Multi-Agent AI Workflows: Failure Modes When Tools Call Each Other

Single-agent assistants fail in familiar ways: hallucinated citations, overconfident SQL, a tool call with the wrong parameter type. Multi-agent setups—where one model delegates to another, or where “specialist” agents chain tool calls—fail in additional dimensions that look like distributed systems bugs dressed up in natural language. The hardest part is not the demo where Agent A neatly hands work to Agent B; it is the Tuesday afternoon when B silently misreads A’s output and writes to production anyway.

This article catalogs practical failure modes when tools call each other across agents, why they emerge even with good models, and what guardrails actually change outcomes instead of merely decorating architecture diagrams.

The promise: division of labor without division of responsibility

Multi-agent patterns try to mimic teams: a planner, a researcher, a coder, a verifier. In software, specialization reduces context overload—each call can carry a narrower system prompt and smaller tool surface. In theory, that improves precision. In practice, you introduce interfaces between agents, and interfaces are where semantics leak.

Failure mode 1: ambiguous handoff payloads

Agent A summarizes a task for Agent B in prose. B interprets “rollback the migration” as “drop the table” instead of “revert the last transaction.” No individual tool call violated syntax; the pipeline violated intent. The fix is not a smarter model alone—it is structured handoff schemas: JSON with required fields, explicit invariants (“do not drop tables”), and machine-checkable preconditions before side-effecting tools run.

Failure mode 2: double execution and race conditions

Two agents both believe they own the compensating action. They each call the payment refund tool. Or they interleave writes to the same CRM record with last-write-wins semantics. This is classic distributed systems pain, except the “developers” are non-deterministic. Mitigations include idempotent tool design, external correlation IDs, transactional boundaries, and a single writer principle for critical objects.

Failure mode 3: tool hallucination by proxy

Agent B assumes Agent A already verified a fact and skips retrieval. The chain looks authoritative because it is long. In reality, confidence collapsed at step two. Forcing retrieval—or a dedicated verifier step with read-only tools—reduces but does not eliminate the issue. You still need logging that attributes claims to specific evidence objects, not to chain position.

Failure mode 4: exponential cost and latency creep

Each hop adds tokens, tool round trips, and retries. A planner that reflexively spawns subagents for trivial tasks can spend dollars to rename a file. Budget caps help, but the deeper fix is task routing: rules that keep shallow workflows shallow, reserving multi-agent fan-out for genuinely parallelizable research or codegen partitions.

Failure mode 5: security boundaries smeared across agents

Agent A has read access; Agent B inherits a transcript that contains secrets and suddenly gains a tool with write scope. Or a plugin prompt-injection in an intermediate web fetch poisons downstream reasoning. Treat each agent hop as a trust boundary: redact, allowlist domains, separate API keys per role, and never pass raw HTML from untrusted fetches straight into planner context without sanitization.

Failure mode 6: observability gaps

When something goes wrong, you need a trace: which agent proposed which tool call, with what arguments, under which policy version. Plain chat logs are insufficient—they interleave reasoning with user-visible text. Adopt tracing patterns from microservices: span IDs per agent invocation, structured JSON logs for tool I/O (redacted), and retention that matches compliance requirements.

Failure mode 7: partial failure with no compensating transaction

Agent A books a calendar slot; Agent B emails a customer; Agent C crashes before updating the CRM. You now have a meeting nobody internally knows about. Without saga-style compensation—or at least an outbox pattern—the mesh of tools becomes eventually inconsistent in the wrong direction. Multi-agent fans sometimes forget that LLMs do not magically implement two-phase commit. Your orchestration layer must own state transitions explicitly.

Failure mode 8: prompt drift across versions

Agent personas are often edited independently. A “strict verifier” update tightens formatting expectations while the planner still emits the old shape. The result is brittle parsing errors that look like model regression. Version prompts as artifacts, test handoff contracts, and roll out changes together—or prepare for silent skew.

Design patterns that survive contact with production

• Schema-first handoffs: Prose is for humans; machines get JSON with enums and validation.
• Single side-effect owner: One agent executes writes; others propose patches.
• Verifier with teeth: Read-only checks before commit; fail closed.
• Human gates on irreversible tools: Especially finance, infra, and PII.
• Deterministic retries: Idempotent APIs and deduplication keys.

When multi-agent is worth it—and when it is theater

Use multiple agents when tasks decompose cleanly, parallelism buys wall-clock time, or separation of concerns materially shrinks tool exposure per call. Skip it when your problem is fundamentally a single well-bounded function call with good tests—adding agents will only add seams.

Bottom line

Tools calling each other across agents are still programs, even when the control flow is written in persuasive English. The failures look like integration bugs because they are. The organizations that win will spend less on clever personas and more on contracts, traces, and idempotency—the unglamorous infrastructure that keeps chains from becoming liabilities.