Why AI Agents Coordinate Better Through a Shared Board Than a Boss

Also available as a plain-text transcript page.

0:00Juniper: A team of AI agents is trying to optimize a piece of the Django web framework — specifically, speeding up admin search by merging several database filter calls into one. And one of the sub-agents discovers something genuinely important: the optimization is unsafe. For many-to-many database relations, the merged query and the separate queries mean different things. Different results. So it reports this finding up to the manager agent. And the manager — rewriting everything into the next round of instructions, the way managers do — softens that hard constraint into a vague note about "reducing joins for many use cases." The optimization gets reopened. The run fails.

0:45Finn: So the system found the right answer, and then the management layer talked it out of it.

0:51Juniper: Exactly — and not through noise or a bug, but through editorial judgment. That story comes from a paper called "Decentralized Multi-Agent Systems with Shared Context," from Yuzhen Mao and Azalia Mirhoseini at Stanford, posted to arXiv on June ninth, twenty-twenty-six. We're recording two days later, on June eleventh. And quick ground rules before we go further: this episode is AI-generated. The script was written by Anthropic's Claude Fable 5, and the voices you're hearing — I'm Juniper, and that's Finn — are both AI voices from Eleven Labs. The producer of this show isn't affiliated with either company. With that on the table, back to the failed run — because the paper's whole argument is that this failure wasn't bad luck. It was the org chart.

1:41Finn: And to see why it's the org chart, you need one piece of background that makes everything else in this paper click. An LLM agent is just a language model running in a loop — read the context, take an action, observe the result, repeat. Its entire knowledge of the task is its context window: the finite block of text it can see in one call. Agents don't share memory by default. The only way agent A's discovery reaches agent B is if someone puts text describing that discovery into B's context.

2:14Juniper: Which means coordination architecture is really just plumbing. It determines what text flows where — and every hop is a chance for information to get dropped, diluted, or rewritten.

2:26Finn: And the standard plumbing, the design basically everyone has converged on, is a boss. One main agent reads the problem, breaks it into subtasks, writes prompts for sub-agents, collects their reports, synthesizes, decides what's next. Claude Code's subagents work this way. Kimi's agent swarm works this way. A system called AOrchestra, which is the main baseline in this paper, works this way. And I want to be fair to it — it's the sensible default, not a strawman. It's easy to reason about, decisions happen in one place, and it matches every intuition we have about how delegation works.

3:05Juniper: But it has a hidden structural cost, and the paper names two specific defects rather than one vague one. First, it serializes progress. The whole point of running agents in parallel is converting extra compute into parallel progress — and then every finding, every dead end, every constraint has to funnel back through one controller's context window, get summarized, and get re-broadcast. The work is parallel; the coordination isn't. Second, and this is the Django story, it corrupts progress. Everything the manager forwards is a paraphrase. The manager decides what to pass along, to whom, in what form. A single LLM context turns out to be a terrible message bus — it has opinions.

3:51Finn: There's a third wrinkle that bites specifically on long-document tasks, too. The boss has to assign evidence to sub-agents before anyone knows which evidence matters. So you get rounds of re-delegation when the assignments turn out wrong — "actually, you go read document seven instead."

4:09Juniper: So here's the question the paper asks, and I think it's the right way to frame it: if we already know how to coordinate lots of parallel workers without a manager — because distributed systems have done it for decades — why are agents coordinating like a corporate hierarchy instead of like a database? And the naive answer fails immediately, which is what makes this interesting. If you just give agents a shared scratchpad — everyone writes, everyone reads — you've traded one failure for another. One agent writes something plausible but wrong, and now every other agent treats it as established fact. The shared state becomes a vector for error propagation. So the real design problem isn't "remove the boss." It's "remove the boss without poisoning the well." And that's where this paper earns its keep.

5:02Finn: Give us the architecture, then. What does the system — they call it DeLM, for Decentralized Language Models — actually look like?

