Question 1

How do you recognize it?

Accepted Answer

Client deliverables arrive with one section contradicting another because agent B never saw agent A's output schema change. Retry loops quietly triple token spend on a single retainer task while the workflow still reports success. Nobody on the delivery team can name which agent produced a given paragraph when a client asks for provenance. A single upstream model swap or API deprecation halts three client workflows on the same morning. Approval gates get bypassed because the human reviewer only sees the final output, not the intermediate reasoning.

Question 2

Why does it happen?

Accepted Answer

Orchestration is sold as a chain of prompts when the real work is contract design: schemas, validation rules, and typed handoffs between agents are usually undocumented. Fallback logic is written for the happy path only, so a failed agent either silently passes partial output downstream or retries until the budget is gone. Token consumption is treated as an infrastructure line item rather than a per-client margin variable, so cost blowouts surface after invoicing. Monitoring watches whether the workflow completed, not whether each step's output was correct, leaving hallucination to propagate undetected through multi-step runs.

Question 3

How do you fix it?

Accepted Answer

Instrument every agent boundary with a schema check and a logged payload before the next agent runs, then replay one live client workflow to find where the contract is loose. Set a hard per-run token ceiling and a max-retry count on each agent, and route breaches to a human queue instead of letting the chain self-heal. Add a named fallback model or manual step for every agent that touches client-facing output, and document the swap procedure on the retainer brief. Run a permission audit on each agent's connected accounts, scoping access to the minimum its task requires before the next client workflow goes live.

More for Multi Agent Orchestration