Multi-Agent System Failure Modes: How Errors Propagate

§ 01What Is a Multi-Agent System Failure?

A multi-agent system failure is an unacceptable system outcome caused or amplified by the interaction of two or more agents, or by the infrastructure that coordinates them.

An individual agent can hallucinate, misunderstand a task, choose the wrong tool, or exceed a budget. The failure becomes a multi-agent concern when coordination changes its impact.

The initial defect and the cascade are different problems

The initial defect may be a hallucination, hostile input, an ambiguous objective, a corrupted source, stale memory, a software fault, a tool failure, a policy error, or a human configuration mistake.

The cascade is the mechanism that lets the defect spread or grow.

OWASP’s 2026 Top 10 for Agentic Applications describes cascading failures as the propagation and amplification of an initial fault across agents, tools, and workflows. That distinction matters because eliminating every initial error is unrealistic. A production design must assume that one component will eventually be wrong and prevent that error from becoming a system-wide event.

Local success can hide system failure

A specialist may satisfy its child-task schema while the parent objective fails. A reviewer may complete its check while using the same poisoned source. A manager may close every visible child while missing an untracked external action.

Ask two separate questions:

1. Did each component follow its local contract?
2. Did the complete system produce an accepted outcome without violating a non-compensating control?

The second question governs production readiness.

Not every disagreement is a failure

Useful multi-agent systems can surface different interpretations. Disagreement becomes failure when the system hides the conflict; merges incompatible claims; lets the most confident agent decide without evidence; repeats work indefinitely; or performs an external action before the conflict is resolved.

A healthy system preserves disagreement as visible state and assigns one owner of resolution.

§ 02How Do Errors Propagate Between AI Agents?

An error propagates when one component treats another component’s unverified output as authority, truth, state, or permission.

Propagation needs a carrier

Common carriers include task instructions, agent messages, artifacts, tool results, summaries, shared memory, state transitions, approval records, retrieved documents, database writes, event streams, and human-facing reports.

The same text can play several roles. A child artifact may become evidence for a manager, a source for a writer, a memory entry for future work, and a tool parameter for an external action. The risk changes at each use.

Propagation needs a receiver that trusts the carrier

The receiving component may fail to check origin, identity, artifact version, evidence, scope, freshness, sensitivity, authority, state validity, or whether the content contains instructions rather than data.

One missing check does not always cause harm. It creates a route through which harm can move.

Amplification changes the size of the failure

Five amplifiers determine how far a defect can travel:

A compact propagation model

Use this operating expression:

Cascade exposure = branch reach x reuse rate x authority weight x persistence weight x reversibility weight

It is not a universal scientific formula. It forces the team to examine why two equally inaccurate outputs can have very different consequences.

An unsupported sentence in an isolated draft has low branch reach, no durable persistence, and high reversibility. The same sentence used by a manager, stored as policy, and sent by five outreach agents has a much larger exposure.

§ 03Which Multi-Agent System Failure Modes Matter Most?

Twelve failure families cover most operational pathways without treating every symptom as a new category.

One incident can contain several modes

A poisoned source may produce a decomposition error. The manager may delegate it widely. Several agents may repeat the same claim. A reviewer may agree because it retrieves the same source. The approved result may enter memory and then trigger external actions.

Labeling only “hallucination” misses the operational problem. The incident contains correlated error, fan-out, review capture, memory contamination, and authority amplification.

Severity depends on the complete route

Classify severity through people or accounts affected, data sensitivity, privilege used, external visibility, financial or legal consequence, persistence, reversibility, detection delay, and the ability to stop descendants.

Do not infer severity from model confidence or the number of failed agents.

§ 04How Does a Wrong Plan Multiply?

The coordinator is a leverage point. A wrong specialist answer may affect one artifact; a wrong coordinator plan can shape every child task.

Decomposition creates shared assumptions

A parent task contains the desired outcome, constraints, dependencies, acceptance rules, risk tier, source policy, and action boundary.

The coordinator converts those elements into child tasks. If it omits a market, date, customer segment, prohibition, or acceptance rule, every child can perform well against the wrong specification.

Fan-out rewards clarity and punishes ambiguity

Anthropic reports that its early multi-agent research system spawned excessive subagents, searched indefinitely for nonexistent sources, and generated distracting updates. It also found that vague task descriptions produced duplicate work, gaps, and misinterpretation. Its corrective pattern gives each subagent an objective, output format, tool and source guidance, and clear boundaries.