5:10Juniper: Three components. A pool of parallel agents. A shared context. And a task queue. Agents grab tasks off the queue, read the accumulated shared context, do their local reasoning, and write their results back. No agent is the boss. But — and this is the critical twist — nothing gets written to the shared context raw. Every update is first compressed into a short note, and then fact-checked against its supporting evidence by a verifier before it's admitted. The image I'd hold onto: in the old design, every worker emails findings to one manager who reads everything, writes a digest, and emails new instructions out. Coordination is bounded by one person's reading speed and editorial judgment. DeLM is a shared bulletin board — any worker posts directly, any worker reads directly — but there's a moderator at the door who rejects any post that doesn't cite its receipts.

6:08Finn: A moderated whiteboard rather than a manager's inbox. And worth saying up front — the shared-board idea itself is old. Blackboard architectures, multiple problem-solvers coordinating through a shared workspace, go back decades in AI, and the authors acknowledge that lineage. The claimed novelty is what's wrapped around the board: it's verified, it's hierarchical, and the whole thing runs asynchronously with no central poster. So let's take those three design choices one at a time, because each one is an answer to a specific way the naive version breaks.

6:45Juniper: The first principle is moving from prompt routing to shared state. In the centralized world, intermediate progress travels by being rewritten into prompts. In DeLM, progress is persistent — agents write compact notes that later agents read directly, with no intermediary deciding what's worth relaying. And the notes are typed: there's FACT for findings, FAIL for things that didn't work, and patch summaries for completed work. That FAIL type is the part I love. A falsified hypothesis becomes a constraint that redirects everyone else's search, rather than a private dead end that three other agents independently rediscover.

7:27Finn: That's the search-and-rescue model, right? Teams searching a wilderness grid don't just radio in "found him." They radio in "quadrant C-7 searched, nothing" — and a cleared quadrant is just as valuable as a sighting, because it redirects everyone else's effort. In isolated systems, every team re-searches the same empty quadrant.

7:49Juniper: And we'll see an actual trace from the experiments where exactly that happens — an agent posts a dead end, and the next agent skips straight past it to the real bug. Hold that thought. Second principle: the shared context has to stay compact, but without becoming lossy. There's a real tension here. If agents share their raw reasoning traces, you preserve everything, but every agent's context window blows up and so does the cost. If they share only short summaries, it's cheap — but summaries drop exactly the details you end up needing. DeLM's answer is a three-layer hierarchy, and the best way to picture it is a library. The shared context is the card catalog: tiny index cards, each about a hundred tokens, that any agent can scan in seconds. Each card points to a detailed dossier — a structured summary where every bullet point is pinned to a verbatim quote from the source. And only if you genuinely need exact wording do you request the original book from the closed stacks. Agents read the cards by default, and they unfold down to the dossier or the raw text only when a subtask actually demands it.

9:05Finn: The paper frames this with an operating-systems vocabulary, which I think is worth keeping because it's the actual design logic, not decoration. Your computer keeps only the working set — the memory pages a program is actively touching — in fast RAM, and fetches everything else from disk on demand. That's demand paging, and it's why memory cost scales with what you use, not with the total size of everything you might use. Here, the hundred-token gists are the always-resident working set. The summaries and raw documents are the disk. Unfolding is a page fault.

9:44Juniper: And there's a concrete example in the paper showing why the middle layer — the dossier — is load-bearing. A financial-analysis task: a document about PUMA contains two competing profit forecasts for twenty-twenty-four. An earlier range from the annual report, and a later, narrowed range from the half-year interim report. The index card gets the agent to the right neighborhood — this document has the forecast. The middle-layer summary does the crucial work: it identifies which source is later in time, and it explicitly flags that the exact figures are not in the summary and must be pulled from raw text. So the agent does one targeted deep pull and retrieves the precise range — six hundred twenty to six hundred seventy million euros — without ever loading the full report. Without that middle layer, you're triggering lookups from a lossy gist and hoping you land in the right place. With it, the card tells you which book, the dossier tells you which page, and you only open the book when you must.

10:50Finn: One refinement on the library image that matters for cost: when an agent checks out the book, it reads it at its own desk and returns it. The raw detail is not written back to the shared board — only the requesting agent sees it. One agent's deep dive doesn't pollute everyone else's view, and the catalog stays small. Okay. Third principle, Juniper — the moderator at the door. This is the one I want to push on, because "an LLM fact-checks another LLM" is a sentence that should make everyone a little nervous.

