Direct answer
When the work has genuinely separate responsibilities with different tools and permissions, separation helps. When it is one task split for elegance, it adds failure modes without adding capability. The useful test is whether each agent would need a different tool contract and a different permission scope.
Multi-agent system
An agentic design in which several specialised agents, each with its own instructions, tools and permissions, cooperate on a workflow under an orchestrator that routes work between them and holds the overall governance.
When separation earns its cost
Extra agents add coordination, latency and cost. These are the conditions under which they pay for themselves.
Different tool contracts
One agent reads a data warehouse, another writes to a ticketing system — different operations and different risk.
Different permissions
Separating them keeps a broad read scope away from the component that can write.
Different failure handling
A retrieval failure and a write failure need different recovery, and mixing them obscures both.
Genuinely parallel work
Independent sub-tasks that can run at once rather than a sequence dressed as a graph.
The single-agent default
Start with one agent and more tools. It is easier to evaluate, easier to trace, and cheaper to run, and most workflows that look like they need a team of agents actually need clearer tool definitions. Split when a specific responsibility needs its own permissions, not when the diagram would look better.
Governing the whole, not each part
Approval and audit belong to the workflow, not to individual agents. A reviewer approves a consequential action once, with the evidence assembled across whichever agents contributed, and the record traces that evidence back through the handoffs. Governing each agent separately produces several partial records and no answerable question.
The Propose–Decide–Execute pattern
CodeDTX builds agentic systems on the Propose–Decide–Execute pattern: agents may only write proposals with evidence attached, a named human records an approval or rejection with a reason, and a separate execution layer carries out approved work and logs the artifact. No agent holds a write tool to the outside world.
- 01
Propose
The agent analyses live system state and drafts a change, with the evidence it relied on attached to the proposal.
- 02
Decide
A named human approves, edits, or rejects with a reason. Risk tier determines who is allowed to decide.
- 03
Execute
A separate execution layer performs approved work — merge, publish, call, write — and records the resulting artifact.
- 04
Audit
Actor, reason, evidence, artifact, tokens, and cost are retained for every run, so any decision can be reconstructed later.
The six layers we build and review against
- 1
Agent layer
Agent architecture, tool use, memory and context, multi-agent patterns, structured outputs, orchestration.
- 2
Integration layer
MCP servers, tool contracts, API and database adapters, authentication, permissions, legacy system access.
- 3
Knowledge layer
Retrieval and RAG, vector and search architecture, enterprise knowledge sources, data access controls.
- 4
Reliability layer
Evals, tracing, observability, cost and latency budgets, fallbacks, regression tests.
- 5
Safety layer
Guardrails, prompt-injection defense, PII and data boundaries, human-in-the-loop gates, audit trails.
- 6
Product layer
The application people actually use: interfaces, approval queues, and operational runbooks.
Frequently asked
Is a multi-agent system more capable than a single agent?
Not inherently. It is better at work with genuinely separate responsibilities and worse at everything else, because coordination introduces failures that a single agent does not have. Capability usually comes from better tools and evidence rather than from more agents.
How do agents hand work to each other reliably?
Through structured messages with explicit schemas rather than free text, and with the orchestrator holding state. Free-text handoffs lose information silently and make a failure impossible to attribute to a stage.
How do you evaluate a multi-agent workflow?
At the workflow boundary first — did the end state come out right — then per agent for the stages that fail. Evaluating only the parts can show every agent passing while the workflow still produces the wrong outcome.
Have a workflow that should become AI-enabled?
Tell us about the system it lives in. We reply from an engineering seat, not a sales deck.