Yohei (@yoheinakajima) on X

X (formerly Twitter) ·

5 min read Original article ↗

I asked a simple question on X recently:

The replies were interesting because they felt simultaneously sophisticated and unfinished.

A lot of smart people are independently building:

event logs,

memory systems,

graph layers,

retrieval engines,

replay systems,

state machines,

trace infrastructure,

workflow runtimes,

self-reflection loops.

And yet the overall feeling from almost everyone was still:

this doesn’t quite feel solved.

Not in a “the models aren’t good enough” sense.

More in a:

we’re still compensating for something fundamental in the architecture.

That distinction matters.

The field is converging on the same pain points

If you zoom out, a lot of current agent infrastructure starts looking like different attempts to patch the same underlying problem.

Models are stateless between turns.

Everything else exists because of that.

Memory systems compensate for it.

Context graphs compensate for it.

Decision traces compensate for it.

Workflow engines compensate for it.

Multi-agent systems compensate for it.

And they all help.

But after building these systems for a few years now, I keep noticing the same pattern: every serious long-running agent eventually rebuilds roughly the same surrounding infrastructure:

task state,

event logs,

replay,

approvals,

memory,

context retrieval,

evaluation,

retries,

branching,

provenance,

capability tracking.

Usually with different storage layers and abstractions, but conceptually very similar.

The implementations vary a lot. The shape of the problem doesn’t.

Memory is not the real problem

One thing that became very clear reading the responses: people say “memory” when they actually mean several different things.

Conversation recall is one thing.

Long-term knowledge is another.

Tool history is another.

Decision lineage is another.

Capability evolution is another.

State reconstruction is another.

A lot of current systems flatten these together.

But a long-running agent is not just remembering text.

It is maintaining a changing model of:

what it believes,

what it is doing,

what changed,

what tools it has,

what failed,

what succeeded,

what should happen next,

and increasingly, what version of itself produced those outcomes.

That last one feels especially important.

Agents do not just accumulate memories. They mutate.

They gain tools.

They refine prompts.

They change policies.

They improve workflows.

They alter retrieval strategies.

They update internal heuristics.

And once that starts happening, simple “chat memory” stops being enough.

The system now needs continuity not just of information, but of evolving capability and evolving interpretation of the world.

Events and graphs seem complementary

One phrase from the discussion stuck with me:

events capture what happened, graphs represent what is

That feels close to the actual shape of the problem.

A lot of builders are converging on event sourcing because events are simple:

append-only,

replayable,

debuggable,

versionable.

Everything becomes an event:

tool calls,

LLM responses,

memory writes,

failures,

approvals,

capability changes.

Then state gets reconstructed from the history.

This naturally gives:

replay,

auditability,

lineage,

resumability.

At the same time, graph-based systems are clearly becoming more important too.

GraphRAG, knowledge graphs, FalkorDB, Graphiti, and similar approaches are already proving graphs are extremely useful for:

representing entities,

relationships,

semantic context,

provenance,

organizational memory,

and retrieval over structured knowledge.

That part increasingly feels validated.

The thing that still feels underexplored is:

can the graph represent not just the agent’s knowledge, but the evolving operational state of the system itself?

That includes:

tasks,

goals,

capabilities,

policies,

failures,

approvals,

contradictions,

behavior changes,

evaluations,

forks,

traces,

and relations between all of them.

That feels like a different category than “memory graph.”

More like:

a persistent operational substrate.

The branching problem

One thing that came up repeatedly was branching.

Linear replay is relatively easy.

Long-running agents rarely operate linearly.

You want to:

fork hypotheses,

retry from earlier assumptions,

compare strategies,

simulate alternatives,

evaluate different policies,

branch reasoning paths.

This is where many event-sourced systems start getting awkward.

People mentioned versions of:

“it works until you need branching.”

That feels like a very real observation.

A purely linear trace is great for replaying what happened.

But intelligent systems do not only replay. They explore alternatives.

This feels increasingly important as agents become:

more autonomous,

longer running,

and more self-modifying.

Because now the system is not just changing its beliefs.

It is changing itself.

I think we’re still underusing graphs

One thing I realized reading the discussion is that I no longer think graphs are the weak part of the ecosystem.

If anything, I think we are still underleveraging them.

A lot of graph systems today are primarily used for:

retrieval,

entity relationships,

semantic search,

memory organization.

Which is already powerful.

But the deeper opportunity may be treating graphs as the structure of evolving operational state itself.

Not just:

what entities exist?

But:

what changed?

what depends on what?

what is stale?

what was approved?

what failed?

what capability produced this?

what should react next?

what version of the system believed this?

That feels much closer to what long-running agents actually need.

The deeper shift

I increasingly think the underlying problem is not memory.

It is continuity.

Most current agent systems are still fundamentally organized around reactions:

prompt in,

reasoning,

output out.

Even many multi-agent systems are mostly more elaborate reaction chains.

But humans are not fundamentally reactive beings.

We are stateful beings.

A message does not produce a response in isolation. It perturbs an already-existing system:

beliefs,

memory,

goals,

habits,

unresolved tasks,

relationships,

accumulated experience,

and history.

The reaction is only one expression of state.

That distinction feels increasingly important for long-running AI systems.

Especially now that:

models are becoming real-time,

agents are becoming persistent,

tool use is becoming native,

and systems are running continuously instead of per-request.

The bottleneck no longer feels purely like reasoning quality.

It increasingly feels architectural.

The strange convergence happening

One thing I found encouraging from the thread is that people are independently rediscovering very old systems ideas:

event sourcing,

actor systems,

blackboard architectures,

rules engines,

reactive systems,

durable execution,

graph databases.

That does not mean we are regressing.

It probably means long-running AI agents naturally push toward the same requirements older distributed systems already encountered:

persistence,

replay,

coordination,

lineage,

concurrency,

branching,

recoverability.

The agent ecosystem started from chat because chat was the easiest interface for LLMs.

But conversation may not be the correct substrate for persistent intelligence.

That feels like the deeper shift happening underneath all these projects.

The primitive still feels missing

There are already many strong systems:

LangGraph,

Temporal,

Zep,

Cognee,

GraphRAG systems,

custom event kernels,

workflow runtimes,

graph memory layers,

orchestration frameworks.

And honestly, I think the ecosystem is learning very quickly.

But the overall feeling I still get is:

everyone is rebuilding the same missing layer slightly differently.

Some systems center workflows.

Some center retrieval.

Some center events.

Some center memory.

Some center agents.

Some center graphs.

My current intuition is that the missing thing may be some form of:

persistent,

reactive,

inspectable,

evolving state substrate.

Not just memory retrieval.

A system that can maintain:

what it believes,

what changed,

what caused what,

what version of itself acted,

what should react next,

and how its own capabilities evolve over time.

The ecosystem already understands that memory matters.

It already understands that traces matter.

It already understands that graphs matter.

The missing step may be treating these not as separate systems around an agent loop, but as one evolving operational substrate.