Those observations apply most directly to Anthropic’s research architecture, not every business workflow. The broader lesson is still useful: coordination errors scale with the number of branches that inherit them.

Validate the plan before expensive fan-out

Before a parent creates several children, test:

• Does the plan preserve the original objective?
• Are required constraints represented?
• Are child scopes mutually intelligible?
• Are gaps and overlaps visible?
• Does each child produce an integrable artifact?
• Is the source and tool policy explicit?
• Are dependencies ordered?
• Can the parent afford the complete branch?
• Which condition stops further decomposition?

High-risk or high-fan-out plans need human or deterministic approval before children receive work.

Sample before full execution

When the task permits, run one representative child first.

Check task interpretation, artifact shape, evidence quality, actual tool use, elapsed time, token or credit consumption, review effort, and unexpected side effects.

A failed sample is cheaper to contain than eight synchronized failures.

§ 05Why Can Several Agents Create False Confidence?

Multiple agents do not automatically provide independent evidence. They often share the same causes of error.

Correlation hides inside the stack

Agents may share the same base model, system prompt, coordinator, retrieved documents, search ranking, memory, tools, APIs, evaluation rubrics, fine-tuning data, or organizational assumptions.

If four agents use the same incorrect source, four matching answers are one evidence path repeated four times.

Voting can count copies as opinions

Majority voting helps only when errors are sufficiently independent and the aggregation rule is appropriate.

A tie-breaker agent that receives the majority’s full explanation may become anchored before evaluating the evidence.

Confidence language is not calibration

Do not aggregate phrases such as “high confidence” unless the system has a validated calibration method for that task.

Prefer claim-level evidence, source agreement and conflict, deterministic validation, known-error tests, domain-specific reviewer decisions, and outcome-based calibration against labeled cases.

Independence should be designed

For consequential verification: give the reviewer the original task and acceptance rule; hide the producer’s conclusion until the reviewer forms an initial result where practical; use different primary sources or methods; separate action authorization from content review; and reconcile disagreements through evidence, not confidence.

Redundancy without independence increases cost and apparent certainty.

§ 06How Do Context and Handoff Defects Spread?

Every boundary compresses context. The receiver needs enough information to continue correctly, but not every message, memory, or internal detail held by the sender.

Context loss changes the task

Common losses include omitted non-goals, missing source caveats, unresolved contradictions, stale versions, an unclear customer or tenant, an absent deadline, untransferred approval conditions, hidden partial actions, and ambiguous ownership.

The receiver fills gaps with inference. That inference may then be treated as an explicit instruction by the next agent.

Context excess can be equally dangerous

Sending the entire conversation or tool history can bury the current objective, expose protected data, carry hostile instructions, transfer stale decisions, consume the receiver’s context, and blur the boundary between source material and authority.

The correct packet is selective and typed.

Summaries need traceability

A summary should point to the source object, relevant section, version, author or origin, observation date, unresolved conflicts, and confidence basis.

The receiver should be able to distinguish an exact source fact from the sender’s interpretation.

Ownership must move explicitly

An incomplete transfer can create dual execution, abandoned tasks, contradictory updates, duplicated external actions, or apparent completion while work remains open.

Use a governed ownership-transfer packet when the receiver takes over the defined scope. A child-task request is not an ownership transfer.

§ 07How Do Delegation and Authority Failures Cascade?

Delegation creates a child task; it should not create an authority bridge.

The complete AI agent task delegation protocol separates the parent outcome from the child contribution, requires receiver acceptance, recalculates authority, and closes the child separately from the parent.

The parent’s permissions must not travel

The child should operate with:

child authority = receiver policy ∩ task grant ∩ data scope ∩ current approval

The intersection can narrow authority. It cannot widen it because a manager requested the action.

The executor authorizes the action

A privileged agent must independently verify the authenticated requester, permitted relationship, approved purpose, target object, operation, data scope, value limit, expiry, current state, and whether human approval is required.

Natural-language urgency is not authorization.

Confused-deputy failure is a chain problem

A low-trust research agent may not be able to send email. It may still persuade an outreach agent to send a message containing protected information or unsupported claims.

The outreach agent is not safe merely because its own identity is valid. It must validate the request, content, recipient, policy, and approval attached to the exact action.

Descendant budgets must share one ceiling

If every child receives a fresh budget, a parent can evade limits through repeated delegation.

Cap the complete lineage: depth; children; concurrent work; tool calls; retries; elapsed time; token or credit spend; data read; and external actions.

