Multi-Agent Orchestration — Deep Dive

Debate Agent Router uses two specialist agents and a judge.

# Judge Agent gamma reads the debate state and outputs a sufficiency label,
# an adjudicated risk level, and the selected expert.
# The selected expert follows the adjudicated Low/Medium/High routing signal.
# Low, Medium, and High correspond to Qwen3-VL-2B, Qwen3-VL-4B, and Qwen3-VL-8B.

Imagine a kitchen where a single chef is responsible for every dish: chopping, grilling, plating, even managing the pantry. When the menu is simple, that works fine. But as orders pile up and dishes become complex, the chef gets overloaded, forgets which ingredient is where, and starts making mistakes—burning steaks or using the wrong sauce. That’s exactly the problem this subsystem solves. It’s for splitting a big, confusing job among a team of dedicated specialists so each can focus on what they do best.

In practice, instead of giving one agent a huge set of tools (like a chef with too many knives and pans), the system assigns separate agents to handle specific roles. One agent might evaluate safety risk, another provides a second opinion, and a third judge reads both arguments to make a final decision. The source describes concrete patterns: a Subagent pattern where a main agent delegates tasks to helper agents as tools; a Handoff pattern where the conversation gets transferred directly to a specialist; and a Router that instantly classifies incoming work and sends it to the right expert. Each pattern uses a different number of calls—for example, Subagents take four calls per task because results must flow back through the main agent, while Handoffs use just two.

The trickiest part is that splitting work adds overhead, and choosing the wrong pattern makes things worse. For instance, Subagents are “stateless by design”—each new request starts the same flow from scratch, so if the same customer orders twice, the agent doesn’t remember the previous order and redoes all four calls each time. A Handoff pattern, on the other hand, keeps conversation context, so the second order only needs two calls. Without this careful splitting, a single overburdened agent with too many tools would lose track of which directory it is in, pick the wrong tool, and deliver a useless or even dangerous result—exactly like a burnt steak or a wrong sauce.

The subsystem’s ordered mechanism begins with a design principle from the Building effective agents article: the agent-computer interface (ACI) is first crafted to require a full absolute location reference, eliminating the prior relative-location tool that caused the agent to lose track of its directory. After this ACI refinement, the system splits the work across focused specialists using a Debate Agent Router from the autonomous driving paper. The Base VLM/Question Generator first produces perception, planning, and prediction questions; the router then dispatches each question to the appropriate expert agent. On failure—for instance if the router cannot match a question to a domain expert—a traceable routing log is produced, allowing operators to inspect the decision.

The invariant the design preserves is traceable expert-routing, explicitly named as such in the source. This guarantee means every routing decision is inspectable, addressing the opaqueness of traditional latent-feature gates. The ACI change independently upholds the simpler invariant of maintain simplicity and prioritize transparency from the Anthropic article—by requiring absolute references, the tool’s behavior is fully predictable and the agent’s state is never ambiguous, enforcing a clear “write boundary” on the agent’s location awareness.

The key trade-off is rejecting the obvious alternative of a single monolithic agent with many tools. That alternative would rely on complex frameworks or opaque Mixture of Experts routers that hide reasoning failures behind latent gates. The Building effective agents article explicitly warns that “agentic systems often trade latency and cost for better task performance,” and the monolithic agent would compound errors from relative-path confusion. By splitting work via the Debate Agent Router and enforcing absolute references through the ACI, the design accepts the cost of additional infrastructure (a separate router and specialist agents) but avoids the far higher cost of non‑inspectable, error‑prone tool usage that would undermine reliability and require extensive debugging.

A concrete failure mode arises when a relative-location tool is accidentally reintroduced or bypassed. An operator would see repeated errors in the agent’s logs such as “directory not found” or “invalid relative path” entries, indicating the agent has lost track of its current directory. In the router’s domain, if the Base VLM/Question Generator produces a question that falls outside the defined expert domains (e.g., a safety question routed to a planning expert), the operator would observe a traceable routing assignment with low confidence or an explicit misrouting flag in the router logs, signaling a question‑generation failure that needs to be addressed through further ACI iteration.

Failure 1: Directory Tracking Loss Due to Relative Location Reference

• Trigger: The agent is handed a tool that asks for a relative location reference instead of an absolute one.
• Guard: The designers changed the tool to always require a full absolute location reference — this is a design-time guard, not an exception handler.
• Posture: fail‑soft — the agent continues to operate but produces frequent errors (the source says “leads to frequent errors”).
• Operator signal: Frequent errors in any operation that depends on directory awareness; the agent’s output shows incorrect file paths or stale directory context.
• Recovery: No automatic retry or fallback in the source. The manual step is to redesign the offending tool to enforce an absolute reference, as the designers did.

Failure 2: Lower Quality Outcomes from Tool Overload

• Trigger: A single agent is given “too many tools” to manage.
• Guard: No guard is shown in the source for this failure mode. The text only states that “a single agent with too many tools often produces lower quality outcomes” without describing any runtime protection.
• Posture: fail‑soft — the agent continues to operate but delivers degraded quality.
• Operator signal: The operator observes “lower quality outcomes” — for example, inconsistent or suboptimal decisions across tasks.
• Recovery: The source suggests a design‑level remedy: “splits the work across focused specialists.” This is a manual re‑architecture, not an automatic recovery.

Failure 3: Relative Reference Tool Error (Distinct Trigger from Failure 1)

• Trigger: A tool that specifically “asks for a relative location reference” is invoked.
• Guard: The same design change — requiring a full absolute location reference — prevents this failure.
• Posture: fail‑soft — the agent can still make calls, but each call using that tool “leads to frequent errors.”
• Operator signal: Repeated error messages or incorrect paths when the tool is used; the error is tied to the relative reference pattern.
• Recovery: The tool must be redesigned to require an absolute reference; no automatic retry is documented.

