--- title: "A Multi-Agent Claude Build: From Problem to Shipped" description: "A realistic end-to-end walkthrough of shipping a multi-agent Claude system — from problem framing to architecture, evals, and a safe production rollout." canonical: https://callsphere.ai/blog/a-multi-agent-claude-build-from-problem-to-shipped category: "Agentic AI" tags: ["agentic ai", "claude", "multi-agent systems", "use case", "orchestrator subagent", "ai engineering"] author: "CallSphere Team" published: 2026-04-10T17:46:22.000Z updated: 2026-06-06T21:47:43.706Z --- # A Multi-Agent Claude Build: From Problem to Shipped > A realistic end-to-end walkthrough of shipping a multi-agent Claude system — from problem framing to architecture, evals, and a safe production rollout. Most writing about multi-agent systems lives in the abstract: orchestrators, subagents, coordination patterns. This post does the opposite. It follows one realistic project from the moment a problem lands on an engineer's desk to the moment the feature ships and runs unattended, so you can see where coordination earns its keep and where it nearly derails the build. The scenario: an operations team drowns in inbound vendor contracts. Each contract needs to be read, key terms extracted, checked against company policy, and either flagged for legal or auto-approved. A single person handles maybe a dozen a day. The ask is to build an agentic system on Claude that handles the routine cases and escalates the rest. It is exactly the kind of bounded, high-volume, judgment-heavy task where multi-agent coordination shines — and exactly the kind where it can quietly go wrong. ## Framing the problem before reaching for agents The first instinct of a good engineer is to ask whether this even needs multiple agents. Plenty of tasks that look like they need a fleet are better served by one well-prompted Claude agent with a couple of tools. Multi-agent coordination is the right call when subtasks are genuinely independent, benefit from specialized context, or run faster in parallel — and it carries a real cost, since multi-agent runs use several times more tokens than single-agent ones. Here the decomposition is natural. Extracting terms from a contract, checking those terms against policy, and assessing legal risk are different jobs with different context needs. The extractor needs the raw document; the policy checker needs the company rulebook; the risk assessor needs both plus a sense of precedent. Three specialized subagents, coordinated by an orchestrator, map cleanly onto the work. That clean mapping is the signal that multi-agent is the right pattern, not a fashionable one. ## The architecture we shipped The design settled into an orchestrator that owns the workflow and three subagents that each do one thing well, with a deterministic gate before anything irreversible happens. ```mermaid flowchart TD A["New contract arrives"] --> B["Orchestrator agent"] B --> C["Extractor subagent: pull key terms"] C --> D["Policy subagent: check vs rulebook"] C --> E["Risk subagent: assess legal exposure"] D --> F["Orchestrator synthesizes verdict"] E --> F F --> G{"Clean & low-risk?"} G -->|Yes| H["Auto-approve, log decision"] G -->|No| I["Escalate to legal with summary"] ``` The orchestrator extracts first, because both downstream checks depend on the structured terms. Then it fans out the policy check and the risk assessment in parallel, since they are independent. It synthesizes the two results into a single verdict, and a deterministic gate — not the model's judgment alone — decides whether the contract is clean and low-risk enough to auto-approve. Anything ambiguous goes to a human with a tidy summary attached. The human gate sits exactly where the blast radius is highest: auto-approving a bad contract is the one outcome we cannot tolerate. ## Where it nearly went wrong The first working version was a trap. It auto-approved aggressively because the risk subagent, handed only the extracted terms, kept rating things low-risk that a human would have flagged. The fix was a context fix, not a model fix: the risk subagent needed the original document, not just the extractor's summary, because the risk often lived in clauses the extractor deemed minor. This is the recurring lesson of multi-agent builds — most bugs are about what each agent can see, not about the model's reasoning. The second problem was cost. Early runs spawned the risk assessor recursively when contracts referenced other contracts, and a few runs ballooned. We added a fan-out depth limit and a per-run token budget; if a contract was tangled enough to trip the limit, it escalated to a human automatically. That turned a cost risk into a graceful degradation: complex cases route to people, simple cases stay cheap and automated. ## Proving it before trusting it We did not flip it on for live traffic. We built an eval set of around a hundred historical contracts with known outcomes and ran the system against them, grading on a simple rubric: did it auto-approve only things a human would have, and did it escalate everything risky? The first scores were mediocre, mostly false auto-approvals. Each failure became a fixture in the eval suite, and we iterated on context and the gate until the system reliably erred toward escalation — the safe direction for this problem. Only then did it go live, shadowing the human reviewer for a week: the system produced a verdict, the human still decided, and we compared. When the agreement rate held steady on the safe side, we let it auto-approve the cleanest tier and route the rest. The ops team went from a dozen contracts a day to clearing the routine backlog automatically and spending their attention on the genuinely hard cases. The win was not that Claude read contracts; it was that a coordinated, observable, gated system turned an unbounded queue into a bounded, auditable workflow. ## Frequently asked questions ### How do I decide whether a task needs multiple agents? Ask whether the subtasks are genuinely independent, need different context, or benefit from parallelism. If a single well-prompted Claude agent with a few tools can do the job, use that — it is cheaper and easier to debug. Reach for coordination only when the decomposition is natural, as it was for extract, check, and assess. ### What broke most often during the build? Context, not reasoning. The most damaging bug came from a subagent that could not see the original document and therefore underrated risk. In multi-agent systems, deciding exactly what each agent receives is usually the real engineering work. ### How did you keep auto-approval safe? A deterministic gate, not the model alone, made the final auto-approve decision, and the system was tuned to err toward escalation. Irreversible, high-impact actions should always sit behind a rule or a human, with the agents feeding judgment rather than holding the trigger. ### How long did it take to trust the system in production? A shadow week after the evals passed. The system produced verdicts while humans still decided, and we compared agreement before letting it auto-approve only the cleanest tier. Earning trust gradually beats flipping a switch on day one. ## Bringing agentic AI to your phone lines CallSphere ships this same build-it-and-gate-it discipline to **voice and chat** — coordinated AI agents that answer every call, pull data mid-conversation, and escalate the tricky cases to a human. See a production system at [callsphere.ai](https://callsphere.ai). --- *Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.* --- Source: https://callsphere.ai/blog/a-multi-agent-claude-build-from-problem-to-shipped