The parent correlation ID should follow every descendant and every side effect.

§ 08How Does Shared Memory Turn One Error Into Persistent Error?

Memory converts a transient result into future context. That persistence can transform one mistake into a delayed, cross-task failure.

The shared versus role-specific AI memory architecture separates human-owned sources, team or project sources, bounded role memory, task-local context, and lifecycle evidence. The separation determines how widely an incorrect entry can travel.

Memory is an influence surface

A memory entry may affect tool selection, task interpretation, refusal behavior, customer treatment, source ranking, routing, generated content, and external action.

Microsoft’s current agentic memory safety guidance treats memory as both data and a control plane. It recommends provenance-gated writes, deterministic isolation by user, agent, and tenant, scoped subagent access, retrieval-time relevance and freshness checks, and lifecycle logging.

Poisoning can be accidental

Memory contamination does not require an attacker. It can begin with a hallucinated fact; an outdated price; a customer-specific exception stored as policy; a rejected draft stored as approved; a temporary workaround retained after expiry; or a sender’s inference saved as source truth.

The controls should therefore govern all writes, not only content that looks malicious.

Track downstream influence

Store a propagation graph: source to memory object to retrieved task to artifact to action.

When a source is corrected or an entry is quarantined, the organization can find affected tasks, derived artifacts, external recipients, unresolved actions, and later memory objects.

Deletion without dependency tracking may remove the bad object while leaving its effects intact.

Retrieve memory as candidate context

At read time: verify identity and purpose; enforce tenant, project, role, and data scope; check source and version; test relevance and freshness; scan for hostile or sensitive content; prevent memory from overriding policy; label uncertainty; and record influence.

Persistent text is not a permission, approval, instruction hierarchy, or guaranteed fact.

§ 09How Do Retries, Loops, and Duplicate Actions Escalate?

Retries are safe only when the system knows what happened before the timeout.

A timeout does not prove failure

An external tool may complete an action even when the agent does not receive the response. Retrying can produce a duplicate.

Before retrying, determine: Was the request accepted? Did the action commit? Is there a transaction or event ID? Is the operation idempotent? Can the prior result be queried? Has an approval already been consumed? Would a second action be externally visible?

Unknown state should trigger reconciliation, not automatic repetition.

Loops can cross several agents

A loop may run manager to specialist to reviewer to repair and back, or return through several peers: agent A to agent B to agent C and back to agent A.

No single component exceeds its local retry rule, yet the chain continues.

Count work at the lineage level

Monitor total turns, delegation depth, child count, repeated task fingerprints, repeated tool parameters, artifact version churn, reviewer reason-code repetition, time since last material progress, and cost since the parent started.

OWASP’s AI Agent Security guidance recommends chain, retry, token, and cost limits; circuit breakers; trust boundaries; and tests for recursive tool abuse and multi-agent chaining.

Separate repair from restart

A repair request should identify the defect and preserve completed state. Restarting the full chain can repeat successful external actions, recreate accepted artifacts, overwrite newer state, spend the budget again, and hide which change fixed the problem.

Retry the smallest safe operation.

§ 10How Do Review and Voting Fail?

A review stage is useful only when it can detect defects the producer path is likely to miss.

Reviewers can inherit the producer’s error

Review capture occurs when the reviewer receives the producer’s conclusion before checking; the same poisoned memory; the same incomplete source set; the same prompt assumption; or an evaluation rubric that rewards surface agreement.

The reviewer may produce a clean approval record without adding a real control.

One reviewer cannot test every risk

Separate checks by responsibility:

No model reviewer should overrule a deterministic authorization denial.

Approval needs an object

Bind approval to the action, parameters, target, artifact version, risk tier, time window, and one execution.

“Approved” in a conversation is too ambiguous for a consequential action.

Escalate repeated disagreement

After a defined number of repair cycles: stop automatic work; preserve both positions and evidence; identify the exact unresolved decision; assign an authorized resolver; and keep the task out of the completed state.

Endless reviewer-producer debate is a cost loop, not governance.

§ 11Which Signals Reveal a Cascade Early?

Early detection depends on correlated events across the complete chain.

Watch structural signals

Structural signals include an unexpected new agent-to-agent edge; an ineligible receiver; unusual delegation depth; a sharp increase in child count; repeated task fingerprints; a circular parent-child relationship; a state transition out of order; a terminal parent with active descendants; and one approval referenced by several actions.

These signals can often be detected without interpreting model output.

Watch behavioral signals