Failure 4: Safety Risk Evaluator Agent Makes an Erroneous Assessment

• Trigger: The safety risk evaluator agent (one of the focused specialists) is given a scenario with ambiguous or misleading data.
• Guard: No guard is mentioned in the source for this agent’s individual error. The framework relies on a second assessment and a judge agent, but no validation or exception handler for the evaluator itself is specified.
• Posture: fail‑soft — the evaluator’s incorrect assessment is passed forward; the system may still continue because the judge agent will read both arguments.
• Operator signal: The operator would see a discrepancy between the safety risk evaluation and the second assessment, or the judge’s final decision might be inconsistent.
• Recovery: No automatic recovery is shown. The operator may need to manually inspect the arguments or re‑run the evaluator with corrected input.

Failure 5: Judge Agent Fails to Reconcile Conflicting Arguments

• Trigger: The judge agent receives two contradictory arguments from the safety evaluator and the second assessment agent.
• Guard: No guard is presented in the source for the judge’s reconciliation failure. The system has no retry, fallback, or validation on the judge’s output.
• Posture: fail‑soft — the judge produces a possibly flawed final decision, and the pipeline continues; the output is unreliable but does not abort.
• Operator signal: The final decision may be logically inconsistent or not match either assessment; the operator notices a mismatch in the chain of reasoning.
• Recovery: No recovery is defined in the source. A manual review of both arguments by a human is required to correct the judge’s output.

The Judge Agent Router reads the debate state from two evidence-producing agents, outputs a sufficiency label and adjudicated risk level, and selects the appropriate Qwen3-VL expert based on low/medium/high routing signals.

class JudgeAgentRouter:
    def __init__(self, base_vlm_question_generator):
        self.question_gen = base_vlm_question_generator
        self.routing_trace = {}

    def judge(self, debate_state):
        # debate_state contains risk_assessments from agent_alpha and agent_beta
        # each with evidence sets (referenced bounding-box indices)
        sufficiency_label = self._evaluate_sufficiency(debate_state)
        adjudicated_risk_level = self._adjudicate(debate_state)  # Low/Medium/High
        selected_expert = {
            "Low": "Qwen3-VL-2B",
            "Medium": "Qwen3-VL-4B",
            "High": "Qwen3-VL-8B"
        }[adjudicated_risk_level]
        self.routing_trace = {
            "sufficiency_step": len(debate_state),
            "expert": selected_expert,
            "risk_level": adjudicated_risk_level,
            "referenced_box_indices": debate_state["evidence_indices"]
        }
        return sufficiency_label, adjudicated_risk_level, selected_expert

Think of a restaurant kitchen where orders come in—a head chef quickly reads each ticket and decides which station, like the grill or salad prep, should handle it. This system is for directing each task to the specialist best suited for that specific type of work, ensuring efficiency and quality. The router reads every incoming job, classifies it into a category, and sends it to the right downstream process—for example, a customer service router might direct refund requests to billing and technical questions to support. This classification can be done by an LLM or a traditional algorithm, and the key mechanism is separation of concerns: each specialist is optimized for its own kind of input, so the router prevents mixing tasks that require different expertise. Without this, optimizing a single system for all inputs would hurt performance on some of them.

The non-obvious rule is that the router must not do the specialized work itself—it only decides where to send the task, leaving the actual handling to the expert at that station. The deep reason this matters is that a router can only handle classification accurately when the categories are distinct and clearly separable; if the input is ambiguous, the wrong specialist might be chosen. Without this routing workflow, a simple question could get routed to a massive, slow model, wasting time and money, while a complex problem might end up with a cheap, weak model that gives a wrong answer—a failure a beginner would feel as frustratingly slow or useless responses.

The subsystem operates as a well-ordered pipeline driven by structured multi-round debate. First, the two persona agents—Zealot (aggressive bull) and Reaper (aggressive bear)—each independently produce a risk assessment accompanied by supporting evidence sets. Second, the router agent named Fulcrum (the moderating chief investment officer) reads the full debate state, including both assessments and the arguments exchanged during the debate rounds. Third, Fulcrum outputs a sufficiency label (indicating whether the evidence is adequate) and an adjudicated risk level (the moderated risk score) while also selecting the expert specialist who will execute the task. The chosen expert then follows the routing signal. Fulcrum retains the global picture because it sees all the evidence from Zealot and Reaper, but it must not itself decide the evidence—that responsibility remains strictly with the two debating agents.

The invariant the design preserves, named from the source, is decision stability. The paper reports that “debate structure itself provides decision stability rather than prompt memory.” This means the system guarantees that the final routing and risk adjudication are grounded in the competitive interplay of evidence between the two persona agents, not merely in what a single model recalls from its training. The guarantee holds as long as the structured debate process is followed; Fulcrum’s role is to moderate and adjudicate, not to introduce new evidence or override the debate outcome arbitrarily.

The key trade-off is between decision stability and the risk of systematic persona bias. The design explicitly rejects the alternative of relying on a single agent’s base model priors or on simple prompt memory—the paper notes that “distilling behavioral finance principles directly into agent prompts produces qualitatively superior reasoning compared to relying on base model priors.” The cost this rejection avoids is the tendency for monolithic agents to produce unreliable or ungrounded output, as highlighted in the earlier reliability review (where “self-correction without external feedback shows inconsistent reliability”). However, the trade-off introduces a new failure mode: one agent can consistently dominate through rhetorical structure rather than evidence quality. An operator would observe this failure as a persistent pattern where Zealot’s position always prevails in Fulcrum’s adjudication, even when Reaper’s evidence objectively stronger. The concrete signal is that the sufficiency label becomes a formality and the adjudicated risk level consistently mirrors Zealot’s initial assessment, indicating that the debate structure has been captured by rhetoric rather than content.

