A single AI agent can be the right architecture even when the technology makes a larger agent network possible.
I think that is an important decision to keep available.
Multi-agent systems can be genuinely useful. Different responsibilities, information boundaries and specialist capabilities can justify separate agents working together.
But a second agent should solve an architectural problem.
It should not appear on the diagram simply because the first agent can communicate with it.
Imagine a business wants an internal assistant to investigate a particular category of operational issue and prepare a recommendation for an authorised owner.
The task has a clear scope. The sources are known. The tools are limited. The output has an identifiable recipient.
It may need one agent capable of carrying out that investigation well.
A researcher, analyst, critic, planner, supervisor and reporting agent might sound more sophisticated.
They also create new questions.
Which participant owns the task?
What information passes between them?
How do they resolve disagreement?
When does the work stop?
Which permissions belong to each component?
What extra value does the network produce?
Those questions are worth answering when specialisation helps the responsibility.
They are avoidable work when it does not.
I would want the architecture to earn its complexity through a clear operational benefit.
Begin with the responsibility the business needs
The first question should be the same regardless of how many agents the system may eventually contain.
What job are we asking the system to perform?
For our imagined assistant, the responsibility might be investigating a defined operational issue, locating the relevant evidence and preparing a useful account for a technical owner.
That is a bounded job.
A single AI agent may have enough capability to perform it with a small set of appropriate tools.
The fact that the investigation involves several reasoning steps does not automatically establish several separate responsibilities.
Reading a log, checking a document and comparing two records can all belong to the same investigation.
I would distinguish the stages inside a job from the organisational boundaries between jobs.
That connects to enterprise AI architecture. Agents should have identifiable responsibilities because that makes the system easier to reason about.
Creating a new agent for every step can make the diagram larger without making those responsibilities clearer.
The architecture should reflect the work, not the number of labels we can assign to its reasoning process.
Specialisation needs a reason beyond a different prompt
Two agents can have different instructions and still be doing substantially the same job.
One is told to research.
Another is told to analyse.
A third is told to be critical.
Those may be useful behaviours inside a task. They do not necessarily require three independently operating participants.
I would ask what changes when the responsibility becomes a separate agent.
Does it need a different permission profile?
A distinct information source?
A specialist tool set?
A separate operating owner?
An independent review process?
A lifecycle that differs from the rest of the workflow?
Those are more substantial architectural reasons.
A single AI agent can sometimes perform several forms of analysis while the surrounding workflow preserves the relevant review conditions.
Splitting the work becomes more useful when it creates a meaningful boundary rather than another conversation inside the same boundary.
The aim is not to reject specialisation.
It is to establish what the specialisation contributes to the operation before paying the coordination cost required to maintain it.
Every handoff introduces another contract
When one agent asks another to perform work, the request needs a defined meaning.
What is being requested?
What information is supplied?
Which conditions apply?
What result should return?
Is the result a finding, proposal, approval or completed action?
Those distinctions matter.
Imagine the investigation agent asks an analyst to examine a failure. The analyst returns a plausible cause without the supporting record. A supervisor treats that cause as confirmed and prepares a proposed correction.
The uncertainty changed as it crossed the handoff.
A single AI agent may also make an incorrect inference, but a larger network creates more boundaries at which meaning can be lost or strengthened unintentionally.
I would design those contracts explicitly when the split is justified.
I explored this in how AI agents should communicate inside an enterprise.
The quality of the communication architecture can matter as much as the capability of its participants.
If one agent can perform the bounded responsibility with less transfer of context, that may be a useful simplification rather than a lack of ambition.
A single AI agent can make ownership clearer
The business needs to know who or what is responsible for completing the task.
A single AI agent inside a defined workflow can have an obvious relationship to that responsibility.
A network may distribute work across several participants, which is useful only if the overall ownership remains clear.
Who decides that the investigation is complete?
Who recognises the evidence is insufficient?
Who routes the unresolved question to a person?
Who prevents two agents from independently attempting the same action?
I would want the answers before introducing more autonomous participants.
A coordinator may provide that structure. The surrounding software may also do it. Either way, coordination is another responsibility that needs evaluation and maintenance.
This connects to AI agent ownership after launch.
A system can distribute execution without distributing accountability into ambiguity.
The smaller architecture is attractive when it lets the organisation preserve a clear relationship between the task, its execution and its operating owner.
That clarity can be valuable even when a larger system is technically possible.
Different permissions can justify different agents
There are strong reasons to split a responsibility when the participants need different authority.
An investigation agent may read operational information.
A separate authorised component may execute an approved change.
Another participant may communicate externally.
Those distinctions can support useful boundaries.
I would not collapse them into a single powerful agent merely to reduce the diagram.
The permission architecture behind enterprise AI should determine which capabilities belong together and which should remain separate.
The useful question is whether the split preserves a control the operation needs.
If all participants use the same credentials, retrieve the same information and can request the same actions, the apparent separation may achieve much less than expected.
A single AI agent with a narrow role may be safer and easier to understand than several agents whose combined authority is effectively unrestricted.
Equally, distinct identities and enforceable contracts may make a specialised network appropriate.
The number of agents is not the security property.
The boundaries between their responsibilities and capabilities are.
Separate information environments can justify the network
An organisation may need agents that operate in genuinely different information contexts.
A support agent understands product guidance and customer enquiries.
A finance agent operates within a controlled financial environment.
An operational agent handles a particular process and its systems.
That is different from splitting one investigation into several agents that all read the same collection of documents.
I would consider whether specialisation helps limit context, preserve access rules or maintain a useful domain boundary.
The concept behind AI sub-agent divisions becomes valuable when the organisation has responsibilities that deserve separate operating environments.
A single AI agent may still be appropriate inside each of those bounded jobs.
The wider architecture can coordinate them when the workflow actually requires it.
This is a useful distinction: one agent per clearly defined responsibility does not mean one agent for the whole company.
Simplifying a local task and designing a specialised enterprise layer can be entirely compatible.
The architecture should reflect both the local job and the boundaries of the larger organisation.
More participants can make disagreement more expensive
Agents may reach different conclusions.
That can reveal useful uncertainty.
It does not automatically resolve the uncertainty.
Imagine two agents review the same operational evidence and recommend different next steps. The workflow needs to determine whether the disagreement reflects incomplete information, a policy ambiguity or different interpretations of the task.
Asking another agent to vote may not establish which conclusion is supported.
I would want a defined resolution path appropriate to the decision.
That could involve checking the source, applying a deterministic rule or involving an authorised person.
A single AI agent can also examine alternative explanations and present uncertainty without creating a separate participant for every perspective.
The network becomes useful when independent work genuinely improves the evidence or responsibility structure.
It becomes less useful when disagreement produces another round of conversation without a clear way to settle the business question.
The architecture should explain what the additional perspectives contribute and how their findings affect the operation.
Otherwise the system can become very articulate about being undecided.
Review does not always need another autonomous agent
A generated output may benefit from additional checks.
The necessary checks can have different forms.
Verify that the referenced record exists.
Confirm the required fields are present.
Check the proposed action against the applicable authority.
Assess whether the explanation is understandable.
Have an appropriate person review the consequential decision.
I would choose the checking mechanism according to the condition being evaluated.
Some conditions can be checked directly in software. Others may benefit from a model-based assessment or human judgement.
A single AI agent can produce work that enters those checks without making every reviewer another autonomous agent responsible for deciding its own next steps.
This can help preserve the separation between execution and evaluation.
Adding a critic agent may be useful in some architectures, but its judgement still needs a defined role and evidence of being useful.
The label critic does not make the result independent, correct or authoritative by itself.
The review should be designed around the actual quality and control requirement.
Cost needs to include coordination and correction
A larger network may use more model calls, context transfers and tool interactions.
It may also reduce work by dividing a genuinely complicated responsibility effectively.
The comparison needs evidence.
I would measure the completed task rather than assume a single AI agent is always cheaper or a multi-agent system is always more capable.
How much investigation was required?
How long did the operation take?
How much context was repeated?
How often did the system need another round of coordination?
What human correction remained?
Which architecture produced the useful result under the conditions that matter?
The answer may differ across task types.
A network that helps with difficult cases may still be unnecessary for routine ones. The surrounding workflow can potentially route responsibilities accordingly.
The useful design is the one whose additional complexity creates enough operational benefit to justify its cost.
Activity is not the measure of success.
A long conversation between agents should have to explain why it produced a better business outcome.
Observability gets harder when responsibility is spread out
An operating owner needs to understand what happened when the result is wrong.
A single AI agent with a defined task can still produce a complicated trace, but the responsibility may be easier to follow.
A network adds handoffs, waiting, coordination decisions and several participant configurations.
I would want the evidence to connect those events to the original operation and actual result.
Which agent retrieved the information?
Which produced the finding?
Which treated it as confirmed?
Which requested the action?
Which authority applied?
Where did the uncertainty change?
That is part of AI observability across the entire workflow.
The network may be worthwhile, but its operating complexity belongs in the architecture decision.
It should not be discovered only when an investigator tries to reconstruct an unexpected outcome from several separate logs.
The business should be able to own the system it deploys, including the evidence required to improve it when the participants do not behave as expected.
Start with evidence from the smaller useful system
Where the responsibility permits it, I would begin with the simplest architecture that can perform the job meaningfully.
That creates a baseline.
The organisation can identify what the single AI agent handles well and where it reaches a genuine limitation.
Perhaps the context becomes too broad.
Perhaps different information permissions are needed.
Perhaps independent work can reduce a clear bottleneck.
Perhaps the responsibility actually contains two jobs with different owners.
Those findings can justify a split.
Anthropic's guidance on building effective agents encourages starting with simpler approaches and adding complexity when the task requires it. I think that discipline is particularly useful when multi-agent design becomes a fashionable default.
The smaller system does not need to be a throwaway demonstration.
It can be a focused operation whose evaluation tells the team where specialisation would help.
Expansion then answers an observed architectural problem rather than a prediction that more participants must eventually be better.
Splitting the job should preserve what already works
When a responsibility is divided between agents, the existing useful behaviour should remain part of the evaluation.
The new handoff may lose evidence the original agent used directly.
The second participant may interpret the output differently.
A coordinator may change when the workflow stops or escalates.
The permission structure may have new indirect paths.
I would test those changes alongside the benefits the split is intended to create.
A single AI agent completing the job correctly provides a useful comparison, where that architecture is feasible.
The larger network should demonstrate an improvement in the dimensions that justified introducing it.
It should also preserve the controls and ordinary outcomes the business already depends on.
This is especially important when a split is introduced to improve performance on difficult cases. The organisation still needs to know whether routine cases became slower, less reliable or harder to review.
The new architecture should be evaluated as a change to the operation, not accepted because the participants now have more specialised names.
A smaller architecture can be easier to change deliberately
Every independently configured participant creates another place where behaviour can change.
A prompt update.
A model change.
A different tool contract.
A new source.
An altered handoff format.
Those changes may interact.
I would consider the maintenance effort as part of the architecture decision, including who reviews changes and how regressions are detected.
A single AI agent can be easier to improve when the responsibility and boundaries remain clear.
That is not a universal rule.
A well-designed specialised component may also make change easier by isolating one responsibility from the rest of the system.
The useful question is which design gives the organisation a more manageable relationship with the work it intends to maintain.
Complexity should create structure the business can use, not simply more places that require attention.
The architecture that is easiest to demonstrate is not always the one that is easiest to operate.
The team should understand both before deciding how many agents the job deserves.
The boundary between jobs is the useful unit
I do not think the right number of agents can be established through a universal rule.
One agent for every company is too broad for many responsibilities.
One agent for every reasoning step can create unnecessary coordination.
I would look for boundaries that reflect distinct jobs, authority, information and ownership.
Inside a boundary, a single AI agent may be capable of performing the necessary investigation or interpretation.
Across boundaries, controlled communication may be necessary.
The surrounding software can preserve the state, validation and review conditions that the operation requires.
That gives the architecture a reason for each participant.
A specialised agent exists because the responsibility benefits from being separate.
A coordinator exists because the workflow needs coordination.
A human receives the decision because it requires their judgement or authority.
The diagram becomes an explanation of the operation rather than a collection of possible AI roles.
I think that is a much stronger foundation for systems intended to work inside real organisations.
I think agent count should be an outcome of the architecture
Multi-agent systems will play an important role in enterprise AI.
So will well-designed responsibilities handled by a single AI agent.
The two ideas belong together.
A company can develop a broader agentic layer while keeping individual jobs as simple and well bounded as possible.
For enterprise AI implementation, I think the useful ambition is a coherent operating system with clear responsibilities, rather than the largest possible network of agents.
That means understanding where specialisation protects a boundary or improves the work.
It also means recognising when another participant creates a handoff the responsibility does not need.
The architecture should account for quality, authority, cost, oversight and maintenance.
Then the number of agents can follow from those decisions.
A smaller system is not automatically less sophisticated.
Sometimes it is evidence that the engineering team understood the job well enough to avoid unnecessary complexity.
That is a result I would be comfortable defending.
You can follow what we’re building, or explore working with us, at RayneAI.com.
