Adding a second agent does not add intelligence, it adds a contract

A team has one agent doing too much, so they split it up. A researcher, a writer, a checker. Every instinct says this should be better.

Quality goes down.

Not dramatically, and not in a way any single trace explains. The researcher does good work. The writer produces something reasonable from what it received. The checker approves it, because what it was handed looks internally consistent. Every agent behaved sensibly and the output is still wrong.

That is the signature failure of multi-agent systems, and it is almost never an intelligence problem. The moment you go from one agent to two, you stop building an AI feature and start building a distributed system. Distributed systems fail at their interfaces, and an interface you never wrote down is still an interface. It just runs on defaults, timing and luck.

Days 49 to 54 of my series take those interfaces one at a time.

The version with no coordinator at all

A swarm deletes the coordinator. Many cheap agents follow local rules, nobody holds the global picture, and coverage emerges rather than being assigned. The resilience is real: lose a third of the workers and nothing breaks, because there is no orchestrator to crash and no bottleneck to saturate. What you pay is explainability. When the output is wrong, no individual agent decided anything, so there is no reasoning chain to follow. Debugging becomes statistics over distributions of behaviour.

The pattern earns its keep on work that divides cleanly and verifies cheaply: sweeping a codebase for one vulnerability class, validating thousands of records. Verification never requires reassembling the whole picture.

That condition does the heavy lifting. Swarm output is noisy by design, so the verifier is the first thing you build, not the last. Decide up front what aggregation rule turns many partial results into one answer, and what stops the exploration. Without both you have motion, a rising bill and no owner.

Headcount is the least interesting variable

In small crews with defined roles, the temptation when quality dips is to add agents. That works about as well as adding people to a late project.

Two agents with crisp boundaries beat six with fuzzy ones, and fuzzy boundaries fail in two directions. Overlap means two agents own the same responsibility, so you pay duplicate tokens and then pay again to reconcile conflicting outputs. Gaps are worse: each assumed the other covered it, nobody did, and the omission ships silently, with no conflicting artefact to alert anyone.

The fix is unglamorous. One page per agent, written before the prompts: what it owns including an explicit not-list, what tools it may use, what it receives and produces, and the criteria its output is judged against. That charter largely is the prompt, which is the point. A system prompt is a job description with worse formatting.

Print every charter side by side once a quarter, looking for responsibilities claimed twice and responsibilities claimed by nobody. Then ask what would get worse if you deleted each agent. If that is hard to answer, removing it is a real architectural improvement.

Permission scope is role scope: a researcher holding deploy credentials has a larger role than its description admits.

Schema-valid and completely misunderstood

Inside one framework, agent communication feels free. The trouble starts at the boundary, and the boundary arrives for everyone. A partner team's agent, a vendor's agent, the system built on a different stack two acquisitions ago.

A real protocol pins down four things. Identity, because an agent accepting tasks from anything that can reach its endpoint is an incident waiting for a motivated party. Capability, stated machine-readably, or task assignment is guesswork in a config file. Task state, with both sides agreeing on the transitions. And artefacts, because passing a blob of prose and hoping the receiver parses it is not an interface. MCP and A2A exist because every team was reinventing those four layers, badly.

The harder failure is semantic, not syntactic. Anyone who survived enterprise systems integration knows the wire format was never the difficult part. Agreement on meaning was. Two agents can exchange flawless, schema-valid JSON while holding incompatible beliefs about what a field means. Does accepted mean "I will do this" or "I received your message"? Does an empty result mean "nothing found" or "I could not check"? Nothing in the schema says.

Each is an incident on a delay fuse. The system works until the difference matters, then fails in a way that makes both agents look innocent, because both were. Negotiate semantics in prose before traffic flows, and version the protocol from day one.

Shared memory is access control whether you designed it or not

Shared memory lets agent crews compound knowledge. It is also how one agent's wrong conclusion becomes infrastructure, and how one user's private context surfaces in another user's conversation. Both failures share a root: memory written without zones.