A concrete failure mode, therefore, is systematic persona bias emerging in the debate loop. The operator would see that across multiple tasks, Fulcrum’s sufficiency label and risk level correlate almost perfectly with one agent’s output, and the losing agent’s evidence sets are consistently ignored or downweighted. The paper explicitly warns that “systematic persona bias can emerge where one agent consistently dominates through rhetorical structure rather than evidence quality.” This failure is detectable by monitoring the distribution of adjudicated risk levels relative to each agent’s initial assessment over a batch of tasks. If, for example, Reaper’s bearish evidence never sways Fulcrum away from Zealot’s bullish recommendation, the operator would flag a breakdown in the debate’s intended balancing mechanism. The root cause is not a model outage but a structural property of the design: without external calibration or cross-checking, the rhetorical framing of the dominant agent can overwhelm the evidentiary contribution of the other.

Failure 1: The router selects a specialist that has no capacity or fails to execute the subtask.

• Trigger — The central LLM (orchestrator) decomposes the task into a subtask that does not match any available specialist’s capability, or the specialist model itself produces a hallucinated or incoherent response.
• Guard — “guardrails” (from the source’s parallelization example where one model instance screens queries for inappropriate content) – but no guard explicitly checks specialist selection validity; the source merely describes a separate screening process for content, not for routing decisions. No retry or fallback is shown.
• Posture — fail-soft: the router continues to the next task, but the result for this task is lost or corrupted. The source does not show a hard abort mechanism.
• Operator signal — silent absence of output for that task; no log line or metric is defined in the source.
• Recovery — no retry count or backoff is specified in the source; the operator would need to manually re-route the task.

Failure 2: The two agents produce risk assessments that contradict each other on a key evidence point, causing an inconsistent debate state.

• Trigger — One agent’s model variant (e.g., “GPT-OSS-120B” vs. “Qwen3-VL”) yields a different inference than the other, or a witness code-ablation effect (like the “state_detail” / “proprietary_code” leakage in the source) distorts its evidence set.
• Guard — “voting” (the “four-family vote” from the source’s “Drilling+HSE+Council” experiment) that aggregates multiple assessments. The guard is invoked only if the router reads the vote output before making its decision.
• Posture — fail-soft: the router still produces a sufficiency label and adjudicated risk level, but the vote tie‑breaker may be unreliable (the source notes “the paired test is not significant at three seeds (p = 0.22)”).
• Operator signal — the macro‑F1 metric (e.g., “0.442 ± 0.019” on the WITSML‑applicable subset) drops, or the “B1” score falls below an expected threshold.
• Recovery — no retry mechanism is described; the operator would need to inspect the raw debate text and manually override the vote.

Failure 3: The router’s sufficiency label (e.g., “enough evidence” vs. “need more”) is incorrectly set, causing a premature decision.

• Trigger — The router’s own hallucination (as studied in the source’s “TruthfulQA” and “HallucinationEval” benchmarks) misinterprets the debate state; the source states “self‑correction without external feedback shows inconsistent reliability”.
• Guard — “chain‑of‑thought (CoT) prompting” (from the source’s hallucination survey) is described as a structured prompt strategy that reduces hallucinations in prompt‑sensitive scenarios. However, the source does not specify that CoT is applied to the router’s decision step; it is only a general recommendation.
• Posture — fail‑hard: if the label is “sufficient” but reality is not, the expert acts on wrong evidence; if the label is “insufficient”, the router may abort the task (no further processing). The source does not define a fallback for an incorrect label.
• Operator signal — a spike in the RMSE metric (e.g., “RMSE reduced by 28.8%” in the tunnel‑fire study) could indicate degraded outputs, but no direct log line exists.
• Recovery — no retry or backoff is shown; the operator must re‑run the entire routing pipeline with a modified prompt.

Failure 4: The router fails to collect results from the chosen expert because the expert’s output is not returned or is malformed.

• Trigger — The specialist agent crashes (e.g., a timeout or memory limit), or the orchestrator–workers channel loses the result.
• Guard — “evaluator‑optimizer” workflow (from the source) where one LLM call generates and another evaluates – but this is a different workflow, not a guard for result collection. No retry or fallback is defined in the source.
• Posture — fail‑closed: the router cannot proceed without the expert’s output; the task is abandoned. The source describes “calibrated refusal” in the reliability‑gap framework but does not implement it here.
• Operator signal — silent absence of a “result” field in the router’s output; no metric is logged.
• Recovery — no automatic retry; the operator must re‑submit the task.

Failure 5: The router overrides the two agents and decides the evidence itself, violating the design principle.

• Trigger — The router’s prompt lacks the explicit instruction to not decide evidence, or the model’s inherent bias (the source’s “Model Variability (MV)” metric) causes it to generate evidence even when not requested.
• Guard — “parallelization” (from the source’s example of “sectioning” where one model instance handles guardrails and another handles core response) could separate concerns, but the source does not show such a guard for the router. No explicit guard exists.
• Posture — fail‑soft: the router still produces an output, but the evidence generated by the agents is ignored, defeating the purpose of the debate.
• Operator signal — the “Prompt Sensitivity (PS)” metric would be low, but no specific log line is provided.
• Recovery — the operator must inspect the router’s output for generated evidence and manually revert to the agents’ evidence set; no automatic recovery path is defined.

Handoff with debate: two agents produce risk assessments, judge adjudicates and routes to expert.

