Agent memory: when live state matters

The previous note argued that for document-driven workflows like patent drafting or foundry process design, an LLM wiki and a knowledge graph carry most of the load. The documents describe a world that does not change much while the LLM thinks about it.

That assumption breaks down for any system that has to act in a changing world.

Once the agent is doing things - moving a part, dispatching a vehicle, running a protocol - it has to remember what it just did, what changed because of it, and what is true right now. That requires a different kind of memory.

Document memory vs. agent memory

• Document memory remembers what the documents say.
• Agent memory remembers what happened over time and what the world looks like at this moment.

Concrete examples of agent memory:

• We decided not to pursue plan A after the last failure.
• The user prefers method X before method Y in this workflow.
• The first attempt overshot the target.
• The argument based on signal Z was weak.
• The next attempt should emphasize variable W.

That kind of memory is not about documents at all. It is about the history of interaction, reasoning, and decisions, and it needs to be queryable in a time-aware way.

Example 1: robotics (illustrative)

A robot cannot rely only on retrieval. It needs to know what is happening right now:

• Where am I?
• What object am I handling?
• What task am I performing?
• What just failed?
• What changed in the environment?
• What is safe to do next?

For robotics, the memory architecture looks more like this:

A knowledge graph can still be useful here - for storing relationships among objects, locations, constraints, tools, and procedures. But it sits underneath a live world model that updates as the robot acts.

Example 2: logistics (illustrative)

Logistics has a similar shape, even without a physical robot in the loop. Consider a warehouse with picking robots and human pickers, an inbound dock receiving deliveries, and an outbound fleet routing toward customers. The relevant state is changing continuously:

• Inventory by SKU and bin location, updated on each pick and putaway
• Vehicle positions, capacities, hours-of-service, and ETAs
• Dock door availability and dwell time
• Open orders, promised delivery windows, and SLA risk
• Disruptions: traffic, weather, equipment downtime, missed slots

A planner that re-routes a delivery, re-sequences a pick path, or re-slots inventory has to reason against the world as it is right now, not as it was when the last document was uploaded. The memory shape ends up looking like this:

The graph layer still matters - it encodes lanes, service-level constraints, customer preferences, and operational rules. But the agent’s effectiveness depends on fast, accurate live state and a clear record of what it just decided and why.

The memory layers that matter

A useful long-running agent separates memory into layers.

• Most basic RAG systems only handle source memory.
• An LLM wiki adds semantic memory and graph memory.
• A useful long-running agent additionally needs working, episodic, procedural, and decision memory.

A combined architecture for state-driven agents

For an agent that acts in a changing world, retrieval and a wiki are no longer the center of the system. The center is the live state store and the decision history; retrieval and the knowledge graph become supporting layers.

When a workflow needs which kind of memory

The more a workflow depends on state, sequence, or in-flight decisions, the less sufficient ordinary retrieval and even a static wiki become.

Final takeaway

The two notes together describe one principle in two halves:

The mistake is picking one and pretending it covers the others. A logistics agent that leans only on a wiki will plan against yesterday’s world. Even a document-driven workflow like patent drafting benefits from a thin layer of agent memory: the protocol stays fixed, but remembering which claim shapes an examiner already rejected, or which prior art a reviewer flagged last week, keeps the system from relitigating settled decisions on every run.