A multi-agent workflow can pass isolated tests and still fail at the boundaries between agents. Treat the patterns below as hypotheses to test in your system, not as claims that every multi-agent system exhibits them.
1. Delegation has no execution bound
A task can keep expanding when an agent delegates work that delegates again, or retries a subtask without a stopping condition. The relevant boundary is the whole execution: nested calls, tool operations, retries, elapsed time, and any human escalation path.
Diagnose it: Trace each child task to its parent and record the agent, attempt, purpose, and remaining execution budget. Test a case where a subtask cannot complete. The workflow should stop at its configured limit and return a defined partial result or failure state, not start another child indefinitely.
Set limits that match the task and system's risk. A depth cap alone may miss a single agent making repeated calls; a call or time cap alone may hide a rapidly expanding delegation tree. The limit should cover the resource that can actually grow, and the caller should be able to see why the workflow stopped.
2. Parallel state updates have no defined merge
Shared state is not automatically corrupt, and concurrent writes are not inevitable. The risk exists when parallel work can update the same state field and the application or framework has no merge behavior that preserves the intended result.
Diagnose it: Identify each field, its writers, whether those writes can overlap, and the update rule. Run the overlapping case and assert the expected final state. If the framework uses a reducer or another merge rule, test that rule with realistic updates. For example, LangGraph documents per-key reducers for applying node updates; its behavior is framework-specific, not a guarantee about every shared-state design.
Choose an explicit boundary: serialize updates, give fields separate writers, or define and test a deterministic merge. The correct choice depends on whether updates replace, append, combine, or must reject conflicts.
3. Supervisor routing sits on the critical path
A supervisor call can add latency and model usage, but its presence alone does not make it a bottleneck. The concern is a measured dependency: downstream work waits for a slow or unavailable routing decision, or the same decision is recomputed across steps.
Diagnose it: Trace routing duration, queue wait, repeated routing calls, and the effect of a wrong assignment. Compare the current route with a deterministic rule on the same set of requests whose routing criteria are known. Check both routing quality and end-to-end behavior before replacing the supervisor. Keep model-based routing where the decision depends on context a stable rule cannot represent; give it a timeout and an explicit fallback.
4. Handoffs validate shape but not meaning
A typed response can have every required field and still contain a false, unsupported, or incomplete claim. Structural validation catches malformed handoffs; it does not establish that the next agent should trust the content.
Diagnose it: At each boundary, test a missing field, a type error, and a plausible but unsupported claim. Confirm the receiving step rejects malformed data and asks for evidence or escalates when a material claim lacks support. A schema check should be one part of the handoff, with provenance and task-specific validation where the next decision depends on them.
This distinction matters when a later agent turns a research summary into a customer-facing answer or an action request. Valid syntax is not permission to act.
5. A peer's output carries more authority than it should
An agent may pass along mistaken or manipulated content. If downstream agents treat a peer's output as trusted instruction, the effect can extend beyond answer quality into tool use or data access. OWASP's LLM06:2025 Excessive Agency guidance identifies compromised peer agents as a possible source of unsafe outputs and recommends limiting functionality, permissions, and autonomy.
Diagnose it: Give a test handoff an instruction that requests an action outside the task's authorization. Confirm that the receiving agent treats it as data, and that the tool or downstream service enforces authorization independently of model judgment. Limit each agent to the actions and data its role requires. For consequential writes, keep the authorization check at the system boundary.
This is different from a malformed handoff: the payload can be well-formed and still request an unauthorized action.
Measure coordination, then test the simpler baseline
Cost is a diagnostic dimension, not a sixth failure pattern or a score. For each run, record calls and tokens for routing, handoffs, state transfer, task execution, retries, and evaluation, then classify each by its recorded purpose and count it once. A retry or evaluation call may serve coordination or task work depending on why it ran; do not assign every one to coordination. Compare the records with workflow latency, reconcile metered usage to the provider bill, and report shared infrastructure costs separately with their allocation rule.
Then run the same representative tasks through the multi-agent workflow and the simplest plausible alternative. Hold output-quality checks, task mix, and authorization boundaries constant. Compare successful completion, latency, measured model usage, and the operating work each version requires. If the simpler path meets the same requirements with less measured coordination, the extra agent boundary has not earned its cost for that workload. If it does not, keep the specialization and investigate the boundary that failed. No universal coordination ratio decides this for you.
For an applied CrewAI debugging path, see Debugging CrewAI Agent Failures. For workflow-level evaluation design, see The Evaluation Layer Every Production AI System Needs.