alpha = {"risk_level": "medium", "evidences": ["box_1","box_2"]}
beta = {"risk_level": "low", "evidences": ["box_3","box_4"]}
debate_state = {"alpha": alpha, "beta": beta}
# Judge gamma reads debate state and outputs
sufficiency_label = "sufficient"
adjudicated_risk_level = "medium"  # adjudicated from debate
selected_expert = {"low": "Qwen3-VL-2B", "medium": "Qwen3-VL-4B", "high": "Qwen3-VL-8B"}[adjudicated_risk_level]
routing_trace = {"t_s": 1, "e_k": selected_expert, "r_hat_k": adjudicated_risk_level, "referenced_box_indices": ["box_1","box_2","box_3","box_4"]}

Imagine a relay race where each runner passes a baton that also carries a notebook of their progress—so the next runner knows exactly what’s been done and what still needs to happen. This handoff system lets one agent directly pass a task to another in the middle of work, carrying the important context along with it, so the overall effort stays smooth and coordinated.

In practice, the first agent works on its part and then hands off the task along with a record of its decisions. The source shows that this handoff pattern is especially efficient for single tasks, using only three calls total—much leaner than other approaches like subagents, which need an extra call because they are stateless and must re‑establish context each time. The handoff keeps the history alive, so the next agent can immediately build on the previous work without repeating steps or losing track of what has already been decided.

The trickiest detail is that the handoff must carry just the right context to prevent the system from forgetting intermediate reasoning. If the context were lost—for example, if the baton were passed without the notebook—the receiving agent would have to start fresh, missing the earlier analysis. Without this handoff mechanism, agents would effectively run in isolation, forcing repeated work or causing contradictory conclusions, much like a relay runner who receives an empty baton and has no idea what lap they are on.

The handoff mechanism in this multi-agent debate router begins with two agents—alpha and beta—each independently producing a risk level assessment accompanied by an evidence set consisting of referenced bounding-box indices. These outputs form the Debate State. The Judge Agent gamma (Router) then reads that Debate State and produces three outputs: a sufficiency label, an adjudicated risk level, and the selected expert. The Judge's routing trace records the sufficiency step t_s, the selected expert e_k, the adjudicated risk level r_hat_k, and the referenced box indices that were part of the original evidence. The selected expert is then dispatched according to the adjudicated Low/Medium/High signal (mapped to Qwen3-VL-2B, Qwen3-VL-4B, or Qwen3-VL-8B respectively). If the Judge cannot determine sufficiency—for example, if the debate state lacks sufficient evidence—the trace would record an incomplete sufficiency step t_s, and the system would log a missing adjudicated risk level, causing the handoff to fall back to a default expert or pause for operator review.

The design preserves a traceability invariant: every handoff decision is linked to a complete routing-trace record containing the sufficiency step, the selected expert, the adjudicated risk level, and the referenced box indices. This ensures that the routing decision is inspectable and that the evidence motivating the handoff can be audited post-hoc. The invariant is not about exactly-once execution but about full traceability of the adjudication chain—a core requirement for the structured-input Autonomous Driving VQA context described in the source.

The key trade-off is replacing a single supervised router with a two-stage debate-and-adjudicate architecture. The obvious alternative rejected is a supervised router that would use a single controller to pick an expert based solely on the input query, without any intermediate debate or evidence-based adjudication. That alternative would be simpler and faster but would forfeit inspectability: the supervised router’s decisions are opaque, providing no evidence sets or sufficiency labels. By adopting the debate structure, the system accepts higher latency and computational overhead in exchange for a recordable, evidence-grounded decision that can be verified by operators. The cost avoided is the inability to audit why a particular expert was chosen, which is critical for safety in Autonomous Driving.

A concrete failure mode occurs when the Judge Agent gamma fails to produce an adjudicated risk level r_hat_k because the two agent assessments (alpha and beta) are contradictory or both lack confidence—for instance, one agent assigns "Low" risk with sparse bounding-box indices while the other assigns "High" with no reliable evidence. In this case, the routing trace would record a sufficiency step t_s with a null or "Insufficient" label, and the selected expert e_k might be omitted or set to a fallback. The operator would see a routing trace with missing t_s, null r_hat_k, and incomplete referenced box indices—a clear signal that the debate handoff could not reach an adjudicated decision, requiring manual intervention or a default expert selection.

Judge Agent Misclassification

• Trigger — The debate state (outputs from agents alpha and beta) is ambiguous, contains contradictory risk assessments, or evidence is insufficient for the judge to produce a correct sufficiency label or adjudicated risk level.
• Guard — No guard is shown in the source. The Judge Agent gamma (Router) reads the debate state and outputs directly; no validation or fallback mechanism for classification correctness is described.
• Posture — Fail-soft. The system continues with an inappropriate expert selection, degrading downstream question-answer quality. The source evaluates quality with BLEU-4, ROUGE-L, and SPICE metrics, so the misclassification manifests as poor text-overlap scores rather than an abort.
• Operator signal — Low values for BLEU-4, ROUGE-L, or SPICE; or an unexpected selected-expert distribution, such as e_k shifting to an expert not aligned with the prompt‑defined risk signals.
• Recovery — No automatic retry or fallback is specified. Manual inspection of the routing‑trace fields (t_s, e_k, r_hat_k, referenced box indices) and re‑execution of the handoff with adjusted prompts would be required.

Expert Agent Unavailability

• Trigger — The selected expert (one of Qwen3-VL-2B, Qwen3-VL-4B, or Qwen3-VL-8B) is unreachable, has crashed, or times out after the judge designates it in the handoff.
• Guard — No guard is shown in the source. There is no fallback expert, retry loop, or fallback‑to‑default‑expert mechanism described.
• Posture — Fail-hard. The handoff cannot complete because the chosen expert never receives the adjudicated risk level and referenced box indices. The system aborts that routing branch.
• Operator signal — An absence of the expected expert response, recorded as a missing or zero‑length latency measurement for that expert, and a routing trace that shows e_k but no subsequent output.
• Recovery — No automatic recovery is shown. Manual restart of the failed expert process and resubmission of the handoff context (sufficiency step, risk level, box indices) is necessary.