Three tiers cover most of it. Private scratch, one agent's working notes, readable by nobody else. Mission-shared, visible to the current crew and expired when the mission ends. Organisational, the durable facts everyone builds on, where write access is a privilege.

The control that matters is promotion between those tiers, because whatever crosses into organisational memory becomes load-bearing for every future run. Copy-paste promotion is how a guess made in March becomes established fact by June, relied on downstream, its origin long forgotten. That is contamination, and it is far harder to catch than leakage, because nothing looks wrong. The claim is stated cleanly. It is simply not true.

One heuristic covers most audits: would a human colleague in that role be allowed to see this? Role-based access is already solved elsewhere in your stack, and the mistake is rebuilding a weaker version inside the agent layer. Every entry should be useful, authorised, attributable and correctable. The fourth is the one teams forget, and a correction has to win at retrieval time rather than sit politely alongside the original.

The bug is in the seam, and your traces do not cover the seam

Audit a failed multi-agent run and the defect is rarely inside an agent. It sits at a handoff, where context the sender held never reached the receiver, which then did something reasonable with a fragment.

The instinct is to blame the receiver. The fix is upstream: treat a handoff as a typed contract rather than a message. Objective, so the receiver does not optimise for its own idea of good. State, including what has already been ruled out, the field everyone omits and the one that prevents re-exploring dead ends. Evidence by reference, because a summary of evidence is not evidence. Constraints, so no agent starts fresh against limits already half spent. Ownership, meaning who holds the task now.

Then validate on receipt. A rejected handoff costs seconds and yields a precise error; an incomplete one costs a full downstream execution built on an invented premise.

Most observability setups instrument what each agent did, not what moved between them. If five agents each behaved sensibly and the answer is wrong, the evidence is in the seams, and you cannot see it unless handoff payloads are logged.

Undefined conflicts still get resolved, just not by you

Agent A says approve. Agent B says block. What does your system do?

If you cannot answer instantly, the honest answer is "whatever happens to happen". Undefined conflicts still resolve, just by accident: last writer wins, highest confidence wins, or the system stalls until a timeout chooses.

Disagreement here is scheduled, not exceptional. The risk checker optimises for safety, the growth agent for conversion, both work as specified, and eventually they meet on the same case with opposite answers. Tuning prompts until the disagreement disappears suppresses a signal you want.

Four mechanisms, in order of preference. Policy lookup first, because many conflicts were already settled by compliance, legal or an SLA, and retrieving that ruling beats re-litigating per request. Then categorical priority rules, where safety constraints outrank optimisation goals with no scoring involved. Then a designated decider per conflict class, named in advance rather than discovered mid-incident. Then escalation for genuine ties, carrying both positions and their evidence, because "the agents disagreed" is a shrug with a ticket number.

Log every conflict and its resolution. Two agents colliding weekly on the same case class are telling you their roles overlap, and arbitration is treating the symptom while the boundary defect stays put. Those logs are also the best evaluation data you will get free: real, genuinely ambiguous cases with outcomes attached.

What this adds up to

Six posts, one argument: every connection between two agents is a contract, and if you did not write it, your system is running one anyway, assembled by accident out of defaults, timing and whoever wrote last.

The instinct when a multi-agent system underperforms is to improve the agents. But the failures cluster in four places where agents touch. What each one owns. What they say to each other and what those words mean. What they can read and write in common. Who wins when they disagree.

None of it is model work. It is design work you can do on a whiteboard before writing a line of orchestration code, and it is the difference between five sensible agents producing a wrong answer nobody can explain, and a failure with a name, an owner and a log entry.

The six posts behind this

Each is a short standalone post with the specifics:

• When decentralized agent behavior makes sense
• Why role design matters more than agent count
• Why agents need a shared language
• Why shared memory becomes a permission problem
• Why handoffs need contracts
• Why multi-agent systems need decision rules

They form the Agent Coordination Contracts chapter of my sixty-day series on building AI that survives real users. To work through it from the beginning, Start Here lays out all sixty posts in ten chapters.