Multi-Agent Systems

This cover delivers the post's hard truth with a concrete horror story: a team that demoed beautifully ends up with two agents handing the same task back and forth, triple the cost, and no way to tell which agent broke. The clever decomposition is the easy part; the coordination discipline is what determines whether the team survives contact with reality.

The post is a field guide to the specific, repeatable ways multi-agent systems fail — no termination rule, overlapping roles, context duplication, poisoned handoffs, over-using teams, and no observability — each paired with a concrete fix. These are the mistakes that turn a promising architecture into an expensive, opaque liability.

The no-termination mistake is first because it is the most dangerous and the most common in multi-agent systems specifically. Without an explicit stop condition, agents defer to each other indefinitely — the writer asks the critic, the critic requests a rewrite, and the cycle repeats with no one committing to finish. There is no natural stopping point in a loop where each agent can always find a reason to hand off again.

The fix is non-negotiable: set a max-turns cap, define a clear 'done' signal, and return a graceful failure when neither agent will commit. The deference loop is subtler than a single agent's infinite loop because each handoff looks locally reasonable. That is exactly why an external, explicit termination rule is mandatory rather than emergent.

Overlapping roles are the failure unique to multi-agent design. When two agents have fuzzy, overlapping responsibilities, three bad things happen: they duplicate work, they contradict each other, or each assumes the other handled the job and neither does. The whole premise of specialization collapses when the specializations blur.

The fix borrows a principle from clean system design — roles should be mutually exclusive and collectively exhaustive. Each agent owns exactly one job with no overlap, and together the agents cover the entire task with no gaps. Sharp, non-overlapping role definitions in each agent's prompt are what keep handoffs clean and prevent the duplication-or-gap failure mode.

Context duplication is the mistake that quietly explodes your bill. The naive approach passes the full conversation to every agent on every turn, which multiplies token cost by the number of agents — and multi-agent systems already make many more calls than a single agent. What looks like a modest team can cost an order of magnitude more than expected.

The fix is to scope context per role: each agent receives only the slice it actually needs. The writer gets the researcher's distilled facts, not the raw search logs; the critic gets the draft, not the entire history. This is the same context-isolation benefit the 'why' post promised, but here framed as a discipline you must actively enforce or lose.

The mindmap organizes the failure space into four buckets — Loop, Roles, Cost, and Handoff — so the mistakes are memorable as categories rather than a flat list. Loop failures are missing termination and agents deferring forever. Role failures are overlap and gaps in coverage. Cost failures are duplicated context and simply too many agents. Handoff failures are garbled messages and propagating errors.

This taxonomy is a diagnostic tool. When a team misbehaves, walk the four branches: does the loop terminate, are roles clean and complete, is context scoped, and are handoffs validated? Most broken teams fail on at least one branch, and identifying which one points you straight at the fix instead of vaguely blaming 'the agents.'

The poisoned-handoff mistake captures how errors compound in a chain of agents. Agents trust their inputs by default. If the researcher returns a wrong fact, the writer faithfully builds on it and the critic may not catch it — the single error propagates and amplifies down the whole chain, producing a confident, thoroughly wrong final answer.

The fix is to treat handoffs as boundaries that deserve validation. Check critical outputs at the point of handoff — citations exist, numbers are plausible, required fields are present — and explicitly give downstream agents permission to reject bad inputs rather than building on them. A critic empowered to send work back, not just annotate it, is one practical form of this defense.

This mistake is the inverse of the day's whole thesis, included deliberately for balance. Multi-agent is the answer to coordination problems, not a default architecture. If a single well-prompted agent with tools solves the task, splitting it into a team only adds latency, cost, and new failure modes for no benefit. Complexity you do not need is pure downside.

The fix is a discipline: start with one agent, and split into a team only when the work genuinely has distinct roles, parallelizable subtasks, or a real need for independent review. This echoes the 'when not to use it' slide from the 'why' post — the temptation to over-architect is strong enough that it earns a place in both the benefits and the mistakes.

The comparison puts a fragile team beside a robust one trait by trait, as an auditable checklist. Fragile: no turn cap, overlapping roles, full context broadcast to all agents, blind trust in handoffs, a team reached for on every task. Robust: max turns plus a done signal, one job per agent, scoped context per role, validated handoffs, and a team used only when truly needed.

Use this as a self-audit. If your system matches the left column on even one row, that is a thread to pull before you ship. The right column is not aspirational perfectionism — it is the minimum bar for a multi-agent system whose success in a demo predicts anything about its behavior under real traffic and real cost.

The no-observability mistake is the one that makes every other mistake harder to fix. When a team fails, 'the agents messed up' is not a diagnosis — it is an admission you cannot see inside your own system. Without logging each handoff, message, and routing decision, you have no way to tell which agent broke, what it received, or why the orchestrator sent work where it did.

The fix is to trace every turn: record the sender, the content, and the routing choice for each step. In a multi-agent system this is even more critical than in a single agent, because failures are emergent — they arise from interactions between agents, not within one. Good tracing turns 'the team failed' into 'the researcher returned an empty result on turn three,' which is something you can actually fix.

The code operationalizes the most important guardrails in one function. safe_team records a start time and, on every iteration, checks both the turn count via the bounded for-loop and a wall-clock deadline, returning a graceful timeout if either trips. It logs every routing decision for observability, honors an explicit 'done' signal for termination, and wraps each agent run in try/except so a throwing agent records an error in the log instead of crashing the whole team.

These few lines are the difference between a demo and a deployable system. The deadline and turn cap guarantee termination; the per-turn log gives you the observability the previous slide demanded; the try/except keeps one agent's failure from taking down the run. Note that scoped context lives inside run_agent — the cost discipline is enforced where each agent is actually invoked. Make this guarded, logged, fault-tolerant shape your default skeleton.

The tips consolidate the post into a buildable checklist: set a termination rule and turn cap, make roles mutually exclusive with one job each, scope context per agent to control cost, validate handoffs and let agents reject bad inputs, log every handoff for observability, and use a single agent unless the work truly splits. Each line is the direct antidote to one of the six mistakes.

The meta-lesson is that a trustworthy agent team takes deliberate engineering — it does not emerge from clever role decomposition alone. The decomposition gives you potential capability; this checklist gives you capability you can deploy affordably and debug when it breaks. The gap between those two is where most multi-agent systems quietly fail in production.

The CTA closes the day and points to the next building block in the series. You have now seen what a multi-agent system is, why teams reach for one and when they shouldn't, how orchestration and message passing actually work, how to build a team in code, and how the same team descends into chaos without discipline. That is a complete, defensible foundation for building agent teams.

Save the day as a set. The concept anchors the agents-roles-messages model, the stakes explain what splitting the work unlocks, the mechanics show orchestration and memory, the code makes it real, and these mistakes keep your team honest, affordable, and debuggable when it finally meets real traffic.