Handoff Context Corruption

• Trigger — The context carried in the handoff—specifically the sufficiency step t_s, adjudicated risk level r_hat_k, and referenced box indices—becomes garbled or lost due to serialization errors, network corruption, or buffer overflow during the transfer from the judge to the selected expert.
• Guard — No guard is shown in the source. The source mentions only that the routing trace records these fields, not that the expert validates the received context.
• Posture — Fail-soft (if the expert can proceed with partial data) or fail-hard (if the expert refuses to process missing critical fields). The source does not define the expert’s requirement, so the more severe interpretation is assumed: the expert likely needs all context to produce a risk assessment, causing a failure in subsequent reasoning.
• Operator signal — The routing trace would show an incomplete or corrupted entry (e.g., missing t_s, r_hat_k, or box indices). The expert’s output may be absent or contain errors in the VQA answer.
• Recovery — No automatic retry is specified. Manual comparison of the trace with expected values and re‑triggering the handoff after clearing the corruption.

Routing Trace Recording Failure

• Trigger — The logging subsystem responsible for writing the routing‑trace fields (t_s, e_k, r_hat_k, referenced box indices) fails due to a disk‑full condition, permission error, or concurrent write conflict.
• Guard — No guard is shown in the source. There is no explicit exception handler, retry, or fallback log destination described for the trace recording.
• Posture — Fail-soft. The handoff itself proceeds, and the system continues to process the selected expert’s response. However, the inspectable audit trail is lost, degrading the system’s ability to evaluate routing behavior offline.
• Operator signal — The routing trace is empty or missing fields that the trace is defined to contain (t_s, e_k, r_hat_k, box indices). The operator would observe an absence of these fields in the log.
• Recovery — No automatic recovery is shown. Manual inspection of system logs, disk space remediation, and re‑execution of the handoff to regenerate the trace is required.

Debate State Incomplete

• Trigger — Agents alpha or beta fail to produce their prompt‑defined safety risk level assessments or fail to output the referenced bounding‑box indices, leaving the debate state partially empty.
• Guard — No guard is shown in the source. The Judge Agent gamma (Router) reads the debate state without validation of its completeness; it will attempt to process whatever is provided.
• Posture — Fail-soft. The judge proceeds with missing evidence, likely producing an incorrect sufficiency label or adjudicated risk level. The selected expert then acts on weak or missing context, degrading overall answer quality.
• Operator signal — The routing trace will show missing referenced box indices. Text‑overlap metrics (BLEU-4, ROUGE-L, SPICE) will be lower than expected, and the selected‑expert distribution may shift unexpectedly.
• Recovery — No automatic recovery is specified. Manual re‑run of the failing agent (alpha or beta) and re‑initiation of the debate handoff is necessary.

Subagents pattern: main agent coordinates subagents as tools.

Think of a head chef in a busy kitchen who, rather than cooking every dish alone, breaks a vast banquet order into small plates and hands each to a specialized line cook. This subsystem is for orchestrating multiple helpers so that a big, shifting workload gets completed smoothly. The lead agent, like that chef, uses a model of the kitchen's state—what each cook has done and what orders remain—and when a new rush arrives or a cook drops a dish, it reasons about how to split the remaining tasks differently and delegates again. In practice, this orchestration system uses patterns like subagents, where the main agent coordinates specialized workers as tools, relying on context engineering to ensure each helper sees only the relevant information for its small job. Deeper still, the lead agent depends on careful state management to track progress across all helpers, because if one cook fails, the chef must reassign that part without restarting everything from scratch. Research emphasizes that this adaptive decomposition, guided by a model of the environment, improves error recovery and decision stability when goals shift. Without this subsystem, a single failure in one worker would cascade, leaving the entire task stuck because no coordinator was watching the big picture and rerouting work around the snag—the kitchen would grind to a halt whenever anything went wrong.

In the described subsystem, the mechanism proceeds in a structured order: first, the lead agent applies state-management granularity to capture the current environment state. Next, it adopts a hierarchical coordination topology to decompose the overarching task into smaller sub-tasks, with each sub-task delegated to worker agents. The system optionally activates a dynamic–adaptive control axis, enabling the lead agent to re-plan or adjust task structures as goals shift or disruptions arise. On failure, the design invokes documented failure-recovery options, such as the iterative verification patterns that ablation studies identify as the primary contributor preventing error propagation. This ordered sequence ensures that state tracking precedes decomposition, and that adaptive re-planning or recovery only occurs when the initial plan fails, maintaining a clear operational flow.

The invariant this design preserves is state-management granularity, defined as the precise tracking of environmental changes and agent states across the multi-agent system. This guarantee ensures that the lead agent’s reasoning about task decomposition remains grounded in an accurate representation of current conditions, rather than relying on stale or aggregated snapshots. The system upholds this invariant by encoding semantic context via mechanisms like behavior loop and language loop from the dual-loop architecture, where the language loop updates external latent vectors by reflecting on the semantic embeddings of generated text. The design ensures that even as the environment changes, the state management granularity remains fine enough to support reliable hierarchical planning.

The key trade-off is between the added complexity of hierarchical decomposition with dynamic adaptation and the simpler alternative of a static, centralized coordination topology. The design rejects a flat, non-adaptive approach because it would lack the failure-recovery options needed in dynamic and uncertain environments. By embracing hierarchical coordination and the dynamic–adaptive control axis, the system gains error recovery and decision stability, as evidenced by gains in tasks requiring sustained state tracking (e.g., Turing machine simulation improving from 9% to 92% when iterative verification is used). The rejected alternative—static centralized control—avoids the cost of catastrophic error propagation: without these mechanisms, baseline approaches fail catastrophically because they cannot recover from cascading mistakes. The system pays the cost of higher token consumption and orchestration overhead but avoids the far greater cost of unrecoverable task collapse.