Behavioral signals include agents repeating identical unsupported claims; sudden agreement after one shared memory update; repeated selection of an unusual tool; output that changes after retrieved content; widening recipients or data scope; agents continuing without material progress; reviewer approval despite missing evidence; and late actions after closure.

Watch resource signals

Track tokens or credits per parent outcome; tool calls per minute; concurrent descendants; retries per edge; elapsed time without state progress; external actions per outcome; and cost per accepted result.

Anthropic reports that its research agents typically used about four times the tokens of chat interactions, while its multi-agent systems used about fifteen times the tokens of chats. That is a system-specific operating observation, not a universal multiplier. It shows why abnormal consumption can be both a cost problem and a failure signal.

Preserve causal evidence

Every event should include the organization and tenant, parent correlation ID, task and agent identity, policy and model version, input and artifact references, memory objects retrieved or written, tool and action, authorization result, approval ID, state transition, cost, error or reason code, and timestamp.

The objective is to reconstruct inputs, actions, results, and responsibility from observable records. The audit-log reconstruction standard defines what buyers should be able to replay.

§ 12How Should You Measure Blast Radius?

Blast radius describes how much of the organization a defect can affect before containment.

Count affected objects, not only agents

Measure tasks, artifacts, memory objects, customer or tenant records, tools, external actions, recipients, and downstream decisions.

One agent can affect thousands of records. Ten isolated agents can affect only ten drafts.

Measure four kinds of reach

Use a severity record

For each cascade, record the initial defect, first propagation edge, detection event, affected lineage, highest authority used, external effects, persistence, reversibility, time to contain, time to correct, residual uncertainty, and accountable owner.

The first propagation edge is often the best place to add a new control.

Do not average away severe events

Keep high-impact failures as non-compensating gates.

A low duplicate-action rate does not excuse one duplicate payment. Strong average task acceptance does not offset one cross-tenant disclosure. Some outcomes require zero observed severe defects in the tested release.

§ 13How Do You Design Failure Containment Boundaries?

Containment limits what one failed component can influence.

Build narrow trust zones

Separate tenants, customers, projects, roles, data classes, tools, credentials, environments, queues, memory namespaces, and external-action channels.

An agent should receive only the zone required for the current task.

Treat every agent output as untrusted input

Before another agent uses it: authenticate origin; validate schema; enforce size and type limits; separate data from instructions; check provenance; scan sensitive or hostile content; verify version and state; recalculate authority; and apply domain acceptance.

“Internal” does not mean trustworthy.

Place controls where the effect occurs

Enforce memory write policy at the memory service; authorization at the executor; idempotency at the side-effect boundary; approval at the exact action; spend limits at the complete task lineage; and closure at the owner of the parent outcome.

A prompt cannot reliably enforce a control when the same model judgment may be compromised.

Prefer reversible staging

Safer patterns include draft before send; preview before publish; proposed memory before approved memory; shadow write before production write; reversible record updates; sandbox before live environment; and a limited recipient cohort before full fan-out.

Increase autonomy only after the staged path meets its acceptance and containment gates.

§ 14How Should Circuit Breakers and Kill Paths Work?

A stop control is useful only if it can halt the complete chain quickly and predictably.

Define trip conditions

Possible conditions include maximum chain depth; maximum children or concurrency; repeated task fingerprints; no material progress; an error-rate spike; abnormal cost or token use; an unauthorized tool request; an approval mismatch; a memory-integrity failure; a duplicate external action; a cross-tenant access attempt; or a human stop.

Use task-specific thresholds based on tested normal behavior rather than copying arbitrary global values.

Stop new work before cleaning old work

A reliable trip should:

1. block new descendants;
2. block or constrain new tool actions;
3. cancel queued work where safe;
4. mark in-flight state;
5. preserve evidence;
6. notify the accountable owner;
7. identify uncertain external actions; and
8. require explicit recovery authorization.

Stopping the manager alone is insufficient if children can continue independently.

Distinguish pause, cancel, quarantine, and revoke

An incident may require all four at different layers.

Recovery must not reopen the same route

Before resuming: remove or quarantine the source defect; correct affected state; rotate compromised credentials; invalidate approvals; reconcile external actions; re-evaluate descendants; add a regression case; and confirm the new control at the first propagation edge.

The incident-response playbook covers the complete contain, revoke, review, and recover loop.

§ 15What Does a Cascading Failure Look Like in Practice?

Consider a growth organization preparing an outbound campaign.

The initial defect

