Several agents, one outcome, and a clear answer to what happens when two of them disagree.
Agentic systems are worth building when work genuinely needs more than one specialised agent coordinating. That coordination, and its failure modes, is the whole engineering problem.
Building and running software since 2007One agent first, wherever one agent will do
The same task, given to both agents
Answer A
Confidence: high
Answer B
Confidence: high
Who decides?
The system picks one, usually the last or the most confident-sounding, and nothing records that a conflict occurred.
Illustrative of the disagreement case, not a client result.
When one agent is not enough, and when it is.
This is the wrong page for most buyers, and that is worth saying first.
The work needs genuinely different specialisms
One part reads documents, another queries a system, another drafts a response. Each needs different context and different permissions.
A single agent has become an unmaintainable prompt
It works, and nobody can change it safely, because every instruction interacts with every other one.
Steps need to run in parallel and then reconcile
Three lookups at once, then a decision from all three. Sequential handling makes the whole task as slow as the sum of its parts.
Different steps need different authority
Reading is safe, writing is not, and one agent holding both permissions is a larger risk than the work requires.
If the work is one job with one set of permissions, a single agent is simpler and easier to debug. Multi-agent architecture answers genuine specialisation, not ambition.
See AI agent developmentFour shapes that work.
- An agent
- An agent
- Work passing between them
- Work passing between them
- A checkpoint
- A checkpoint
- A permission boundary
- A permission boundary
A supervisor with specialised workers
One agent decomposes the task and routes parts to agents that each do one thing well. The supervisor holds the plan; the workers hold narrow permissions.
A pipeline with checkpoints
Stages in sequence, each validating the previous stage's output before proceeding. Slower than parallel and far easier to debug and defend.
Parallel retrieval with reconciliation
Several agents gather independently and one reconciles, including the case where two return contradictory answers.
A single agent with tool boundaries
Frequently the right answerListed here because it is frequently the right answer. One agent, several tools, distinct permissions per tool. Less architecture, same outcome.
The four failure modes specific to multi-agent systems, and what each requires.
These do not occur with a single agent, which is why multi-agent work is more than a scaled-up version of it.
Disagreement
Two agents return contradictory results.
What it looks like in productionThe system picks one, usually the last or the most confident-sounding, and nothing records that a conflict occurred
What it requires at design timeAn explicit reconciliation rule, plus surfacing conflicts rather than resolving them silently
Loops
Agents hand work back and forth without converging.
Produces incidentsWhat it looks like in productionCost and latency climb with no output. Frequently discovered on an invoice rather than in monitoring
What it requires at design timeHard limits on hops and total spend per task, enforced rather than advisory
Diffused accountability
The output is wrong and no single step was.
Produces incidentsWhat it looks like in productionEach agent behaved correctly given its input. The error is in the composition, and it is not attributable
What it requires at design timeTrace every step's input and output, so a wrong result can be walked backwards
Permission creep
A worker agent needs one more capability, repeatedly.
What it looks like in productionOver months, the narrow agents each accumulate broad access, and the isolation the design depended on is gone
What it requires at design timePer-agent permission review, and treating a permission increase as a change requiring approval
The second and third produce incidents. A loop is a cost event; diffused accountability is what makes an incident impossible to explain afterwards.
How the work runs, step by step
This is the architecture; the agents themselves are comparatively straightforward.
Try the single-agent version first
On paper, and often in practice. If one agent with well-scoped tools can do the job, that is the answer and the engagement is smaller than expected.
Decompose only where specialisms genuinely differ
Different context, different permissions, or different failure consequences. Splitting on anything else adds coordination cost for nothing.
Design the coordination contract
What each agent receives, what it must return, and what happens when it cannot.
Set the hard limits before the first run
Maximum hops, maximum spend per task, and a stop condition. Made afterwards, these are written in response to a bill.
Trace everything, from the first day
Every step's input and output retained. Without it, a wrong answer in production cannot be explained, only apologised for.
Where this work has been done
Coordination and cost control are the hard parts of agentic work, and both are visible in what Viithiisys already runs in production.
- Workplaces where Vizitor is in daily use
- 500+Workplaces where Vizitor is in daily use
- Countries Vizitor runs in
- 15+Countries Vizitor runs in
- Years of Viithiisys delivery, since 2007
- 19Years of Viithiisys delivery, since 2007
- Countries Viithiisys has delivered across
- 6Countries Viithiisys has delivered across
- Fitelo, evaluation and cost controls in productionDirectly relevant here, because cost control is one of the four failure modes above. Evaluation and cost controls in place rather than added after an incident.Read the Fitelo case study
- Vizitor, a platform in daily multi-site useIn production at scale: 500+ workplaces across 15+ countries.Read the Vizitor case study
None of these is a multi-agent engagement, and none is offered as one. They are cited as context for the two things this page says are hard, coordination and cost control.
See the case studiesCost per completed task, not cost per call, and the difference is where projects get caught.
A single agent answers once. A multi-agent system may make a dozen model calls to complete one task, and that multiplier is invisible during a prototype.
One model call
A dozen model calls
Calls per task, not calls per agent.
Why it is invisible early. A prototype is run by hand a few times. Nobody multiplies by monthly volume
What to put in placeMeasure calls per completed task during the pilot, then multiply by real volume before committing
Retries and re-planning.
Why it is invisible early. A supervisor that re-plans after a worker fails can double the cost of a task that still succeeds
What to put in placeCount retries separately. A rising retry rate is a quality signal as well as a cost one
Context carried between agents.
Why it is invisible early. Each handoff may resend accumulated context, so cost grows faster than the number of steps
What to put in placeDecide what each agent actually needs. Passing everything is the default and the expensive one
Traces and retention.
Why it is invisible early. Storage is cheap until you keep every step of every task for a year
What to put in placeSet a retention period deliberately, balanced against how far back an incident might need walking
The loop case.
Why it is invisible early. Rare, and disproportionately expensive when it happens
What to put in placeHard hop and spend caps, which is the same control as the loop failure mode above
Know cost per completed task before production, not after. A system that is correct and uneconomic gets switched off, which is the same outcome as one that does not work.
Four pages could answer an agent question. Here is which one you want.
The titles do not make the distinction obvious, and choosing wrongly costs a first conversation. This page is the narrowest of the four.
- One job, one agent, one set of permissionsAI Agent DevelopmentMost buyers want this one. Simpler, cheaper and easier to debug
- Several specialised agents that must coordinateThis page · you are hereThe coordination contract and its failure modes are the engineering problem
- Fixed triggers and rules, no interpretationAI Workflow AutomationDeterministic work does not need an agent at all, and is more reliable without one
- It is live and behaviour is driftingMLOps and LLMOpsOperating the system after release rather than building it
- Whether any of this is appropriateAI Consulting and StrategyThe decision before the build
What you are left holding.
The architecture is the asset.
The coordination contract, documented
What each agent receives and returns, and the reconciliation rule. Portable across frameworks, which matters in a category changing this quickly.
Traces you can query
In your systems. The ability to walk a wrong answer backwards is what makes the system defensible to a customer.
The limits, enforced in code
Hop and spend caps as behaviour rather than as documentation.
No framework lock-in beyond what you chose
Orchestration frameworks in this category are young and will be replaced.
Describe the task and how many different things it needs to do.
If the answer is one thing, the single-agent page is cheaper and we will say so. If it is genuinely several, with different permissions, this is the right conversation.
Questions we are actually asked
Pick a topic, or ask us directly. We answer every inbound within one business day.
Still have questions?
Talk to a senior engineer, not a bot.