A concrete failure mode occurs when state-management granularity degrades—for example, when the language loop fails to update latent vectors correctly after a disruption. The signal an operator would see is a sharp decline in accuracy on sustained state tracking tasks: the performance on long division, which normally reaches 94% with iterative verification, would fall to 16% as error propagation sets in. The operator would observe logs showing that the lead agent repeatedly calls for re-decomposition without progress, or that worker agents produce inconsistent outputs because their semantic context encodings no longer match the actual environment state. This failure mode matches the ablation result where removing iterative verification leads to catastrophic failure, with the accuracy metric providing an unmistakable operational signal.

Hallucination

• Trigger — The lead agent generates content not supported by grounded evidence, often due to insufficient retrieval or model uncertainty.
• Guard — calibrated refusal (from the reliability article) — the agent refuses to generate output when it cannot ground the response.
• Posture — fail-closed: if the guard triggers, no output is emitted; otherwise the hallucination is output (fail-soft).
• Operator signal — absence of output or explicit refusal message when guard activates; otherwise hallucinated text in the response.
• Recovery — operator can retry with a more constrained or source-augmented prompt; if hallucination occurs, manual fact‑checking is required.

Self‑correction inconsistency

• Trigger — The agent attempts to correct its own output without receiving external feedback.
• Guard — none; the source explicitly notes that self‑correction without external feedback shows inconsistent reliability.
• Posture — fail‑soft: the corrected output is produced but may be less reliable than the original.
• Operator signal — observed as inconsistent reliability across multiple runs; no specific log line is defined.
• Recovery — operator should provide external feedback or use a different correction strategy; fallback to a human‑in‑the‑loop process.

Attribution error

• Trigger — The agent incorrectly identifies or omits the source of a claim.
• Guard — attribution (listed as a dependency of RAG reliability) — but the source does not define an executable guard for this failure.
• Posture — fail‑soft: the output is produced but with wrong or missing attribution.
• Operator signal — an incorrect or missing source citation in the output.
• Recovery — manual verification of all sources against the output; possible re‑run with stricter retrieval constraints.

Reasoning faithfulness failure

• Trigger — The lead agent produces reasoning traces that improve answer accuracy but do not faithfully represent the actual reasoning steps taken.
• Guard — process verification (from the reliability framework) — a protocol that reports whether the reasoning trace matches the executed process.
• Posture — fail‑soft: the answer may be correct, but the reasoning is unreliable; the system continues.
• Operator signal — process verification results indicate mismatch between trace and actual process.
• Recovery — redesign the agent’s trace generation to enforce faithfulness; manual audit of trace logs.

Sycophancy

• Trigger — The agent adopts the user’s mistaken premise or biased viewpoint in its output.
• Guard — none; the source identifies sycophancy as a separable factuality risk without providing a guard.
• Posture — fail‑soft: the output reflects the user’s error rather than the truth.
• Operator signal — output that aligns with an incorrect user‑supplied premise.
• Recovery — use multi‑agent debate to challenge assumptions; human oversight to reject sycophantic responses.

Coordination costs are illustrated by the Debate Agent Router design where two agents produce risk assessments and a third agent decides.

Think of a kitchen where one chef chops vegetables, another grills meat, and then a third chef must taste both before deciding which sauce to call for—creating a clear waiting step. This subsystem coordinates multiple AI agents, but adding more agents brings hidden costs like that bottleneck, making the whole system slower and trickier to manage.

The actual mechanism works like this: two agents each produce their own risk assessment, then a third agent reads both before it decides which expert to call next—that is a routing pattern. The entire pipeline depends on shared state such as bounding box indices and adjudicated risk levels. Keeping that state consistent across multiple calls adds complexity, and the text notes that other frameworks report challenges with latency and token limits. Scalability becomes a serious issue when you keep adding agents because each new one introduces another waiting step and more state to synchronize.

The non‑obvious rule a beginner would miss is that agents can disagree or produce contradictory evidence, and without careful design that disagreement can cascade into a failure mode where no correct expert is called or the system stalls. Without this coordination subsystem, the concrete failure a beginner would feel is a system that grows progressively slower and more unreliable as you add agents—requests time out, outputs conflict, and you never know which agent’s answer to trust.

The subsystem operates as a staged pipeline anchored by the Debate Agent Router. First, a Base VLM/Question Generator produces three categories of structured queries: perception, planning, and prediction questions. Next, two dedicated agents independently generate their own risk assessments based on those questions. The Debate Agent Router then reads both risk assessments before deciding which vision-language expert to invoke. On failure—for example, when the two agents produce contradictory evidence—the router must either reconcile the disagreement or refuse to route, stalling the pipeline until human oversight intervenes.

The invariant the design guarantees is traceable expert routing. The Debate Agent Router explicitly exposes how it weighs competing risk assessments, rejecting the traditional sparse mixture-of-experts approach that relies on opaque latent-feature gates. This traceability ensures that every decision can be inspected, but it comes at the cost of a mandatory sequencing step: the third agent cannot begin until both risk assessments are complete and the shared state—bounding box indices and adjudicated risk levels—is consistently maintained across all calls.

The key trade-off rejects the sparse Mixture of Experts pattern, whose latent gates are difficult to inspect. By making the routing decision visible, the design avoids the cost of debugging inexplicable expert selections in safety-critical autonomous driving contexts. The penalty is increased latency from the extra coordination step and the overhead of keeping shared state consistent across multiple agent calls—a cost that is acceptable only when traceability is paramount.

