Decomposition is not a safety property

63.97 percent, in a simulated wildfire

On 10 September 2026, Zhengran Ji, Jonathan Hyun and Boyuan Chen posted the strongest recent argument for building an agentic system out of many narrow roles rather than one large one. ORCH (arXiv 2609.11737v1, a preprint) reports human-designed organisations improving final score by 63.97% and execution efficiency by 74.29% over four prior embodied multi-agent frameworks, across 25 simulated wildfire-response missions in the CREW-Wildfire environment, with teams of up to 50 heterogeneous agents and eight large language models. Four axes: mission outcome, execution efficiency, exploration and computational resource use. Organisations the models designed for themselves managed 43.63% and 52.53%.

The mechanism is a structure, not a model: ORCH builds task-specific hierarchical organisations "by combining pooled interdependence for work that can proceed concurrently with sequential interdependence for work governed by prerequisite relationships". And, for anyone sizing a model budget, "Notably, collective performance was not monotonically determined by model scale."

One word keeps doing the work. CREW-Wildfire is a simulator: the fire "evolves dynamically through a cellular-automata process", the four agent classes are simulated vehicles — firefighters, bulldozers, drones and helicopters — and the author-contributions statement reads "Z.J. and J.H. designed simulations and performed experiments". The strings physical robot, real robot and hardware occur nowhere in the paper's rendered HTML [inference — the count is ours, the absence is the paper's]. "Embodied", in that title, means simulated embodiment. The 63.97% is a real result about organisation. It is not a result about robots.

Here is the argument. Narrow roles buy two things worth paying for: capability, which ORCH measures, and attributability — when something goes wrong you can name the agent that did it. They do not buy safety. The published evidence that they do is thin to absent, and what the evidence does support is a different noun: externality, a check the actor cannot author, sitting outside the thing being checked. That is the variable every safety result that works varies, not the number of boxes on the diagram. Our own Crew page carried the weaker version until 11 September 2026, and the last section is about what changed.

Three of the four papers here are not robots in a building and the fourth is not robots at all — ORCH a wildfire simulator, CoCoBench a household simulator, MAST seven software-agent frameworks, ChannelGuard an LLM pipeline with no embodiment — and every one of them is a preprint. What they share is the topology under test: a planner, workers, a verifier, and hops between them. Nobody has run this experiment on a machine in a building, ourselves included.

Every hop is a channel

ChannelGuard (arXiv 2607.19430, first posted 20 July 2026, cited here at v2, 10 August 2026, a preprint), by Hossain, Nipu, Faria, Ornee and Sheikh, opens its abstract with the sentence this article is organised around:

"Multi-agent LLM applications chain a planner, worker agents, a verifier, and a synthesizer, and every hop between agents is an unmonitored channel through which an adversary can smuggle instructions."

The title supplies the rest: Safe Models Do Not Compose into Safe Multi-Agent Systems. Decomposition does not remove attack surface; it manufactures surface, one boundary at a time. Draw the planner-and-workers diagram and count the arrows. Each is an interface with a format, a trust assumption and no observer.

The paper's own defence shows what gating a channel buys and what it does not. On a 2,100-trace evaluation across eight attack families, five defences and three model backends — Azure GPT-5, Anthropic Sonnet 4.5 and Anthropic Haiku 4.5 — ChannelGuard's tool-output gate blocks tool poisoning 30 of 30 at the application layer, identically across all three backends, halves prompt-injection attack success from 0.333 to 0.167, and preserves GSM8K accuracy exactly at 0.867. Then, in the same abstract: "White-box adaptive paraphrase evades every embedding gate, where a perturb-and-vote baseline does better." That second clause is the authors reporting that their own defence is not the best against that attack. It is the standard the rest of this piece has to meet.

The boxes, listed once and set asidePlanner · verification gate · named human · VLA policy · controllers · actuators · the robot's own safety functions, a deterministic chain no model output reaches and the thing that actually carries physical safety · governed site memory, core and short-term · other vendors' robots behind an Open-RMF or RoMi-H fleet adapter · the site's own systems, called as tools · the audit log.

Hops that pass a gate

Planner → verification gate: a proposed actionFive published checks, which another article owns and this one does not describe. On rejection nothing is dispatched, the robot holds its safe state, and the rejection returns naming the check that failed.

