Single agent vs multi-agent: when the split earns its keep | Agentic ERP Quickstart
Start with one well-scoped agent. The orchestrator and specialist pattern is implemented here and its benefit is unmeasured, which is a reason to wait, not build.
Series: Building Production-Grade ERP Agents on AWS (18 articles)
- …
- 14Single agent vs multi-agent: when the split earns its keep | Agentic ERP Quickstart This article
Single agent vs multi-agent: when the split earns its keep | Agentic ERP Quickstart
Split an agent into an orchestrator and a specialist and you get a diagram that looks like it belongs in an architecture review. You also get two prompts to keep in agreement, an extra invocation per case, and a second place for work to stall. This project implements that split, and the default here is still one well-scoped agent, for a specific reason: the pattern is implemented and its benefit is not measured. An unmeasured benefit is an argument for running the comparison, not for building the thing.
Series: Building governed ERP agents on AWS · Series guide →
This post: What the optional two-agent pattern changes, which of its claims are measured, and how to decide for your own workflow.
Prereq: None.
New to this series? Start here
The Agentic ERP Automation Quickstart is an open source reference implementation that deploys an AI agent for work your team does by hand from a written procedure, on Amazon Bedrock AgentCore. Accounts payable is the worked example, where a case looks like an invoice that does not match its purchase order. A new process type is a skill directory and your own SOPs. Six terms recur below:
- An SOP is a standard operating procedure: the written steps for resolving one kind of exception. Here, the agent reads it.
- A skill is a deployed package covering one business domain. It declares the allowed tools and which SOP maps to which case.
- AgentCore Gateway is the component that connects the agent to its tools.
- An orchestrator is the agent that holds the workflow and calls the tools. A specialist is a second, narrower agent it can consult.
- Stateless means the specialist keeps nothing between calls. It sees only the task it is handed.
- A model tier is the configured choice of which model handles a given role.
Start with the smallest design that works
A single SOP-driven agent has one model loop, one system prompt assembled from the routed skill and its SOP, and one set of allowed tools. That is easier to understand, evaluate, operate, and improve. Those four properties are worth more than they sound when something goes wrong at month-end.
The repository also implements an optional per-skill split. When a skill sets
multi_agent to true, the request-specific agent uses the configured orchestrator_tier, or the skill's own model tier if no orchestrator tier is set. It creates a stateless reasoning specialist and exposes that specialist as a tool, alongside the Gateway client and the deterministic calculator.The specialist's role is deliberately narrow. It receives one focused interpretation task, it has no tools, and it returns a structured reasoning answer. The orchestrator keeps everything else: the workflow state, the SOP, Gateway access, and responsibility for every tool call.
What is implemented, and what is still your hypothesis
This distinction is the most useful thing in the post.
| Claim | Status |
|---|---|
A skill can opt into the orchestrator and specialist pattern with multi_agent: true | Implemented |
| The specialist is stateless and has no tools | Implemented |
| The metrics hook adds specialist tokens and estimated cost into the invocation totals | Implemented |
| The split reduces cost, preserves quality, or improves latency for your process | Needs your own comparable evaluation |
IMPORTANT
The design decision record contains estimates and proposed rollout criteria. Those are hypotheses, not benchmark results. Do not treat any percentage or dollar figure in the ADR as measured savings, and do not repeat one to a stakeholder as if it were.
The signal that makes the split worth testing
Look at your traces and ask whether the work separates cleanly into two kinds:
- Mechanical execution. Following unambiguous SOP steps, selecting a known tool, running deterministic arithmetic.
- Focused judgment. Interpreting an ambiguous date, reconciling facts that conflict, choosing an escalation the SOP does not cover.
If that separation is repeatable, a specialist can take the judgment calls without ever receiving the full workflow or the tool surface. That is a containment benefit as much as a cost benefit.
Be careful about the inference on the other side, though. Containing judgment in a specialist does not demonstrate that a smaller-model orchestrator will follow a complex SOP correctly. That is exactly what your evaluation has to find out.
What the split costs you operationally
It adds more than a second model call:
- Another prompt to maintain.
- A second model configuration to keep in sync.
- Additional invocation accounting.
- A delegation boundary to test.
There is a measurement wrinkle too. When a specialist is present, the metrics hook retrieves cumulative usage from both agents, estimates each one's cost by model tier, and rolls the token counts into the run totals. But the Amazon CloudWatch metric dimension still identifies the primary model tier.
WARNING
Before you use a dashboard for model-level cost or usage comparisons, validate how it groups multi-agent runs. A chart that attributes both agents' tokens to one tier will quietly mislead you about where your spend went.
The single-agent design has none of this. And when every step in a workflow needs sustained judgment anyway, one well-scoped agent is often the clearer and safer design.
Run the comparison with controlled cases
Send the same ground-truth cases through both configurations. The repository's regression runner combines deterministic assertions against the persisted case with judge-based evaluations, and a case passes only when both the assertions and the evaluator threshold pass.
Record at least these six:
- Goal success and the persisted business outcome.
- Tool-selection and tool-parameter accuracy.
- Faithfulness to the actual source data.
- SAP-action accuracy, wherever the workflow can affect SAP.
- Turns, latency, token use, and estimated cost.
- New failure modes, including unwanted delegation and a missed escalation.
The sixth item is where two-agent designs usually fail, and it is the one people leave out.
IMPORTANT
A cost reduction that arrives with weaker tool parameters or an incorrect financial action is not an optimization. Read items 1 through 4 before you read item 5.
Roll out deliberately
The feature is selected in skill configuration. That makes it easy to turn on, and it is worth being precise about what it does not make easy.
Selecting it in configuration does not make rollback a one-line operational action, and it does not remove the need to validate the deployed skill and model settings. So: start with a non-production evaluation, capture the exact configuration and model IDs you tested, compare outcomes, and monitor the real deployment before expanding use.
Until your own environment demonstrates them, do not claim nested trace visibility, frictionless rollback, or quality parity.
Trade-offs
- What you gain. Judgment can be contained in a narrow, tool-free agent, and the model tier for each role becomes a configuration choice.
- What you give up. A second prompt, a second model configuration, a delegation boundary, and dashboards that need interpreting.
- What the design does not promise. Any cost, latency, or quality outcome. The architecture ships. The benefit is workload-specific and unproven for your case until you measure it.
Decide from evidence, not from architecture fashion
Use a single SOP agent when its traces and evaluations show it can carry the workflow at acceptable quality and cost. Test the orchestrator and specialist pattern when your traces show a repeatable split between mechanical work and judgment, and when the evaluation result justifies the extra operational boundary.
The architecture is available. Whether to enable it stays a question about your workload.
Where to go next
- AI agent observability . Where traces, tokens, and cost surface for a run.
- How an agent loads its procedure . What the orchestrator is actually reading.
Series: Building Production-Grade ERP Agents on AWS (18 articles)
- …
- 14Single agent vs multi-agent: when the split earns its keep | Agentic ERP Quickstart This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article