One giant agent is usually the wrong architecture
Why giving one assistant every tool, policy, and workflow makes it less reliable, and how scoped workers improve control and maintainability.
The first internal assistant often starts with one instruction and one tool.
Then people ask for more.
Add the CRM. Add Slack. Let it prepare reports. Let it onboard employees. Let it update projects. Add the finance policy, the sales handbook, and every client folder.
Soon one assistant has hundreds of instructions, dozens of tools, and access rules that are difficult to explain.
It can do more things. It becomes less dependable at each one.
More capability creates more choices
Every tool gives the model another decision.
Should it search the CRM or Slack? Should it update the project before creating the follow up? Which of two similar tools is appropriate? Does the employee have permission to run the action?
Long tool descriptions and policies also consume the working context needed for the actual task. The model has to separate relevant rules from unrelated ones before it begins.
This is why adding every capability to one assistant can reduce reliability even when each tool works correctly.
Separate coordination from specialist work
A more maintainable pattern uses a small orchestrator and scoped workers.
The orchestrator understands the request, decides which capability is needed, and passes a clear task to the right worker. Each worker receives only the tools, context, and permissions required for its job.
A company might have:
- A reporting worker that reads approved metrics and produces a daily brief.
- A sales worker that reads CRM and meeting context but cannot access HR records.
- An operations worker that creates project tasks after approval.
- An onboarding worker that answers from approved policies and team guides.
The employee still experiences one entry point. The system behind it has clearer boundaries.
Scope makes evaluation possible
It is difficult to test a universal assistant because success means something different for every task.
A reporting workflow should include the correct metrics and cite the source. A CRM workflow should choose valid fields and never overwrite an approved value. An onboarding answer should be current, permitted, and easy to understand.
Scoped workers let the team define specific tests for each capability.
Anthropic’s engineering guidance makes a similar distinction between fixed workflows and agents. It recommends adding complexity only when simpler approaches do not work. Its multi-agent research system uses a lead agent to delegate focused work to subagents with clear objectives and boundaries.
That pattern is useful, but it is not a reason to make every process multi-agent.
Keep predictable work deterministic
Many business processes do not need an autonomous worker.
If the flow is always:
- Read the approved meeting summary.
- Extract confirmed actions.
- Ask a manager to approve them.
- Create tasks in Asana.
- Record the task links.
Then regular application code should control most of the sequence. The model can help interpret the meeting, but it does not need freedom to redesign the process every time.
Use model judgment where language and ambiguity require it. Use code and business rules where the path is known.
Permissions become easier to explain
One giant assistant often receives broad access because it serves many departments.
Scoped workers can use narrower identities and tool permissions. The onboarding worker has access to shared policies. The finance worker is limited to approved finance users. The customer action worker can draft an update but cannot send it without approval.
This aligns access with purpose.
It also makes incident review easier. Logs show which worker retrieved which source and attempted which action, rather than everything appearing under one powerful service account.
Delegation needs a contract
Specialist workers are not useful when the orchestrator gives vague instructions.
Each delegated task should include:
- A clear objective.
- The expected output format.
- Relevant source boundaries.
- Tools the worker may use.
- Actions it may not take.
- A stopping condition.
- What to do when evidence is missing.
Anthropic reports that vague delegation caused subagents to duplicate work or investigate the wrong scope. The same failure appears in business systems. Clear boundaries matter more than adding another worker.
Accept the tradeoff
Multiple workers add coordination, latency, and more components to maintain. They can disagree. A failed handoff can lose context. Logs and evaluation become essential.
Use this architecture when the separation is meaningful, such as different permissions, domains, or tools. Do not split a five step workflow into five agents just because it sounds more advanced.
Build the smallest dependable system
A good Business Brain can provide one command center without pretending one universal prompt does every job.
Behind the interface, each capability can have the context, permissions, tools, and tests it needs. Straightforward work stays straightforward. Complex work is divided where the boundaries are clear.
The goal is not the largest agent.
The goal is a system the company can understand, test, and safely change.
Questions people ask
What is an orchestrator agent?
An orchestrator interprets the request, chooses a plan, and delegates bounded tasks to specialist workers. It keeps coordination separate from domain specific execution.
When should a company use multiple agents?
Use multiple workers when a task has distinct domains, tools, permissions, or evaluation criteria. Keep a single workflow when the steps are predictable and simple.
Are multi agent systems always better?
No. They add coordination, latency, cost, and more failure paths. Start with the simplest reliable workflow and introduce specialist workers only where separation provides clear value.