10 posts tagged with "multi-agent-systems"

A researcher agent asks a retrieval agent for a document. The retrieval agent, mid-task, decides it needs the researcher to clarify the query before it can search. The researcher, waiting on the document, won't respond until it has the document. Neither one is broken. Neither one is looping. They are both politely, indefinitely, waiting for each other — and your orchestrator, which has no concept of "both of these are blocked on each other," will happily hold that state until a timeout you never configured finally fires, or until a human notices the run has been "in progress" for forty minutes.

This is a deadlock. It is one of the oldest failure modes in computing, and it has nothing to do with how smart your model is. It is a property of how work is coordinated, not how work is done. The uncomfortable finding from the last year of multi-agent research is that most of what breaks in agent swarms breaks here, in the coordination layer, not in the reasoning of any single agent.

Single-agent thinking never surfaces these bugs. When one model runs a loop of tool calls, the worst it does is spin — and a spinning loop is at least visibly spinning. The moment you have two or more agents that can wait on each other, you have inherited the entire back catalog of distributed-systems pathologies: circular wait, livelock, lost messages, premature termination, races on shared state. Nobody sat down and decided to build a distributed system. You built one anyway the day you added a second agent.

If your agent team coordinates through a shared plan file, a repo, or a design doc that everyone reads and writes, congratulations: you have reinvented the blackboard architecture. It was state of the art in 1975. The uncomfortable part is not the reinvention — good ideas deserve to come back. The uncomfortable part is that the original had three load-bearing components, and most modern agent stacks rebuilt only one of them.

Hearsay-II, the DARPA-funded speech understanding system built at Carnegie Mellon between 1971 and 1976, faced a problem that should sound familiar: many specialized, unreliable experts — acoustic analyzers, syntax predictors, semantic raters — none of which could solve the problem alone, all of which needed to build on each other's partial guesses. The architecture that emerged had a shared workspace (the blackboard), independent specialists (knowledge sources), and a scheduler that decided, at every step, which specialist's contribution was worth executing next. Fifty years later, teams wiring LLM agents together are converging on the same shape — a lead agent, a set of workers, a shared artifact — and hitting failure modes the blackboard literature named and solved before most of us were born.

Here is a failure you have probably watched happen without naming it. Your orchestrator reads the user's request and briefs a worker agent. The worker runs a dozen tool calls, digests the outputs, and reports back a tidy summary. The orchestrator folds that summary into a brief for the next worker, who does the same. Five hops later, the system delivers a confident final answer — and it violates a constraint the user stated plainly in the second sentence of their request. Nobody dropped the constraint on purpose. Each hop just compressed the context a little, in a direction nobody chose, and the compressions compounded.

This is the telephone game, and multi-agent systems play it constitutively. Every handoff in your pipeline is a lossy compression step: the orchestrator's brief is a paraphrase of the user, the worker's report is a paraphrase of its tool outputs, and the final answer is a paraphrase of paraphrases. The question is not whether information gets lost — it does, measurably — but whether you have decided what is allowed to be lost, or left that decision to the sampling temperature.

Pull up the architecture diagram for your multi-agent system. Now pull up your org chart. If you squint, they're the same picture. The "research agent" maps to the team that owns search. The "billing agent" has a hard boundary exactly where Finance stops talking to Product. The orchestrator that fans work out to five specialists looks suspiciously like an engineering manager with five direct reports. You didn't decide this on purpose. Conway's Law decided it for you.

Melvin Conway's 1967 observation is that any system you design will mirror the communication structure of the organization that built it. For sixty years this was a story about microservices and monoliths. But agent fleets are the most literal demonstration of the law I've ever seen: the agents are communication structures. An agent boundary is a place where one process hands a message to another and waits. When you draw those boundaries to match your teams instead of your problem, you don't just inherit your org chart's shape — you inherit its dysfunction, and you run it at machine speed.

A planner agent receives a task, decomposes it, and spawns a researcher subagent to handle one of the branches. The orchestration framework propagates the parent's full context to the child because that is the easiest default to ship. The researcher now holds the planner's complete system prompt — the policy text, the names of internal tools, the credentials the parent was scoped to use, the few-shot examples that hint at how your billing pipeline is structured. The researcher's job was to read three documents. The blast radius of the call is the entire authority of the parent.

This is not a hypothetical. It is the default behavior of most multi-agent frameworks shipping in production today. A recent audit found that 93% of agentic projects use unscoped API keys, and that when one agent calls another, the child agent either inherits the parent's full credentials or receives its own independent key — with no project implementing scope narrowing, depth limits, or cascade revocation for delegated access. The framework treats "share parent state" as a convenience and "scope down the child" as opt-in. The opt-in step is the one nobody writes.

Most teams building multi-agent systems spend a lot of time thinking about authorization trust: what is Agent B allowed to do, which tools can it call, what data can it access. That's an important problem. But there's a second trust problem that doesn't get nearly enough attention, and it's the one that actually kills production systems.

The problem is epistemic: when Agent A delegates a task to Agent B and gets back an answer, how much should A believe what B returned?

This isn't a question of whether B was authorized to answer. It's a question of whether B actually could.

Your multi-agent pipeline finished. No exceptions were raised. The orchestrator reported success. And yet, the answer is wrong in a way that makes no sense — the executor skipped two steps, the summarizer collapsed three sections into one non-sequitur, and the output looks like it came from a different task entirely. There's no stack trace to follow. No error code to search. Just a quietly incorrect result.

This is the output coupling trap. It's not a model quality problem. It's an interface engineering problem, and it's the leading cause of silent production failures in multi-agent systems.

Here is an uncomfortable fact about multi-agent AI systems: when you let two or more LLM-powered agents share resources and make decisions concurrently, they deadlock at rates between 25% and 95%. Not occasionally. Not under edge-case load. Under normal operating conditions with standard prompting, the moment agents must coordinate simultaneously, the system seizes up.

This is not a theoretical concern. Coordination breakdowns account for roughly 37% of multi-agent system failures in production, and systems without formal orchestration experience failure rates between 41% and 87%. The classic distributed systems failure modes — deadlock, livelock, priority inversion — are back, and they are wearing new clothes.

Every company shipping multi-agent systems eventually discovers the same uncomfortable truth: their agents don't reflect their architecture diagrams. They reflect their org charts.

The agent that handles customer onboarding doesn't coordinate well with the agent that manages billing — not because of a technical limitation, but because the teams that built them don't talk to each other either.

Conway's Law — the observation that systems mirror the communication structures of the organizations that build them — is fifty years old and has never been more relevant. In the era of agentic AI, the law doesn't just apply. It intensifies.

When your "system" is a network of autonomous agents making decisions, every organizational seam becomes a potential failure point where context is lost, handoffs break, and agents optimize for local metrics that conflict with each other.

Standard LLMs without iterative retrieval score below 10% on multi-step web research benchmarks. Deep research agents — systems that search, read, synthesize, and re-query in a loop — score above 50%. That five-fold improvement explains why every serious AI product team is building one. What it doesn't explain is why most of those implementations either run up a $15 bill chasing irrelevant tangents or declare victory after two shallow searches.

The core problem isn't building the loop. It's knowing when the loop should stop. And that turns out to be a surprisingly deep systems design challenge that touches convergence detection, cost economics, source reliability, and multi-agent coordination.