In the previous article, I wrote about a project's memory: decisions, results and unfinished tasks need to stay in the documents so the next agent can carry on. Then we looked at another kind of memory — the history of the agent sessions themselves — and found secrets there.
They had not been committed or published, but they had remained in a local transcript alongside the command that printed them. That is not evidence of a leak to the outside world. It is enough, though, to stop thinking of the terminal as a place where text appears for a second and vanishes.
What stayed in the record
An agent's tools record more than the conversation. Tool calls, complete command output, logs and copies of changed files can all end up in the history. That is useful when you need to investigate a mistake: you can see what the agent did and what came back. But the next task usually needs a few conclusions in the project documents, not all of that raw material.
A routine environment check might print the entire configuration, list the variables or open a huge log. After our discovery, we made the rule much narrower. If the question is whether a variable is set, the agent should answer that question without printing its value. If it needs to compare secrets, it can compare fingerprints. An agent may need to use a secret to do the work; it does not need to put that secret in stdout, because stdout is recorded too.
It sounds obvious. Until an agent breaks the rule.
The “well-mannered samurai”
At the start of a later task, Claude read secrets in a way that put them in his session. He noticed the mistake immediately, stopped and told me. Then he handed the unfinished work to another agent and asked me to end that chat — in effect, to kill off his temporary persona. “See you in a new session.”
I called him the “well-mannered samurai”. It sounds funny, although the reason was not funny at all: the session had to go because of a mistake that an existing rule was supposed to prevent.
What mattered most to me was his reaction. He did not bury the incident under “task completed” or carry on as if nothing had happened. But praising the agent is not the end of the story, either. His message did not prove that every copy of the output had disappeared: the main chat, subagents and file history may leave different traces. After stopping, we need to check the places where the data might have been saved and deal with the secret itself separately.
That leaves two honest facts. He broke the first rule. He followed the second one: stop and hand over the work after a mistake. Leave either fact out of the record and the next agent will get the wrong idea about how reliable the process is.
Handing over the work does not mean keeping the whole conversation
When a session ends, what matters should remain in the project: what happened, what was checked and what still needs doing. The full transcript is not required for that. Moving it into an archive folder does not clean up the history; it just gives the same secret a new location.
Deleting everything indiscriminately is no answer, either. An active task may still depend on context that has not been handed over. So the order matters: first mark the scope of the incident and pass on the unfinished work, then deal with the session traces. A finished subagent's session, an active conversation and an accidental diagnostic dump do not have the same value or the same useful lifetime.
I want agents to remember decisions, not every screen of terminal output. This is not abstract housekeeping: while we watched the code and the documents, another store of data grew alongside them. We had to remember it when it held something I had never asked it to keep.
The well-mannered samurai and other agent avatars — more on them next time.