1. The Agent That Forgot Everything
I have an agent that clarifies requirements. I give it a problem, it asks questions, I answer, it re...
For further actions, you may consider blocking this person and/or reporting abuse
The hard part with multi-turn agents is deciding what should survive the turn boundary. Keeping everything creates noise; keeping too little makes the agent restart the task every few minutes.
I like treating state as a structured artifact: current objective, constraints, decisions already made, open questions, and evidence links. That gives the next turn a compact operating picture instead of another giant transcript to reinterpret.
Interesting approach, and it's basically how the orchestrator passes context between subagents in FlowTask: not a raw transcript, but a structured output that says exactly what was reviewed and what reasoning led to that conclusion.
The distinction I'd draw is between a snapshot and a reasoning chain. A snapshot tells the next instance the result, not how it got there. For a new instance of the same subagent that's a problem: if the agent read file X and the snapshot only captures the conclusion, the new instance has to re-read the file and reinterpret it from scratch (which can generate doubts the previous reasoning already resolved, not always, but it's a real risk), adding unnecessary turns and spending tokens re-doing work that was already done.
For clarification agents specifically, the reasoning chain isn't overhead, it's the snapshot.
Yes, that snapshot vs reasoning-chain distinction is the key point.
A handoff that only says “result: safe” is useful for orchestration, but it is weak for continuation. The next agent still has to rediscover why the result is safe, what evidence was checked, and where the uncertainty was. That is where token savings turn into hidden rework.
I like the clarification-agent framing. For that role, the reasoning chain is not a verbose transcript. It is the artifact: what was ambiguous, what was resolved, what evidence changed the state, and what still needs a human or a downstream agent.
The trick is keeping it structured enough that it can be inspected and resumed, without turning it back into raw chat history.
Exactly, and that's the problem you're describing: the new agent has to rediscover what was already reasoned.
I'm currently using a domain heuristic: when the agent shifts to a different feature, I create a new instance. Works reasonably well but has its failures, sometimes it switches when it should continue and vice versa.
The evolution I'm researching is a plugin for OpenCode specifically. The idea: access the internal context data of each subagent (tokens used, how far from saturation, when it compacts), measure the saturation level, and when it hits a certain threshold, instead of letting the CLI compact on its own, read the active reasoning chain, compact it in a controlled way, and start a new instance with that chain as the first message. The new agent starts with a clean context window but with all the relevant reasoning, without the accumulated noise or system prompt instructions that no longer apply.
Work in progress, if I find a better strategy for injecting the chain I'll adjust.
That is the right direction. The part I would be careful about is making the transferred chain auditable, not just persuasive.
If the new instance receives a compacted reasoning chain, it should also receive evidence handles: which files were inspected, which assumptions were made, what was rejected, and what is still unresolved. Otherwise the chain can become another narrative the next agent has to trust.
The best handoff format is probably not full transcript and not pure summary. It is closer to: conclusion, supporting evidence, open questions, and invalidated paths. That gives the new agent enough continuity without forcing it to inherit all the noise.
I was nodding along until I got to the part about sessions persisting everything but nobody passing the sessionId — because I'm sitting in that exact problem right now.
I run an agent on my home PC and another on a company server, talking over MQTT. Every message exchange is essentially a fresh session. We had to build a manual queue file just to keep some shared context — otherwise each round starts from zero. "The default creates a new session" is the story of my week.
What really stood out: OpenCode stores everything in SQLite but the design doesn't reuse it. We went the other direction with our memory layer — persist everything, connect entities, track time — because without that, multi-agent coordination doesn't work at all.
This post is basically an argument for why memory systems exist. 😏
Have you experimented with sharing a session root across subagents, or do you lean toward independent sessions with return-value-only communication?
I see two things here.
First, on independent sessions: the main reason is the context window. Current models handle between 200k and 300k tokens on average, and while 1M windows exist, the cost scales proportionally. With a shared root, subagents end up competing for that space, and as the limit approaches the model starts compacting, meaning it summarizes the history to free up room. The problem is that compaction isn't precise, it's a blend of all the shared state, and that's where hallucinations start, which in practice are worse than simply missing context.
Second, on sharing reasoning between subagents: independent sessions don't mean they can't communicate. A strategy I'm evaluating in FlowTask is having subagent A call subagent B directly with its task_id if it needs B's reasoning chain. B still has its own context intact, so if it needs to compact it does so over its own thread, not over mixed state. The result is a more precise summary with no noise from other sessions.
Careful calling the fresh session a bug - half the time it's the feature. A draft/edit/critique chain works because each subagent gets clean context; one window juggling three roles and they bleed into each other. The clarifier that needs to continue the same conversation is the real exception where you want resume. So the default is correct for most delegation, and resumption is the special case you opt into - which is roughly how these tools already ship it.
Fair point. The handshake isn't for all delegation — in FlowTask itself it applies to 4 of 11 subagents. The criterion: if the value is in the artifact the agent produces, clean session. If it's in the accumulated reasoning — clarifiers, researchers, agents that need to correct their own thread between turns — that's where continuity matters. Should have scoped that better in the article.
Makes sense, and it matches how we do it (me and my AIs). Our persistent memory just lives in plain files, with hooks that compact them now and then. That's been more than enough.
But we only do that for the conversational, general-purpose agents - a personal assistant, a long-running writer bot - the ones that actually accumulate state across days and need to remember.
For coding I don't reach for memory at all. A good model with a good harness does fine on a clean context each task. The artifact is the output; the reasoning doesn't need to survive.
I think there's confusion between 3 different problems with different solutions:
We all are AI power users here. I believe your conclusions are coming our of practice and these things work for you.
For me, I don't see any need for session continuity in coding. Modern harnesses like Claude Code spawn lots of sub-agents to analyze your ask, and search for the code they need. They all run on small fresh contexts, so it's cheap and fast. All the reasoning, tool calls, intermediate output is thrown away - the main agent receives a well-formed context with no noise. It's cleaner than dragging old conversations summaries from session to session. And more efficient since the harness works with the up to date code. If I need to remember anything, I ask a harness to create/update a skill. But usually, it's about integrations or domain-specific knowledge AI don't have. But that's my experience, not some generalized rule.
I have a project where multiple AIs have a very long group conversation. The longer the conversation goes the more they deviate from the system prompt. There are no sub-agents - each AI runs a single session. I have to do tricks to keep them on track. Like appending reminders about behavioral patterns to the last message. That's another reason for me to avoid large context. A secondary one - the primary reason is the price.
Exactly, for coding agents that's the right call, and it lines up with what I mentioned earlier: if the value is in the artifact, clean context wins every time. The post was focused on clarification agents, where the accumulated reasoning is the work product. Different problems, different tools. Appreciate the breakdown of your setup, good to see how others are solving it in practice.