Verification gate → named human: anything consequentialA person authored by nobody in the system approves it, or it does not go.

Robot → core memory: a proposed changeRobots propose; a named human approves. Core memory changes no other way.

Verification gate → VLA policy and controllers: the dispatchThe only path by which anything reaches an actuator, and the reason the gate is worth having at all.

Four. Each is checked by something that did not author what it is checking.

Hops that pass nothing

Site systems → planner: tool outputsThe terminal operating system, the warehouse management system, the hospital information system, called as tools. Exactly the channel ChannelGuard's tool-output gate exists to cover.

Robot → short-term memory: the semantic observation streamObservations carried with pose and time, written by the robot. Nothing checks a write before the next planner reads it.

Short-term memory → planner: the site's current stateA blockage written by one robot is planned against by the next. The read is not verified; only what the planner proposes afterwards is.

Third-party robot → Crew: pose, state, itinerary, failure reason codesAnother vendor's software, over Open-RMF or RoMi-H, asserting where it is and what it is doing. Arbitration is built on these assertions.

Crew → third-party robot: a dispatched taskWhat the other vendor's stack does with it is outside our gate by construction.

Robot → robot: a cross-embodiment handoff, mediated by shared memoryA tote passed from one body to a different one at a lift lobby. Both halves of this have been published by other groups; the intersection has never been timed by anyone, ourselves included.

Six, on our own published design.

• A hop something outside the sender checks — the verifier, or a named human
• A bare hop: an interface with a format, a trust assumption and no observer
• The parts, which this figure deliberately treats as bookkeeping

What the boundary produces

Why Do Multi-Agent LLM Systems Fail? (arXiv 2503.13657, v1 17 March 2025, v3 26 October 2025, a preprint) is the field's fault catalogue. Cemri, Pan, Yang, Ion Stoica and colleagues at UC Berkeley open on the premise: "Despite enthusiasm for Multi-Agent LLM Systems (MAS), their performance gains on popular benchmarks are often minimal." Their taxonomy, MAST, names 14 modes in 3 categories, derived from 150 traces at an inter-annotator κ of 0.88 and applied across 1642 annotated execution traces from seven open-source frameworks — MetaGPT, ChatDev, HyperAgent and AppWorld among them — on coding, maths and general agent tasks. Across those seven, the failure rate runs from 41% to 86.7%.

