Direct answer

Your agent forgot mid-task. Here is how to find out what it actually did earlier in the same session.

It happens inside one session, not between sessions. The conversation gets long, the early steps fall out of the working context, and the agent starts repeating finished work, undoing a decision it made an hour ago, or asking you to paste something it already produced. Asking the agent what it did is the worst way to find out, because the same missing context is what it would answer from. The record of the calls themselves is the answer.

Check the record instead of the memory: every Zambo call leaves a receipt you can open and check free at zambo.dev/verify, with no signup. Read the session back from its receipts, in order, and you have the ground truth the agent lost.

Updated October 24, 2026.

Why agents forget inside one session

A long session is not one long memory. The model works from a limited window of context. As the session grows, earlier material is summarized, truncated, or pushed out entirely, depending on the app. The agent does not announce when this happens. It keeps talking in the same confident voice, now working from a partial picture. The symptoms are consistent:

It repeats a step that already ran, sometimes producing a second, slightly different version of the same output.
It contradicts an earlier decision, a name, a number, or a constraint it set itself earlier in the session.
It asks you for information it already had, or re-asks a question you already answered.
It summarizes the job so far in a way that drops finished steps or invents a step that never ran.
It loops back to an approach it tried, watched fail, and abandoned.

None of this means the earlier work vanished. It means the agent lost sight of it. The work products, and the record of the calls that made them, still exist outside the conversation window if anything was keeping them.

Settle it from the record, in order

1. Stop the session from doing more damage. Pause the run. A forgetful agent that keeps going can overwrite the good earlier output with the confused later version, and every extra step makes the cleanup longer.

2. List what actually ran, from the record, not the transcript. Go to the calls themselves. On Zambo, each call in the session saved its result when it ran and returned a receipt. Read them in timestamp order. That list, with inputs and saved outputs, is what the session really did, including calls the agent summary forgot and excluding steps the summary invented.

3. Mark the three buckets. Done and good: outputs that stand. Done and superseded: an earlier version replaced by a later call on purpose. Never actually ran: steps the agent talked about but no call backs up. The third bucket is the one that hurts projects, because everyone, including the agent, believed those steps happened.

4. Build a short state brief from the record. Goal, decisions made with their dates, the standing outputs by name, the open items, and the next step. Write it from the receipts and the saved outputs, not from the agent summary. This brief is what re-anchors the session.

5. Restart from the brief, not from the transcript. Paste the brief into a fresh session or hand the job over properly, and check the first few new calls against it. A fresh window with a true brief beats a long window with a false memory every time. The full handover method is in AI agent context handoff.

The difference between memory and a record

Agent memory features help between sessions, and they are worth using. But memory is something the agent writes about itself, in its own words, at whatever moment it chooses. A per-call record is different in kind: it is saved by the system when the call runs, outside the agent narration, whether or not the agent later remembers the call existed. When the two disagree, believe the record, then fix the memory from it.

That is the role receipts play here. Zambo is the verifiable work layer for AI. Work run through the Zambo MCP endpoint saves the result of every call as it runs, and the receipts for a session can be read back in order by you, by a teammate, or by the next agent taking over. The agent can lose the thread. The record does not lose itself, because it was never inside the thread.

The crash version of this same problem, where the session does not fade but dies outright, is covered in AI work lost when the laptop closed: how to resume. The between-sessions version is in your agent forgets between sessions.

Make the next long session forget-proof

Work in recorded calls for anything that matters. Research, drafting, data work, and file changes that run through a recorded endpoint leave a trail you can rebuild state from. Chat that never touches a tool leaves nothing but the transcript.
Close stages, not just sessions. At each natural stage, close the work so far with a handover or a written state brief saved outside the chat. A two hour session then has anchors every thirty minutes instead of one fragile thread.
Name outputs and keep the names. When a step produces the version you want, say so in the record: this file, this draft, this number set. Later confusion is usually about which version was the chosen one.
Watch for the symptoms early. The first repeated question or contradicted decision is your signal to stop and re-anchor from the record, not to push on and hope.

Honest limits

A record settles what ran and what it returned. It does not put the lost context back into the agent head, and it does not make a long session safe to run forever. You still have to do the re-anchoring step: read the record, write the brief, restart clean.

It also only covers calls that actually ran through a recorded path. Thinking the agent did in plain chat, with no tool call, leaves no receipt. If a step matters, route it through a call, or write its result down outside the session at the time. A record can only settle what it was present for.

Set up the record before you need it

Long sessions are normal now, so set the record up before the session starts stretching. Run the work through Zambo from the first call, close each stage with a handover, and the session can be rebuilt from its receipts at any point, by you or by a fresh agent, without asking the forgetful one what happened.

Work run through the Zambo MCP endpoint at zambo.dev/mcp (153 tools, 35 on the default surface) saves its result when the call runs and returns a verifiable AER-1 receipt (draft-zambo-aer1-26) for every call. In short, an agent receipt is a record of one ai agent tool call that anyone can check: it keeps the exact saved bytes and their sha-256 digest, and it proves the result was not changed since it was saved, not that it was right. Start free: 20 free calls per day, then they upgrade. The Day Pass is $0.99 for 24 hours. Checking any receipt is always free at zambo.dev/verify.

Questions, answered

Why does my agent repeat work it already did in the same session?

Because the earlier step fell out of its working context as the session grew. It is not being careless in a human sense; it literally cannot see the earlier call anymore, so it plans as if the step never happened. The fix is to read the session back from its per-call record and re-anchor it with a short state brief written from that record.

How can I tell what my agent actually did earlier today?

From the calls, not the summary. If the work ran through Zambo, open the receipts for the session in timestamp order: each one holds the saved result of that call. Steps with a receipt ran. Steps the agent describes with no call underneath them did not, whatever the summary says.

Is agent memory the same as a call record?

No. Memory is the agent own note about what mattered, written in its words, and it can be wrong, partial, or overwritten. A call record is saved by the system at the moment the call runs, outside the agent narration. Use memory for convenience and the record for truth, and rebuild memory from the record when they disagree.

Should I just start a brand new session when this happens?

Yes, once you have the state brief. A fresh session loaded with a true brief written from the record will outperform the old session, which is now reasoning from a partial and partly false picture. Starting fresh without the brief just trades one kind of forgetting for another.

Can a receipt prove the agent output was correct?

No, and that is not its job here. The receipt settles that a call ran and that the saved result is the result that came back, unchanged since it was saved. Whether that result is good is your judgment, made by reading it. For a forgotten session, settling what ran is most of the rescue.

Start where the work starts: run the next job through zambo.dev/mcp, close it with a handover, and check any receipt free at zambo.dev/verify. If you only need a day, the Day Pass is at zambo.dev/day-pass.