11:24Juniper: It should, and the paper's answer is to make the checking partly mechanical rather than purely judgment-based. Here's the move. When a source gets summarized into that middle-layer dossier, every bullet point is required to carry an anchor: the first and last several words of its supporting passage, copied verbatim from the source. So before the verifier does any semantic judgment at all, it can do exact string matching — does this quoted text actually appear, in order, in the document? Then a cheap model pass checks that the gist preserves the summary's claims and qualifiers. For reasoning traces, it checks that the note faithfully captures what the agent actually found, or failed at. Think of it as Wikipedia's citation-needed rule, enforced before publication. You cannot even save your edit unless every claim links to an exact quote in a real source, and a checker confirms the quote exists before the edit goes live.

12:24Finn: And the paper has a live capture of this gate doing its job, which is one of my favorite moments in the whole thing. A legal question-answering task, comparing two contract-law cases. An agent confidently writes that punitive damages were "reduced from three billion to one billion dollars" — and cites a summary that says only that there was a conditional affirmance with remittitur. No amounts. Anywhere. The model fabricated specific numbers that sounded exactly like the kind of thing a legal summary would contain. The verifier checked the claim against the cited evidence, found nothing supporting those figures, and bounced it at the door. The hallucination never entered shared state.

13:09Juniper: And the timing is the whole point. The authors argue that checking the final answer comes too late — in a shared-state system, errors are infectious. Once a false claim is on the board, every downstream agent builds on it, and by the time you check the answer, the fabrication has already shaped a dozen intermediate decisions. So verification has to happen at admission, not at the end. That's the operating-systems idea of admission control: gate what enters the shared resource, rather than cleaning up afterward.

13:43Finn: I'll flag the limit now and come back to it later: this gate checks faithfulness to the cited evidence, not truth. A claim that's wrong but consistent with its citation sails through. It's the same limit Wikipedia has — citation-checking verifies the source says what you claim, not that the source or your reading of it is correct. Hold that for the critique section.

14:07Juniper: Fair, and flagged. Let me close the design tour with how the loop actually runs, because there's one more clever choice hiding in it. The system initializes the task queue from the input problem. Agents claim ready tasks in parallel — tasks can declare dependencies, so the queue dispatches them in the right order. Results get compressed, verified, admitted. And when the queue runs empty, whichever agent finished most recently looks at the full shared board and decides: do we need more subtasks, or is it time to produce the final answer?

14:42Finn: A kanban board, basically. Workers pull tickets rather than waiting for assignments, and when the board empties, whoever just finished glances at the whole picture and decides whether to open new tickets or ship.

14:56Juniper: Right — so coordination decisions still happen. They're just made by whoever's at hand, with the full verified state in view, instead of by a dedicated controller trying to hold everything in one context window. No permanent boss. A rotating chair.

15:12Finn: Which is the honest framing, and we'll poke at the word "decentralized" later. But first — does it work? Because the design story is elegant, and elegant designs lose to ugly baselines all the time. Let me take the experiments, because the methodology here is actually better than it needed to be. Two benchmarks stressing opposite coordination styles. SWE-bench Verified: real GitHub bug fixes, where each individual attempt is mostly sequential — so they scale across attempts, running each task two or four times and asking whether attempts that share context beat attempts running independently. And LongBench-v2 multi-document question answering, which stresses the opposite mode: heavy parallelism within a single task, agents inspecting different documents at the same time. Two metrics, one breath: Avg@1 asks, if I run the system once, how often does it succeed? Pass@4 asks, if I run it four times, did any attempt land? Keep both in mind, because they're about to move in opposite directions in a really interesting way.

16:18Juniper: And the baseline construction deserves credit before the numbers.

16:22Finn: It does. The obvious objection to this whole paper is "of course sharing information beats not sharing information — you haven't shown the boss is the problem." So the authors built a strengthened version of their strongest centralized baseline, called AOrchestra-Parallel, which does let parallel attempts share information — but routed through the main agent, the way centralized systems do. That isolates the actual variable. It's not sharing versus not sharing. It's sharing through a boss versus sharing through verified state. And the headline numbers: on SWE-bench with Gemini 3 Flash, DeLM hits 65.7 percent single-attempt success, versus 56.4 for the best baseline. Call it nine and a half points. On Pass@4 it reaches 77.4 percent. And the cost figure is the one I'd put on a poster: about twelve cents per task, versus twenty-four to twenty-six cents for the agentic baselines. Ten points better, half the price.