One of the three categories, FC2 Inter-Agent Misalignment, holds six of the fourteen modes. The paper defines it: "Failures arise from a breakdown in critical information flow from inter-agent interaction and coordination during execution." A system with one agent has no inter-agent interaction. That category cannot exist until there is more than one agent, and its six modes account for 32.35% of annotated failures [inference — our sum of the paper's own per-mode figures].

The claim holds at the category level and not below it. The honest version names the mode that cuts against it. FM-2.6, reasoning-action mismatch, is the largest mode in FC2 at 13.2% of annotated failures, and the paper defines it entirely within a single agent: a "discrepancy between the logical reasoning process and the actual actions taken by the agent". FM-2.1, conversation reset, and FM-2.2, fail to ask for clarification, can be exhibited by one agent talking to a human. Exactly three of the fourteen mode definitions name another agent in their own text — FM-1.2, FM-2.4 and FM-2.5 [inference — our reading of the paper's Appendix A]. There is no honest count of the failure modes decomposition creates. Anyone shown one should ask which modes, then read their definitions.

CoCoBench (arXiv 2608.28266v1, 28 August 2026, a preprint) exists because the headline number hides this class of fault: 897 oracle-validated instances of executable household tasks, built around four coordination constructs — task allocation, sequential ordering, mutual exclusion and handoff coordination — across 11 MLLMs. Most benchmarks, its authors write, "summarize multi-agent behavior with overall task success rates, which can obscure coordination failures such as duplicated work, violations of ordering constraints, resource contention, and desynchronized handoffs", and they find that "strong overall performance does not imply balanced competence across different coordination types". Those fault classes have physical forms — duplicated work is two machines reaching for the same tote, a desynchronised handoff is an object released before anything is under it [inference — the benchmark is a household simulator and the corridor reading is ours] — and a success rate averaged over a fleet's week separates none of them from a bad day.

None of this makes MAST an indictment of the pattern, and the paper is careful to say so: "MAS failure is not merely a function of challenges in the underlying model; a well-designed MAS can result in performance gain when using the same underlying model", with a +9.4% success-rate improvement on ChatDev from better agent role specifications alone. Structure is worth engineering. It is not a safety argument.

• FM-1.1 Disobey task specification — 11.8 % — FC1 System Design, 5 modes
• FM-1.2 Disobey role specification — 1.5 % — names another agent in its definition
• FM-1.3 Step repetition — 15.7 %
• FM-1.4 Loss of conversation history — 2.8 %
• FM-1.5 Unaware of termination conditions — 12.4 %
• FM-2.1 Conversation reset — 2.2 % — FC2 Inter-Agent Misalignment, 6 modes
• FM-2.2 Fail to ask for clarification — 6.8 %
• FM-2.3 Task derailment — 7.4 %
• FM-2.4 Information withholding — 0.85 % — names another agent in its definition
• FM-2.5 Ignored other agent's input — 1.9 % — names another agent in its definition
• FM-2.6 Reasoning-action mismatch — 13.2 % — largest in FC2, defined inside one agent
• FM-3.1 Premature termination — 6.2 % — FC3 Task Verification, 3 modes
• FM-3.2 No or incomplete verification — 8.2 %
• FM-3.3 Incorrect verification — 9.1 %
• FC2: defined by inter-agent interaction
• Largest FC2 mode, and single-agent
• FC1 and FC3: no second agent needed

The cost nobody prices

The one vendor we have found publishing numbers on what this costs is Anthropic, in an engineering post of 13 June 2025 [single source — a vendor engineering blog reporting the vendor's own internal eval, on a research assistant, not peer-reviewed and not robotics]. A multi-agent system with Claude Opus 4 as lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on that eval. The bill: "agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats". Token usage alone explains 80% of the performance variance on BrowseComp — one of three factors that together explain 95%, which is the frame to keep whenever the 80% travels alone.

The same post names the shape of work that does not suit wide fan-out: "some domains that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today. For instance, most coding tasks involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time." A ward delivery run and a restroom cleaning cycle are both of that shape: one map, one site state, one picture of where the patients are, and a strict ordering between fetch, traverse, hand over and log [inference]. By the vendor's own criterion that is the wrong shape for a wide crew and the right shape for a small fixed one behind a single verifier. Anthropic has never said anything about robots; the criterion is theirs and the corridor is ours.

Where the safety case actually lives

Five results converge from five unrelated directions. Not one is an argument about how many agents you have.

ChannelGuard puts its gate on the channel between agents rather than inside either of them. MAST's third insight is headed Multi-Level Verification is Needed, and its frame is the stage and level of checks, not the arrangement of roles: "Current verifier implementations are often insufficient; sole reliance on final-stage, low-level checks is inadequate." Reading that as a result about where the check sits relative to the actor is ours [inference], and it is the weakest of the five convergences here.

The third is the one a careful reader will raise against this article, and the best result in the area. SafetyALFRED (arXiv 2604.19638v1, 21 April 2026, and the one result here that has cleared review — its arXiv comment records it accepted at ACL 2026 Findings), by Torres-Fonseca, Deng, Dai, Storks, Zhang, Mihalcea, Kennington and Chai, proposes in its §6 "a multi-agent framework that decouples hazard recognition from mitigation, offloading safety reasoning to a dedicated judge that feeds safety insights to the embodied agent", and reports that "Qwen 3 VL 32b's accuracy in mitigating appliance misuse hazards jumps from 0.7% to 71.1% when provided the safety judge's response". That is a decomposition improving a safety metric in an embodied benchmark, and it belongs in any honest version of this argument.

Five things travel with it. The environment is the ALFRED household simulator. The authors' own abstract calls the framework "slightly improving performance but not entirely resolving this misalignment". Most hazards survive the judge — "many hazards remain unmitigated even when the judge provides a correctly identified hazard", and with metadata the same model identifies hazards at 57.2% accuracy while mitigating 32.5% of them. And §7: "Even in our controlled and significantly simplified simulated environment, there is a huge performance gap between QA tasks and mitigation tasks." And the judge does not help everywhere: in the paper's Table 3, adding it drops the same model's mitigation of fire hazards from 71.2% to 43.7% and of unsanitary hazards from 24.3% to 8.1%, both at p < 0.01, while the average rises from 19.7% to 32.5%.

Read it for the variable and it stops being a counterexample. What changes between the two arms is not the number of agents; it is whether the safety reasoner sits inside the actor or outside it. The authors' own hypothesis is task interference — "the model's focus on completing the goal potentially diminishes the attention allocated to environmental monitoring". A planner optimising for completion stops watching, and a judge outside it recovers some of what the same model already knew.

The fourth looks most like a hardware result and is the strongest thing against a careless version of this piece. Managed Autonomy at Runtime (arXiv 2607.00334v1, 1 July 2026, a preprint) reports a 99.6% anomaly detection rate against 2.1% for the single-agent baseline, on a simulated three-agent UR5 assembly cell over 10,000 Monte Carlo episodes: 47.7× better. Its own results table settles what that is a result about: physical collision rate 0.0% in the baseline and 0.0% in the governed runtime. What improves is anomaly detection, and detection latency, 43.1 epochs down to 12.2; what the governed arm buys is an emergency-stop rate rising from 0.0% to 9.8%. The contrast is also not decomposition against monolith. It is a governance runtime, sitting beneath the agents, against no governance runtime. Quoting the 99.6% without the collision row would be the selective reading this article objects to — and the authors do not let the row be read carelessly in the other direction either: "Equal collision rates do not imply equal safety guarantees", because under the baseline "zero collisions is an artefact of the UR5 telemetry architecture: encoder control is unaffected by camera drift".

The fifth is the one with a real arm in it, and it is a guardrail, not a crew. RoboSafe (arXiv 2512.21220, v1 24 December 2025, cited here at v2, 26 December 2025, a preprint) puts an executable-predicate safety runtime outside a single VLM-driven agent — the guardrail "treats the embodied agent as a black-box system" — and reports hazardous actions down 36.8% against leading baselines across three simulated embodied-agent workflows. Its §6 physical-world section is a two-task case study on a 6-DoF myCobot 280-Pi driven by GPT-4o, in which the arm stops after picking up a knife or a wooden cube; it reports no comparative safety figure on hardware. One agent, one check outside it: the variable is externality again, and the agent count does not move.

So, the negative, with its bound in the same breath. As of 11 September 2026, searching the arXiv API by abstract and full-text fields across six query formulations, plus one web search, we found no published result reporting that decomposing an agentic system into narrow agents reduces physical-safety incidents on real robot hardware; every returned candidate was read at its abstract and the two closest were read in their bodies. Not searched: IEEE Xplore, the ACM Digital Library, Scopus, Web of Science, Google Scholar, PubMed, conference proceedings not mirrored on arXiv, non-English literature, manufacturers' internal safety reports and standards-body technical reports. arXiv plus one web search is the corpus, and that is the bound on the claim. Six formulations do not exhaust arXiv: a second pass on 12 September 2026, two web searches, found three further arXiv candidates the six had missed — RoboSafe above, 2606.31339 and 2604.20193 — and none reports it.

A group with a stake in the opposite answer says the same thing more usefully. AEROS (arXiv 2604.07039, v1 8 April 2026, cited here at v3, 25 May 2026, a preprint submitted to a journal) argues for single-agent architecture and still concedes: "A rigorous empirical comparison between single-agent and multi-agent architectures on the same task remains an important open question." Nobody is winning this on evidence, including the people who would like to.

Which brings it back to our own page. Until 11 September 2026, "One agent, one narrow job. One crew, one outcome. One human, one final approval." sat on the Crew page under a heading that read Safety design. It now sits under How the crew is organised, and the paragraph that follows files it under capability before the next one opens: "It is not a safety argument, and we should not present it as one." Safety design opens differently now — "What carries the safety case is not the shape of the crew. It is the boundary." The ORCH citation on the same page gained its simulation clause a day later, on 12 September. Crew is in development and, in the page's own words, "It is not running on any site": we have measured nothing on a machine, and no number in this article is ours.

For anyone being shown one of these diagrams: the crew shape answers a capability question and is an org chart everywhere else. The questions that reach the safety case are which checks the actor cannot author, where each one sits relative to the thing it checks, and what is watching the hops in between. On our own design the outermost check is not the verifier at all. It is the robot's own safety functions, which the Crew page keeps on the robot, in a chain no model output reaches; that chain is what carries physical safety, and the verifier sits inside it. The checks we publish, and the antecedents they rest on, are a separate argument, made here. This piece is about the arrows.