Multi-agent systems in the enterprise

What people mean by multi-agent

Teams use "multi-agent" for anything from two LLM calls in a row to a graph of specialized workers with tools and memory.

In production, the useful definition is: separate roles with separate tools, separate failure modes, and a defined handoff—not a pile of prompts that chat with each other.

When multiple agents help

Split work when tools and permissions differ: extract vs screen vs write-back should not share one over-permissioned runtime.

Split when evals differ: a classifier and a draft generator need different test sets and pass criteria.

When one agent (or none) is better

If the workflow is a straight pipeline with one schema, one queue, and one owner, extra agents add latency and debug cost without better outcomes.

Start with one production loop. Add a second agent only when you can name the interface between them.

Handoffs are the product

The hard part is not spawning workers. It is defining what one agent is allowed to finish and what the next must receive: schema, confidence, and unresolved flags.

Without a typed handoff, multi-agent systems become multi-prompt systems with worse latency and the same failure modes as a single messy agent.

Operating multi-agent in production

Give each agent its own eval set and its own on-call ownership. When extraction fails, the extraction owner fixes it—not a generic "AI team."

Trace correlation ids across agents so support can answer what happened to a single case without reading five model transcripts.

In practice

Map the workflow on a whiteboard before you open a framework: inputs, systems of record, humans, and irreversible writes. If that map is fuzzy, the agent will encode the fuzz.

Pick ten to fifty real historical cases as an eval set. Include the ugly ones. Run the agent offline against them until critical fields and hard rules are acceptable. Only then connect write tools.

Ship with a pause switch, a human queue, and a weekly review of override reasons. Promote repeated overrides into rules. That loop is how production systems improve—not another prompt brainstorm.

Common failure modes

• Treating a demo on clean samples as readiness for production volume.
• One shared service account with broad write access across systems.
• No owner for the exception queue, so failures pile up as noise.
• Changing prompts and models without regression gates on real cases.
• Measuring only model latency or thumbs-up, not completed-case cost and audit completeness.

What good looks like after ninety days

The first workflow is boring: stable override rate, known failure modes, operators who trust the queue. Config changes go through review. Traces answer "what happened to this case?" without archaeology.

At that point you can add a second document type or a second agent role. Expanding before the first path is boring is how programs stall with five half-built pilots.