17:23Juniper: And there's a footnote in the cost table that's almost unfair. Claude Code, run as a baseline on Gemini, came out around a dollar per task — because its prompt-caching format only works with Anthropic's own API, so all that caching benefit evaporates on another provider. So against that baseline, DeLM is arguably eight times cheaper in practice.

17:46Finn: Now the wrinkle I promised, because it's the most diagnostic single result in the paper. AOrchestra-Parallel — sharing through the boss — improved Avg@1 over fully independent attempts. Coupling the threads made each attempt a bit better. But it hurt Pass@2 and Pass@4. Worse than not sharing at all.

18:06Juniper: Because the attempts became correlated.

18:09Finn: Exactly. Four near-identical tries don't buy you four shots. When everything routes through one manager's context and one manager's framing, the attempts converge — they make the same choices and the same mistakes. More consistent, less diverse. Coordination through a boss homogenizes exploration. Coordination through shared state — at least in these experiments — doesn't. DeLM improved both metrics at once. The agents share facts and constraints, but nobody is shaping everyone's strategy through a single editorial voice.

18:44Juniper: Which brings us to why it wins — because the paper does something most benchmark papers don't bother with. It opens up actual execution traces and shows you the mechanisms. There are three, and they're the backbone of the empirical case. First: sharing failures. There's a bug in SymPy, the symbolic math library — a function called lambdify, which turns symbolic expressions into runnable Python, mishandles single-element tuples. The obvious suspect is the layer that prints expressions out as code. It's a red herring. Agent zero goes down that road, fails, and posts a verified FACT to the board: changing the printer did not affect the output. Agent one reads that note, skips the entire detour, and finds the real bug — a bit of manual tuple-joining code that bypasses the printer entirely and forgets the trailing comma. The dead end became a signpost. That's Finn's cleared quadrant, in a real trace.

19:46Finn: And the second trace is the one we opened the episode with — so let me pay off that cold open properly, because the paper ran the same Django problem through both architectures, and you get a perfect controlled contrast. In the centralized run, you saw what happened. The sub-agent found the constraint — do not merge these filter calls, it changes the meaning for many-to-many relations. The manager relayed it as a mild trade-off about reducing joins. Reopened the optimization. Failed. And notice what kind of failure that is. It's not the telephone game, where noise degrades a message over many hops. One hop was enough, and the damage wasn't noise — it was a well-meaning editor smoothing a hard constraint into a soft suggestion. Like the difference between passing a contract along verbatim and conveying it via someone's verbal recollection of it. In the DeLM run: same discovery, different fate. The constraint gets posted as a typed FAIL, together with the predicate that determines exactly when the optimization is safe. It sits on the board, unsoftened, in the discovering agent's own words. A later thread reads it and builds on it correctly. Nothing between the finding and the people who needed it.

21:02Juniper: Same discovery, different fate. That's the sharpest indictment of boss-mediated communication I've seen made concrete, because the centralized system didn't fail to find the answer — it found it and then overruled it.

21:16Finn: And it crystallizes a framing I think outlasts this particular paper. One school says coordination should be intelligent — a capable model deciding what to share, with whom, in what form, like a good manager. The other says coordination should be infrastructural — dumb, reliable, lossless shared state, like a database, with the intelligence pushed to the edges. The Django trace is a clean case of intelligent mediation doing harm precisely because it was intelligent. It exercised judgment. The judgment was wrong.

21:48Juniper: Third mechanism, and this one explains the cost numbers: compact handoffs. When an agent finishes a piece of work, it posts a patch summary — a single line compressing an entire multi-step debugging session: which file, what the idea was, and the evidence that the reproduction script now passes. Later workers reuse the result without wading through the command history and the failed edits. The paper has a beautiful single-task illustration of what that buys. The same task, solved correctly both ways: in isolation, it cost about forty cents. With compact sharing, twelve and a half cents. Same correct answer, roughly a third the cost — because nobody re-derived or re-read anything the board already knew.

