If nothing is written down, the next call starts amnesiac.

Part 1 left the model as a stateless engine: context in, tokens out. Memory is the architectural answer to “what do we put in that context next time?” Without it, every step is a stranger with a very good vocabulary.

People overload the word. Chat product “memory” (a profile the vendor keeps) is one product choice. Inside an agent, memory is three different jobs that you should not pretend are one database.

Three buckets

Working context is the prompt you are about to send: instructions, the current goal, the last tool result, maybe a retrieved paragraph. It dies when the call ends. It is RAM, not a filing cabinet.

Session memory is the trace of this job: which tools ran, which IDs were found, which step failed. The orchestrator appends observations so the model can re-plan instead of repeating a query that already 403’d. This is the notebook on the desk.

Longer-lived memory is what should survive the job: a customer preference, a runbook snippet you approved, a summary of last month’s incident. It lives in a store you control — a table, a doc index, a key-value record — and is read back on purpose. This is the filing cabinet. It is also where stale or sensitive facts go to cause next quarter’s incident if you never expire them.

The mechanism is boring and important: something must write. Models do not automatically persist. Your runtime decides what is appended to the session, what is upserted to the store, and what is dropped because it was a guess.

Write outside the window

The context window is a buffer, not a disk. MemGPT (Packer et al.) makes that split explicit: treat the window like RAM, and give the model tools to page facts into a store that survives the next call. You do not have to run MemGPT. You do have to accept the idea. If the only “memory” is whatever still fits in the prompt, you have a chat log with a time limit.

In this architecture:

tool result  →  append to session (notebook)
             →  maybe upsert a reviewed fact (filing cabinet)
             →  next LLM call reads both on purpose

For example: Step 1 calls a tool and learns order 9 is paid. That fact must be logged into session memory as something like get_order(9) → paid.

If you don’t log it, step 2 has no reliable record. The model may call the tool again, or hallucinate a different ID — e.g. invent order 8 — and keep going as if that were true.

So a memory is not an observation log. Without get_order(9) → paid written down, later steps can invent the wrong order.

What you write back

Garbage in garbage out. “query_orders returned 3 rows for account 441” the next step will treat that as fact even if it is wrong.

Do not write secrets into a forever store because the model might leak those secrets. Do not write the entire PDF into working context because retrieval exists — that is Part 6. Write without retrieval is a logger. Retrieval without a write is a search box with amnesia between request.

Blackboard

One agent’s notebook is not enough when specialists hand off. Classic AI named the shared surface a blackboard (Nii, 1986): experts contribute to one board until a solution collects there. Recent LLM multi-agent work uses the same idea — a blackboard as public storage agents read and write so they share information without each keeping a private copy (Han & Zhang, arXiv:2507.01701).

That is still memory. It is session or longer-lived store with many writers. The write policy does not relax: put observations on the board (get_order(9) → paid), record who wrote the line, expire or review facts that outlive the job. If the researcher swallows a tool error and the reviewer trusts the board, the wrong email still ships — only now the fiction is shared.

Who acts next from that board is orchestration and the multi-agent pattern in What’s Coming Next. This part only names the shared write.

Example

Turn 1: the agent looks up order 9. Observation: paid, not refunded.
Turn 2: without session memory, it looks up order 9 again — or invents order 8.
Turn 3: a longer-lived note says “this merchant never auto-refunds.” That note should have been written by a human or a reviewed job.

The failure mode is compounding. A wrong ID in the notebook becomes a wrong email in the world. Part 6 of AI Right Now is still the control story. This part is why the notebook is a control surface.

Conclusion

Draw memory on the diagram as arrows into the next LLM call and arrows out of tool results. If you cannot point to the write, you do not have memory. You have a chat log you are hoping is enough.

Takeaway: Agent memory is a write policy — working context, session trace, a longer-lived store, and a shared blackboard when more than one loop must see the same facts.

Sources

Part 1: The language model
Part 3: Planning