The write-read loop that ends the forgetting
During the session, the agent writes. Facts it establishes, decisions you make together, the state of the work in progress: saved with memory tools as it goes, not reconstructed afterward. The write is a tool call, so it leaves a receipt like everything else on the endpoint.
At the next session, the agent reads. Before it answers your first question it recalls the memory and reloads the recent work state, so "the project" is a lookup, not a re-interview. The session still ends whenever it ends. Endpoint-backed memory does not have to end with the session, because it does not live only in the session.
Counted, not promised. In one counted evening window on 2026-10-22 (16:12 to 21:53 UTC), the public receipt stream recorded 21 memory writes, 26 memory recalls, and 55 continuity reads, alongside 398 other receipted calls from 127 distinct callers. That is the loop running in production: agents putting state down in one session and picking it up in another, in the open, where the counts can be recounted by anyone.
Why the usual workarounds keep disappointing
Bigger context windows make a single session longer, not memory longer; the window still closes. App memory features keep notes inside one vendor's walls, in a form you cannot inspect closely and cannot take with you, and they summarize aggressively, which is how the detail you actually needed gets smoothed away. Pasted summaries decay with every hop: session three works from session two's retelling of session one's work. External, tool-level memory avoids all three traps because it is the record itself, written at the time, readable by later sessions in connected clients.
Continuity with receipts attached
Memory alone tells the next session what was decided. Receipts tell it what was done, checkably. When the finished parts of a job carry verifiable receipts, the new session inherits evidence, not just notes: it can recompute the record of the completed steps before building on them. That pairing, external memory plus receipts, is what turns "the AI remembers" from a vibe into an auditable property, and it is the same pairing that lets a job move between connected AIs, as the handoff pattern describes. The forgetting problem and the switching problem are one problem, and they have one fix.
Questions, answered
Why does my AI agent forget everything between sessions?
Because its memory lives where the session lives: inside one app's conversation. When the session ends, the working context ends with it, and the next session starts from whatever the app chose to keep, which is usually a summary or nothing. The fix is architectural, not a better prompt: store the memory outside the app, in a memory layer the agent writes to during the session and reads back at the start of the next one. On Zambo that is the memory and continuity tools behind one endpoint, used across sessions for connected workspaces, so the memory survives the app and the session, and can support a handoff when work moves to a different AI.
How do I give my agent memory that persists across sessions?
Connect the agent to an external memory it can call as a tool. During work it remembers facts, decisions, and state (memory_remember); at the start of a new session it recalls them (memory_recall) and reloads the recent work state (continuity_get_recent). In one counted evening window on 2026-10-22, agents made 21 memory writes, 26 memory recalls, and 55 continuity reads on the Zambo endpoint: the write in one session, read in the next pattern, running in production. Add the endpoint at https://zambo.dev/mcp to the client you already use and the habit is available to every session from then on.
Is pasting a summary into the new chat the same thing?
It works once, badly, and then quietly rots. A pasted summary is a retelling by the previous session, edited by whatever it thought mattered, and it drifts further from the record with every hop. External memory is the record itself: the facts and state as they were written when the work happened, read back verbatim. And when the finished parts of the job carry receipts, the new session can check what it is inheriting instead of trusting the retelling, which is the difference between continuity and a game of telephone.
Does the memory follow me if I switch AI apps?
It can, for workspaces connected through the endpoint, and that is the point of keeping the shared job memory outside any one app. Connected clients read from the same endpoint-backed store instead of each app's own session store, so a job can start in one client and continue in another: the second AI reads the same memory and the same recent state, and picks up with the receipts of the finished work attached. App-locked memory makes switching AIs feel like hiring a new assistant every time. External memory makes the apps interchangeable and the work continuous.