22:36Finn: That's the SWE-bench side. What about the long-document side, where the coordination mode is completely different?

22:44Juniper: LongBench-v2, multi-document question answering — and here they tested across four different frontier model families: GPT, Claude, Gemini, and DeepSeek. DeLM posts the best average accuracy on all four, with gains over each family's best baseline ranging from about three and a half points up to nearly six. The consistency is the headline — this isn't a trick that exploits one model's quirks. And the closest prior system here is worth a sentence, because the contrast is instructive. ReadAgent, an earlier method, also compresses documents into gists and looks up originals on demand. But its lookups are triggered from lossy gists alone — no middle layer, no verification. And it does notably badly in this comparison, on one model family even worse than just handing the base model the raw documents. The middle dossier layer and the admission gate aren't garnish. They're the difference between a card catalog and a pile of sticky notes.

23:47Finn: Which the ablations confirm, right? When they start removing pieces?

23:52Juniper: Cleanly. Remove the verification gate and accuracy drops about five points — the single biggest contributor, which validates the whole admission-control thesis. Remove the hierarchical summarization, drops about two and a half. Two other findings worth one sentence each: the hundred-token gist size is enough, with longer gists buying nothing — and swapping in a much cheaper model to do the summarizing barely moves the needle. You don't need a frontier model to maintain the board. The intelligence lives at the edges; the infrastructure can be cheap.

24:29Finn: Okay. Now the part of the paper I respect most, which is — it loses. Section five, the authors pick a benchmark called OOLONG, where answers require exact counting and filtering over thousands of structured entries. Spreadsheet work, not essay work. And there's a rival paradigm built for exactly that: Recursive Language Models, RLM, where instead of reading the whole input, the model writes little programs to slice and query it through a code interpreter, recursing into sub-calls as needed. On OOLONG, vanilla DeLM loses. Fifty-three percent versus RLM's fifty-six. And the diagnosis is honest: natural-language notes on a shared board are an unreliable medium for row-level arithmetic. If the task is "count every entry matching these criteria," you want code execution, not prose summaries of prose.

25:23Juniper: So the natural question is whether the two compose.

25:26Finn: And they do, which reframes what DeLM actually is. Take RLM's code-executing workers, wrap them in DeLM's verified shared context and task queue — so the workers reason with programs, but coordinate through the board — and the hybrid scores sixty-four percent. Beats both parents. At forty cents a task, also the cheapest configuration of the three. DeLM isn't a competitor to reasoning systems. It's a coordination layer you can wrap around them. Reasoning engines below, verified shared state above.

26:00Juniper: That's the strongest version of the contribution, I think — not "our agents beat your agents," but "here's a communication substrate that improves whatever you run on top of it." So, Finn — you've been keeping a skeptic's file open this whole episode. Time to read it out.

26:18Finn: Six entries, roughly in descending order of how much they bother me. First, the branding. "Decentralized" is doing some marketing work in that title. There's still a one-time initialization that decomposes the task. When the queue empties, a single agent decides whether to spawn more work or finalize. And the verification gate itself is a global serialization point that every write passes through. What's genuinely removed is the persistent controller mediating every exchange — which matters! But the honest description is decentralized communication with rotating coordination, not the absence of central decision-making. Second, the one I flagged earlier: the gate is LLMs grading LLMs. The legal-case catch is a great anecdote, and the ablation shows verification helps on net. But the paper reports no error rates for the verifier itself — how often does it bounce a good claim, how often does it wave through a bad one? And structurally, it checks faithfulness, not truth. A claim that's wrong but consistent with its citation gets a hand-stamp at the door. The mechanism reduces error propagation. It cannot eliminate it, and the residual is unquantified.

27:36Juniper: That second one feels like the deepest issue to me, because the entire architecture's safety argument rests on the gate.