A concrete failure mode occurs when the two risk-assessing agents produce contradictory evidence about a scene. The operator would see the Debate Agent Router log an inconsistency warning, followed by a timeout or a fallback request to a human supervisor. The system’s inability to resolve the disagreement signals that the routing decision cannot be made autonomously, halting the pipeline until the conflict is manually adjudicated.

Agent Disagreement or Contradictory Evidence

• Trigger — Two agents produce risk assessments that are contradictory, leaving the third agent unable to decide which expert to call.
• Guard — Not specified in source. The context does not name an exception handler, retry, or fallback for this condition.
• Posture — Fail-hard. The pipeline cannot proceed because the third agent has no validated resolution mechanism; the source states that “failure modes appear when agents disagree,” implying an abort rather than graceful degradation.
• Operator signal — No exact log line is given. The operator would observe a stalled pipeline or an error indicating that the third agent received incompatible inputs.
• Recovery — Not specified. Only manual intervention (e.g., re-running one or both risk assessments with adjusted prompts) is possible.

Shared State Inconsistency

• Trigger — Concurrent or out‑of‑order updates to shared state such as bounding box indices or adjudicated risk levels cause one agent to operate on stale or corrupted data.
• Guard — Not specified in source. The context mentions “state‑management granularity” as a design axis in the survey, but no concrete guard is provided.
• Posture — Fail‑soft. The system may degrade by producing an incorrect risk assessment or a late‑stage contradiction, but it does not automatically abort the run.
• Operator signal — No exact log line. The operator would see a mismatch in the final decision (e.g., the third agent selects an expert inconsistent with the risk levels) or silent data corruption in the output.
• Recovery — Not specified. Manual inspection and re‑execution of the inconsistent agent(s) would be required.

Token‑Limit Exhaustion in the Third Agent

• Trigger — The third agent’s context window is exceeded because it must read both risk assessments plus its own reasoning, especially if the assessments are long or the agent’s model has a fixed token budget.
• Guard — Not specified in source. The survey’s abstract reports “token‑cost structure” as a challenge, but no guard (e.g., truncation, streaming) is named.
• Posture — Fail‑hard. Token‑limit violations typically abort the agent call, producing no decision.
• Operator signal — No exact log line. The operator would likely see a model‑level error such as "token limit exceeded" (not from source) or an empty response.
• Recovery — Not specified. The operator would need to reduce the input length (e.g., truncate risk assessments) or switch to a model with a larger context window.

Latency Build‑Up from the Waiting Step

• Trigger — The third agent waits for two risk assessments to complete, creating a clear serial dependency that increases end‑to‑end latency, especially when each agent takes significant time.
• Guard — Not specified in source. The text only notes the waiting step as a “clear” problem; no timeout or asynchronous fallback is described.
• Posture — Fail‑soft. The system continues to produce results, but with degraded response time.
• Operator signal — No exact log line. The operator would observe elevated response latency, possibly triggering a time‑out warning if the waiting step exceeds a threshold, but no specific metric is given.
• Recovery — Not specified. Only architectural changes (e.g., parallelization or caching) could address this.

Scalability Breakdown Under Agent Growth

• Trigger — Adding more agents (beyond the three) exponentially increases waiting steps and shared‑state complexity, eventually exhausting system resources or causing coordination deadlocks.
• Guard — Not specified in source. The survey mentions “scalability” as a serious issue but does not name a guard such as a load‑shedding or pooling mechanism.
• Posture — Fail‑soft to fail‑hard depending on resource exhaustion. The system may first degrade (higher latency, lower throughput) and then abort if it runs out of memory or time.
• Operator signal — No exact log line. The operator would see growing response times, repeated timeouts, or out‑of‑memory errors.
• Recovery — Not specified. Manual reduction of agent count or redesign of the coordination topology is required.

Incomplete or Missing Risk Assessment (Agent Failure)

• Trigger — One of the two risk‑assessment agents fails to produce any output (e.g., due to a crash, an internal error, or a network issue), so the third agent lacks the input needed to decide.
• Guard — Not specified in source. The context does not describe any fallback for a missing assessment (no retry logic or default value).
• Posture — Fail‑hard. The pipeline cannot proceed without both assessments.
• Operator signal — No exact log line. The operator would notice that one agent’s output is blank or missing in the shared state.
• Recovery — Not specified. Manual re‑execution of the failed agent or replacement with a cached result would be required.

The provided context contains no Python code excerpts. The topic discusses tool design improvements (e.g., requiring absolute filepaths) but no actual code is present.

Imagine a single master chef in a well-stocked kitchen who can prepare any dish on the menu—rather than hiring a separate chef for appetizers, mains, and desserts. This subsystem is for deciding when one capable assistant with good tools is enough to handle many jobs, instead of building a whole team of assistants.

In practice, this means starting with the simplest possible setup. The source explains that for many applications, optimizing a single large language model call with the right background information and examples is usually enough. If you need more, you can give that one assistant well-designed tools and a clear prompt, and it can often accomplish what a group of specialized assistants would. This avoids the extra cost and delay that come with coordinating multiple agents. The key is to refine the tools and interface for that single agent rather than adding more agents.

The non‑obvious insight is that complexity often backfires. Adding more agents introduces overhead—each interaction eats time and money—and can confuse the system. The source stresses only increasing complexity when truly necessary, because a single, well‑crafted agent with the right tools can achieve similar results without the baggage. Without this disciplined approach, you might build a multi‑agent system that is slower, more expensive, and harder to debug, when all you really needed was one capable chef with the right kitchen.