A research agent retrieves an old pricing page and states that a feature is included in every plan. The artifact does not preserve the page date or current source version.

The propagation

The original factual error is only one part of the incident. The operating system widened, persisted, approved, duplicated, and concealed it.

A containable version

The controlled path behaves differently: the source record carries observation date and page version; the manager’s fan-out gate rejects unverified commercial claims; child tasks reference the source rather than copying a loose summary; the reviewer checks claim-to-source support independently; team-memory writes require a typed proposal and source-owner approval; sends use action-bound approval and idempotency keys; timeout triggers reconciliation before retry; and the parent cannot close while a descendant or external action remains unresolved.

The research agent can still be wrong. The system prevents one wrong result from becoming five durable external actions.

The most valuable control is often early

In this scenario, a provenance requirement before manager fan-out prevents several later failures. Downstream controls remain necessary because the next incident may enter through a different route.

Defense in depth works best when controls fail differently and protect different boundaries.

§ 16Which Metrics Show Whether Containment Works?

Measure propagation, detection, containment, recovery, and cost.

Calculate chain exposure

Suppose 100 parent tasks each create 3 children. A defective parent plan occurs in 4 tasks. The defect reaches all 12 children, and 9 child artifacts are integrated.

Branch exposure is 12 / 300 = 4%. Propagation beyond the child layer is 9 / 12 = 75%.

The 4% figure looks small. The 75% figure reveals that once a defect entered the child layer, containment was weak.

Segment by propagation edge

Track input to coordinator; coordinator to child; child to reviewer; artifact to memory; memory to task; agent to tool; tool to external system; and child to parent closure.

An aggregate system rate can hide one dangerous edge.

Compare severe failures separately

Use weighted quality scores for ordinary defects. Use explicit release gates for an unauthorized privileged action, cross-tenant disclosure, irreversible duplicate action, unbounded chain, memory override of policy, and inability to stop descendants.

These events should not disappear inside an average.

§ 17How Do You Test Error Propagation Before Production?

Test the chain by injecting a known defect and observing where it stops.

Begin with 30 cases

Use five cases in each group:

Thirty is a starter pack, not a sufficient universal test count. Expand it with real incidents, near misses, new tools, changed prompts, memory changes, and policy revisions.

Score the complete outcome

For each case, record the expected detection point; expected denied or allowed action; maximum permitted blast radius; expected terminal state; expected evidence; actual affected objects; actual cost; containment time; recovery result; and residual risk.

Passing means the failure stayed within the declared boundary, not merely that one agent refused.

Test correlated failures deliberately

Run cases where the producer and reviewer share a poisoned source; several agents share the same misleading memory; a manager sends the same flawed plan to every child; the evaluator sees the producer’s conclusion first; and a common tool returns plausible but wrong data.

Independent-agent testing alone will not expose shared-cause failures.

Re-run after material change

Regression-test after changes to the model, prompt, tool, connector, permission, memory or retrieval, delegation policy, reviewer, state machine, approval flow, or external API.

OWASP recommends adversarial testing before production and after material changes to agent prompts, tools, memory, retrieval, policies, or model providers.

§ 18How Should You Roll Out a Multi-Agent System Safely?

Expand one boundary at a time.

Phase 1: Map the chain

Document the parent outcome, agents and owners, edges, artifacts, memory, tools, authority, external actions, and stop owner.

Mark every point where output becomes truth, permission, persistent state, or external effect.

Phase 2: Establish a single-agent baseline

Measure final acceptance, severe defects, elapsed time, human review, correction, cost, and recovery.

The multi-agent design must improve an outcome enough to justify more boundaries.

Phase 3: Add one governed edge

Choose one reversible relationship with typed input, typed output, bounded authority, explicit state, deterministic validation, one owner, and no irreversible action.

Run representative tasks and fault injections.

Phase 4: Add persistence carefully

Begin with task-local context. Add role or shared memory only after verifying provenance, write gates, retrieval gates, isolation, correction, deletion, propagation tracking, and quarantine.

Phase 5: Add external actions

Use previews, narrow recipient or object scope, action-bound approval, idempotency, transaction evidence, reconciliation, and rollback where possible.

Keep high-impact actions under qualified human review.

Phase 6: Increase fan-out

Raise branch count or concurrency only when task interpretation remains stable; branch exposure stays inside tolerance; review capacity is available; lineage budgets work; kill tests pass; and the cost per accepted outcome remains justified.

Before increasing fan-out, apply the human span-of-control workload model to verify that review, exception, approval, and incident queues still fit both weekly attention and peak response capacity.

