What are the most common anti-patterns in multi-agent s...

These five show up repeatedly enough that interviewers specifically probe for them — describing a system and asking “what’s wrong with this” is a common format, and the five anti-patterns below are usually what they’re testing for.

• Over-agentification. Reaching for an LLM-driven agent where a deterministic rule would do — “flag any order over $1,000 for approval” is a one-line condition, not a decision that benefits from a model’s judgment. Every unnecessary agent adds latency, cost, and a new source of unpredictable behavior for zero benefit.
• Unbounded loops. Missing any one of a step ceiling, a cost cap, or a timeout — not just the step ceiling most people name first — is enough for a single stuck run to consume disproportionate budget or time before anyone notices.
• Shared mutable state without locking. Multiple agents writing to the same state concurrently without coordination produces race conditions and corrupted state, and it’s a bug class that reproduces inconsistently, which makes it expensive to debug in production after the fact.
• Too many sequential agents. Every additional agent in a strictly sequential chain adds a full LLM round-trip’s worth of latency. Eight agents run one after another, at roughly half a second to two seconds each, turns what should be a fast interaction into ten-plus seconds — the fix is usually running independent agents in parallel rather than defaulting to a sequential pipeline.
• No fallback. Designing only for the primary agent succeeding, with no simpler backup path or human escalation for when it fails, turns one agent’s failure into a full system outage rather than a contained, recoverable degradation.

Recognizing these in a system someone else designed — not just avoiding them in your own — is usually the actual thing being tested.