Multi-Agent Systems

A single AI agent handles one workflow well. But some tasks are too complex or too broad for one agent. Multi-agent systems split the work across specialized agents that each handle a piece of the problem.

Consider an example: processing a complex insurance claim. One agent reads and extracts data from the claim documents. Another agent checks the extracted data against policy rules. A third agent calculates the payout. A supervisor agent coordinates the whole flow and handles exceptions. Each agent is simpler and more reliable than one giant agent trying to do everything.

The coordination layer is what makes multi-agent systems different from just running multiple independent agents. Agents pass messages, share state, and follow a defined workflow. Architectures vary: centralized (a supervisor agent assigns tasks to specialists), hierarchical (supervisors of supervisors for deep workflows), and decentralized (peer agents negotiate and hand off work directly). Centralized designs are easier to debug. Decentralized designs can tolerate individual agent failures better but are harder to reason about.

Multi-agent systems work well for enterprise workflows that cross departments or require different types of expertise. Procurement processes, audit workflows, loan underwriting, and customer onboarding journeys typically involve multiple checks and approvals in sequence, which map cleanly onto specialized agents.

The tradeoff is complexity. Multi-agent systems are harder to build, test, and debug than single agents. You need clear contracts between agents (often defined as JSON schemas for messages), good observability to understand what's happening when something goes wrong, and careful cost management since every handoff adds LLM calls. A multi-agent flow with 5 agents and 3 turns each burns 15 LLM calls per task instead of 3.

When not to use multi-agent: when a single agent with a few tools can do the job. Teams often reach for multi-agent architectures because they look sophisticated, then spend months debugging agent-to-agent communication that a single well-scoped agent would have handled in half the code. The bar to add another agent should be "this specialization has a clear, testable boundary," not "this sounds cooler as a multi-agent system." Start single-agent. Split only when the single agent is genuinely struggling or when you need parallel execution across independent subtasks.

A commercial insurance carrier deploys a multi-agent system for small-business claims under $25k. A claim arrives with scanned documents, a description, and photos. The orchestrator (built on LangGraph) dispatches the claim to a supervisor agent.

The supervisor calls four specialists in parallel. Document Agent (Claude Haiku) extracts structured data from the scanned forms using OCR plus LLM parsing. Policy Agent (Claude Sonnet) retrieves the policyholder's coverage from the policy DB and checks deductibles and exclusions. Photo Agent (Claude Opus with vision) analyzes the damage photos and produces a preliminary damage estimate. Fraud Agent (a fine-tuned smaller model) scores the claim against historical fraud patterns.

The supervisor receives all four results, reconciles them, and applies a decision rule. Claims with consistent specialist outputs and a fraud score under 0.2 are auto-approved and sent to the payment agent. Claims with conflicts or fraud scores above 0.5 are routed to a human adjuster with a summary of what each specialist found. Claims in the middle go to a second-pass review with an additional document agent checking for missing paperwork.

On 4,200 pilot claims, roughly 38% were auto-approved in under 3 minutes, averaging $0.42 in compute. Another 22% auto-rejected with clear reasons. The remaining 40% went to human review, but with all specialist outputs already prepared, which cut adjuster time per claim from 28 minutes to 9. Cycle time dropped from 6 days to 18 hours for the auto-approved tier.