Phase 7: Rehearse failure

Run a scheduled exercise: inject a defect; trigger detection; stop the chain; identify affected objects; quarantine bad state; reconcile external actions; restore valid state; and verify the regression.

A stop control that has never halted the real execution path is an assumption.

§ 19How Does CellCog Fit a Contained Multi-Agent Model?

CellCog publicly positions AI Employees as standing role agents that can maintain tasks and memory, work on schedules, use connected capabilities, and delegate to other AI Employees.

As of July 24, 2026, CellCog’s public AI Organization page showed one human founder and nine active AI Employees: a Chief of Staff, Sales Lead, Head of Growth, Head of Marketing, and five sales representatives. CellCog reports that the Sales Lead manages the five representatives.

That operating structure makes multi-agent failure containment a practical operating requirement.

Public operating evidence shows real coordination surface

CellCog self-reported cumulative operating counts for shifts, spend, closed tasks, emails including internal coordination, and dashboard updates, alongside 6x outbound throughput after the sales team formed and a 1.5% bounce rate.

These are dated first-party figures, not independently audited customer benchmarks. They show the scale of CellCog’s own operating surface; they do not establish universal reliability or prove every control described above.

Product fit should be evaluated against containment evidence

For the CellCog AI Organization model, ask for a live demonstration of unique agent and task identity; parent-child lineage; authority at each agent boundary; approval binding; memory provenance and isolation; duplicate-action prevention; chain-wide budgets; active-descendant visibility; pause, cancel, quarantine, and revoke behavior; and correlated event history.

For CellCog Agent-to-Agent connections, also verify caller authentication, capability discovery, request schemas, accepted relationship types, task state, replay protection, result provenance, tool and data scope, error semantics, and what happens when the calling agent is compromised.

The operating team remains accountable

Users set an AI Employee’s goals, schedule, permissions, and connected accounts, and remain responsible for monitoring its work and the actions it takes on their behalf.

Start with one reversible task, one narrow edge, one accountable human, and one demonstrated kill path. Add another agent only after the existing chain can detect, contain, and recover from a known failure.

§ 20What Should You Verify Before Launch?

Use the following release gate.

Outcome and ownership

• Is the parent outcome explicit?
• Does every scope have one current owner?
• Are delegation and ownership transfer distinct?
• Can the parent close only after descendants reconcile?
• Is one human accountable for the operating boundary?

Context and evidence

• Are instructions separated from untrusted data?
• Do summaries retain source, version, date, and uncertainty?
• Can receivers verify material claims?
• Are artifact types and versions explicit?
• Do conflicting sources produce visible state?

Authority and action

• Does each agent use its own identity?
• Is authority recalculated at every boundary?
• Are approvals bound to exact actions and parameters?
• Are high-impact actions independently reviewed?
• Are side effects idempotent, reversible, or reconcilable?

Memory

• Are writes gated by purpose and provenance?
• Are tenants, users, projects, and roles isolated?
• Are retrieval relevance and freshness checked?
• Can bad memory be quarantined and rolled back?
• Can every affected descendant be found?

Loops and resources

• Are depth, child count, concurrency, retries, time, spend, and actions capped?
• Do caps apply to the whole lineage?
• Is material progress distinguishable from repeated work?
• Does timeout trigger state reconciliation?
• Does the circuit breaker stop active descendants?

Review and observability

• Are important checks independent of the producer path?
• Do deterministic controls remain authoritative?
• Can one correlation ID reconstruct the chain?
• Are prohibited actions visible even when denied?
• Have failure injection, stop, quarantine, and recovery been rehearsed?

If any consequential answer is unknown, keep the workflow in a reversible, supervised state.

§ 21What Is the Final Decision?

Treat a multi-agent system as a network of trust boundaries, not a group of helpful personas.

Assume one agent, source, tool, memory entry, reviewer, or coordinator will eventually be wrong. Then ask whether the error can acquire more authority, reach more branches, persist longer, repeat actions, or escape into an external system.

The production decision is not based on whether every agent looks capable in isolation. It depends on whether the complete chain can: preserve the parent objective; distinguish evidence from assertion; prevent permissions from widening; keep failures inside a declared blast radius; stop every descendant; reconcile uncertain actions; correct persistent state; and reconstruct what happened.

Before adding another agent, model one plausible cascade from initial defect to external effect. Inject it, observe it, stop it, recover from it, and retain the evidence. Expansion is justified only when the system fails within its boundaries.