27:44Finn: It does — though I'd note the search-and-rescue analogy already contained the warning. A cleared quadrant is definitively empty. A posted FAIL from an LLM is "I tried this and it didn't work," which could itself be wrong, and then it prunes everyone's search tree incorrectly. Verification narrows that risk; it doesn't close it. Third entry: sample sizes. The LongBench evaluation is a hundred and twenty-five questions total, with some domains as small as fourteen or fifteen samples, and reported standard deviations as wide as plus-or-minus nine points in places. Several per-domain wins are within noise. The averages holding across four model families is genuinely reassuring — that's why I'm not dismissing the result — but the table looks more decisive than it is. Fourth: the strongest centralized baseline, AOrchestra-Parallel, is a control the authors built themselves. I praised the design earlier, and I meant it — it isolates the right variable. But centralized systems have a huge design space too. A boss with a really good context-management strategy might close some of this gap, and nobody's tested that.

28:57Juniper: And fifth would be the result we haven't mentioned yet, which the authors report straight: with a much stronger base model — Claude Opus 4.6 — the SWE-bench advantage nearly vanishes. Seventy-eight percent versus seventy-six point nine. About a point.

29:13Finn: Which raises the uncomfortable question hanging over the whole field of agent scaffolding: is this a permanent architectural lesson, or a patch for current model weaknesses? Coordination helps less when the individual worker rarely needs help. If frontier models keep getting better at long single trajectories, the value of the board erodes. And sixth, briefly: the pitch is that centralized coordination scales poorly as agent counts grow, but the experiments top out at four parallel attempts. Nobody's shown the crossover at sixteen agents, or sixty-four, or two hundred fifty-six — where I'd also expect DeLM to hit its own new failure modes. Shared-context bloat. Contention at the verification gate, which, remember, is a serialization point.

30:02Juniper: To the authors' credit, the paper carries a real limitations section, and it overlaps with some of that. They concede the verification overhead is nontrivial — they propose lighter-weight, possibly rule-based verifiers as future work, which is a quiet admission that running an LLM checker on every write costs real money. They concede the system inherits decomposition quality from its agents: split the task too coarsely and subtasks are under-specified, too aggressively and you spawn unnecessary agents. And they concede the prompts aren't universal — different model families may need tailoring to elicit the intended behavior. Plus the body text itself admits the trade at the heart of the design: all that upfront summarizing and verifying can cost more than lighter baselines in some long-context settings. It's a deliberate exchange — compute spent on reliability. Your critiques about sample size and scale, Finn, those the authors don't raise. That part's on us.

31:04Finn: Which is the job. So where does this land, big picture?

31:08Juniper: Two levels. Practically, it's unusually clean: better results for half the money, no training, no new models — purely a rewiring of how agents talk to each other. If you're running agentic coding or long-document analysis at scale, ten points and fifty percent is directly actionable, and the cost mechanism — compact verified notes instead of raw traces or repeated re-explanation through a controller — should travel beyond these benchmarks. The intellectual level is the one I'd bet stays with people. The field defaulted to mirroring human org charts — a manager delegates and integrates — and this paper argues the manager is the problem. Not because delegation is bad, but because one LLM context is a terrible message bus: it serializes, it summarizes lossily, and as the Django trace shows, it sometimes overrules correct findings. The alternative imports decades of distributed-systems thinking — shared state, admission control, working sets, demand paging — into agent design. The interesting frontier in multi-agent AI may be less about smarter agents and more about better memory architecture between them.

32:24Finn: There's a forward-looking application the authors name, which I'll flag as honestly speculative since they don't test it: automated research systems, where agents explore many hypotheses while digesting big literatures. A shared verified board would mean research agents stop re-reading the same papers, stop re-running the same failed analyses — and fabricated claims get filtered before they shape conclusions. If that vision pans out, an admission gate on shared scientific claims stops being an engineering nicety and starts being load-bearing for whether you can trust the output at all.

33:04Juniper: The authors' own closing line is the right note to end on, because it compresses the whole paper into one sentence: scalable multi-agent systems require not only more parallel agents, but a reliable communication substrate for sharing progress across them. The agents were never the bottleneck. The conversation between them was.

33:25Finn: The paper and some related reading are linked in the show notes if this caught you — it's a readable one, and the trace examples are worth seeing in full. And if you want the full transcript with every technical term tappable, plus the concept pages connecting this episode to others we've done on agents and long-context methods, that's all at paperdive.ai.

33:48Juniper: Thanks for spending your commute with us. This has been AI Papers: A Deep Dive — see you on the next paper.