The subsystem begins with a single LLM agent that dynamically directs its own process. First, the agent explicitly reveals its planning steps, adhering to the principle to “prioritize transparency by explicitly showing the agent’s planning steps.” Next, the agent executes tool invocations through a carefully designed agent-computer interface (ACI) that has been refined via “thorough tool documentation and testing.” When a tool call fails or produces an error, the system relies on “extensive testing in sandboxed environments, along with the appropriate guardrails” to detect and recover from the failure—either by allowing the agent to retry with corrected inputs or by halting execution for human review.

The invariant that the design preserves is simplicity and transparency as named core principles. The system guarantees that the agent’s planning steps are always exposed in the trace, and that the ACI remains minimal and robust. This invariant ensures that any deviation from expected behavior is immediately visible to an operator, and that the tool interface does not introduce hidden complexity that could lead to unpredictable model behavior.

The key trade-off is choosing a single, capable agent with a well-crafted ACI over adding more agents or complex orchestration layers. The source explicitly states that “the most successful implementations weren’t using complex frameworks or specialized libraries” and instead used “simple, composable patterns.” This rejects the alternative of multi-agent or workflow-based systems, which often introduce “latency and cost” overhead without proportional gains in task performance. By avoiding that alternative, the design sidesteps the coordination overhead and token costs of managing multiple agents, keeping the system lean and easier to debug.

A concrete failure mode is the potential for compounding errors as the agent operates over many turns. Because the LLM “will potentially operate for many turns,” a small tool misuse early in the sequence can cascade into incorrect outputs. The signal an operator would actually see is the agent’s transparent planning trace showing repeated tool calls with erroneous arguments or failing checks—evidence that the ACI or tool documentation needs refinement. The operator can then update the “tool documentation and testing” to make the interface more robust, directly addressing the root cause.

Failure 1: Relative Filepath Mistakes After Directory Change

• Trigger — The model attempts to use a relative filepath after the agent’s working directory has been changed (e.g., moved to a subfolder during a multi‑step task), causing the tool to resolve the path incorrectly.
• Guard — The tool was changed to “always require absolute filepaths” – validation that rejects any input not beginning with / or the filesystem root identifier.
• Posture — fail‑closed – when a relative path is supplied, the tool refuses the operation and returns an error; no file read/write or execution proceeds.
• Operator signal — An error message from the tool indicating that the provided path is not absolute (e.g., “Path must be absolute, got ‘./src/main.py’”). No specific log line identifier is given in the source, but the tool’s validation is the guard.
• Recovery — The model must resubmit the request with an absolute filepath. The source states that after the fix the model “used this method flawlessly,” implying the guard eliminates the failure entirely, so no retry loop is needed beyond a single corrected call.

Failure 2: Hallucination in Generated Output

• Trigger — The agent’s LLM produces content that is factually incorrect or fabricated, often due to the model’s generative nature, especially under ambiguous or low‑probability prompts.
• Guard — No guard shown in source for this specific agent subsystem. The source mentions hallucination as a “separable factuality risk” but does not describe a specific exception handler, retry, or validation that catches it in the tool‑agent pipeline.
• Posture — fail‑soft – the agent continues to execute, but the output is wrong; the caller may or may not detect the error downstream.
• Operator signal — The absence of a reliable signal: the output appears plausible, so the operator typically sees no explicit error; only later comparison against a trusted source reveals the hallucination.
• Recovery — No automatic recovery defined in the source. Manual intervention is required to inspect the output and re‑prompt the agent with stronger grounding instructions.

Failure 3: Attribution Error in Source‑Grounded Responses

• Trigger — When the agent retrieves evidence (e.g., from a file or database), it correctly identifies the content but incorrectly attributes it to the wrong source, or cites a source that does not contain the claimed information.
• Guard — No guard shown in source. The literature review notes that “attribution error” is a distinct factuality risk, but the subsystem description does not include any validation of source identity.
• Posture — fail‑soft – the operation completes and a response is delivered, but the attribution is inaccurate, potentially misleading downstream consumers.
• Operator signal — No metric or log line in the source; the operator would observe a mismatch between the cited source and the actual source only by manual verification.
• Recovery — Not automated. The operator must cross‑reference citations against the original source material and re‑run the agent with corrected context.

Failure 4: Self‑Correction Without External Feedback Showing Inconsistent Reliability

• Trigger — The agent attempts to correct its own prior output using internal reasoning alone (no human or tool feedback), leading to oscillating or degraded answers because the model’s self‑critique is unreliable.
• Guard — No guard shown in source. The literature states that “self‑correction without external feedback shows inconsistent reliability,” but the agent subsystem does not implement a retry guard that depends on external validation.
• Posture — fail‑soft – the agent produces a final answer that may be worse than the original, yet the pipeline continues.
• Operator signal — No explicit signal; the operator sees the final output and cannot distinguish a self‑corrected answer from a direct response without comparing both versions.
• Recovery — No automatic recovery. A manual rollback to the previous version of the output and a rerun with external feedback (e.g., a tool call) are needed.

Failure 5: Benchmark Score Contamination Invalidating Evaluation

• Trigger — The agent is evaluated on a benchmark that has leaked into the model’s training data, causing inflated benchmark scores that do not reflect real‑world performance.
• Guard — No guard shown in source for the agent subsystem. The source warns that “benchmark scores are sensitive to contamination, saturation, and protocol variation,” but the described agent does not include a contamination detector or a held‑out evaluation protocol.
• Posture — fail‑soft – the evaluation completes and reports high scores, but the results are misleading; the agent may be considered more capable than it actually is.
• Operator signal — The operator sees an unusually high or perfect score on a public benchmark; the source provides no metric to flag contamination. A suspicious pattern of performance would be the only clue.
• Recovery — Manual step: re‑evaluate on a private, uncontaminated test set or a live deployment task. No automated recovery is described.