Merge on reasoning, split on artifacts
We are on our third multi-agent architecture for the same job. The first two failed, and they failed for reasons that turned out to be the same reason seen from opposite sides. The rule we extracted from them is the most portable thing we have learned building this system, and it contradicts how multi-agent decomposition is usually justified.
The job
Compile one topic of robotics engineering knowledge — say A* path planning — into a structured record: the distinct engineering paradigms that solve it, the ordered steps each one takes, the capabilities each step needs, and the open-source assets that implement them. Research it from the literature, verify the assets exist, emit conformant JSON. Then do that 2,524 times, unattended.
v1: one agent, one topic, one context
The obvious first attempt. Give one agent the whole topic and let it work.
It failed three ways that were really one way. Research depth was squeezed by context length — as the conversation filled with retrieved material, later paradigms got visibly shallower treatment than earlier ones. Paradigms contaminated each other, converging on a shared vocabulary that belonged to none of them. And by the time the agent wrote the record, a large share of fields were drafted from memory rather than grounded in anything retrieved; the research documents degenerated into conclusions with no recoverable evidence behind them.
Diagnosis: one context cannot hold five deep investigations. Obvious fix: give each paradigm its own context.
v2: one agent per chain, split into a relay
So we did that, and went further. Each paradigm got its own context, and we split the work inside it across three specialist agents in sequence — research, then asset verification, then JSON emission — with all paradigms completing research before any entered generation. Clean separation of concerns. Each agent has one job. This is how you are supposed to build these things.
It failed for a reason we did not anticipate:
Design intent evaporates at the handoff. Why this chain has this step sequence; why step 4 must follow step 3; why two capabilities were deliberately not split apart — these are judgements formed during research. Only their conclusions can be written into a document. The reasoning that produced them cannot.
The downstream agent had no choice but to transcribe the document literally, and two consequences followed immediately.
The cost of one more search became a whole session. When the document did not cover a field, the JSON agent had no recourse. It was forbidden from searching — because an agent with no research context that is allowed to search will fill gaps from parametric memory, which is worse than leaving them empty. So a gap that one query would have closed had to wait for human intervention or an entire additional round.
Verification could not feed back. When the asset-verification agent discovered that a capability had no real implementation anywhere, it had neither the authority nor the context to revise the capability list the research agent had designed. It could only execute the plan it had been handed, knowing the plan was wrong.
We had decomposed along role boundaries. Roles were the wrong seam.
The rule
Merge two stages into one context when what passes between them is reasoning. Split them into separate contexts when what passes between them is an artifact.
Reasoning does not survive serialization. Artifacts do.
A handoff that requires the receiver to reconstruct why is a handoff that should not exist. A handoff that requires the receiver only to consume what is a handoff that should be made explicit, durable and resumable.
The usual justification for multi-agent decomposition is capability specialisation: give each agent the role it is best at, keep its prompt focused, let it be excellent at one thing. That is not wrong, but our experience says it is not the binding constraint. The decisive question is not what each agent is good at. It is what can survive the gap between them.
What the rule produces
Applied honestly, it cuts in two directions at once, which is why the resulting architecture looks inconsistent until you know the rule.
Within a chain, merge. Research, asset verification and record emission happen in one agent session, because what passes between them is design intent. The agent that writes the record is the agent that did the research. Gaps found during emission get closed by a few extra queries on the spot. Verification can revise the research plan, because it is the same conversation.
Across the orchestration, split. Panoramic survey, cross-chain merge adjudication, and final validation happen in three separate agent sessions handing off through the file system, sharing no conversation context — because what passes between them is finished artifacts: documents, fragments, a record.
Two levels, opposite decisions, one rule. The test is always the same: is the payload a reasoning chain or a file?
What it costs
Closing the loop within a chain is not free, and the bill arrives in a specific place. Chains now run in parallel and mint identifiers independently, so the same real capability reliably acquires two identifiers under two names. Something has to reconcile that.
We pay it deliberately, in one place: a merge stage that is the only point in the whole pipeline with simultaneous visibility of every finished chain. The trade is favourable for a specific reason — merging is mechanically decidable. It has criteria, thresholds, and a written adjudication standard. Design intent, once lost, cannot be reconstructed at any price.
That asymmetry is the whole argument. Pay in the currency you can actually earn back.
There is also a smaller cost we did not foresee. Because the chain agent now researches and emits schema, we can no longer put a cheap model on the mechanical segment. Closing the loop removed an optimisation.
Two corollaries worth stealing
Context is a budget, not a log. When a chain agent returns, our controller records one line — chain number, verdict, entity counts, whether gaps were flagged — and does not read the returned artifacts into its own context. This is written into the specification as a rule, not left to judgement. The controller's context is reserved for dispatch and gating decisions. Treating context as something to be allocated, rather than a place where information accumulates, is what makes a 30-topic batch tractable.
A validation stage needs an explicit instruction not to re-derive. Our final-check phase is forbidden from re-reading the research documents in full, re-verifying asset URLs, or redoing the adversarial reading already performed upstream. The stated reason is that the acceptance records of those earlier steps are the evidence. Without that instruction, a capable agent handed a validation role will re-derive everything it can — and a pipeline that re-validates at every stage does not converge. We learned this by watching it not converge.
Where the rule might not hold
We have applied it to one problem, in one domain, at one scale. Some honest caveats.
It assumes reasoning is genuinely lossy to serialize. If your intermediate reasoning is short and formalisable — a plan in a DSL, a proof term — then it serializes fine and the rule collapses to "split everywhere". Our reasoning is long-form judgement about engineering trade-offs, which is exactly the lossy case.
It also assumes the merged stage still fits. The rule says merge when reasoning passes between stages; it does not repeal context limits. v1 failed because too much was merged. The rule tells you where the seams should be, not how many there should be.
Where this comes from
This is §5 of a system paper on Entropy Box, a knowledge compiler for robotics and embodied AI. The paper describes the full architecture — the admission gates, the provenance ledger, and two sequencing constraints that bit us in similar ways (normalize entity identifiers before measuring chain overlap; rekey to opaque surrogate keys only after every stage that needs to read names).
- Paper (PDF) — §5.1 for the two failures in full, §5.2 for the rule, §5.6 for the ordering constraints
- How the graph is built — including the actual research documents for one topic, with their retrieval ledgers
If you have decomposed an agent system along role boundaries and watched intent leak out at the seams, we would like to compare notes.
Part of Entropy Box, a knowledge compiler for embodied AI. Corrections welcome: wangyuqi11and11@163.com. This post is CC BY 4.0.