Everyone wants a team of AI agents. Most teams need one agent and three good tools. Multi-agent architecture solves a coordination problem, and most projects do not have a coordination problem yet.
July 30, 2026Multi-AgentLeast PrivilegeArchitecture
Start with one agent and real tools. Add a second agent when it must not hold the same permissions as the first.
Most projects have a tooling problem, not a coordination problem
A large part of what gets described as a multi-agent system is a single agent with a few well-defined tools. That is not a criticism. It is usually the correct design.
Multi-agent architecture exists to coordinate work that genuinely needs coordination: parallel branches, competing strategies, separate trust levels. If the work is a sequence of steps that one model can perform with the right tools, adding agents adds overhead rather than capability.
What every handoff costs you
Context is summarized at every hop, so detail is lost in translation
Latency and token cost multiply with each additional call
Failures become non-deterministic and harder to reproduce
Root cause analysis turns into "which agent broke this?"
Evaluation gets harder because there is no single decision to score
When a second agent is actually justified
The useful question is not whether the task is hard. Models handle hard single tasks well. The useful question is whether the two parts of the work should be allowed to do the same things.
Different privileges
The strongest reason. If two tasks require different credentials or different levels of trust, they should not share a process, a context, or a token.
Genuine parallelism
Independent subtasks that do not need each other output can run at the same time. If the work is sequential, a second agent adds latency without adding value.
Context isolation
Long-running work can fill a context window with irrelevant history. Separate contexts keep each task focused instead of degrading over time.
Permission boundaries are defensible. Role labels are not.
An architecture diagram that says the planner agent asks the researcher agent describes a conversation. It does not describe a control. Both agents may still hold the same credentials, reach the same systems, and cause the same damage when something goes wrong.
A boundary drawn on privilege is different. It survives an audit because it can be enforced outside the model: separate service accounts, separate network scopes, separate sandboxes, separate logs. The model does not have to behave correctly for the boundary to hold.
Read only
Reader agent
Queries production data, logs, and metrics
Cannot commit code, cannot deploy, cannot write to any system
Propose
Builder agent
Opens pull requests and proposes configuration changes
Holds no database credentials, merges nothing without human review
External
Customer-facing agent
Talks to users and answers from approved sources
No write access to internal systems, no privileged data
A practical way to decide
Start with one agent, real tools, and a tight scope. Measure it. When you believe a second agent is required, try to complete this sentence: this agent exists because it must not be allowed to do X.
If you can name X, the split is a security boundary and it is worth the coordination cost. If you cannot, what you are describing is usually another tool call, and it will be cheaper, faster, and easier to debug as one.
The same principle applies to the rest of the stack. An agent that reads production data should not be the agent that writes code. An agent that opens pull requests should not hold database credentials. An agent that talks to customers should not have write access to anything internal.
Two versions of the same system
Split by role
Planner, researcher, and writer agents. Three prompts, one set of credentials, one blast radius. A prompt injection in the researcher reaches everything the writer can touch.
Split by blast radius
A read-only agent with production access, and a proposing agent that can open a pull request but holds no data credentials. Compromise one and the other boundary still holds.
The point
Multi-agent is a real pattern with real uses. It is just usually adopted for the wrong reason: the belief that more agents produce better reasoning. In production, the agents that earn their complexity are the ones that exist to contain damage.
Architecture is not how smart your agents are. It is what each one is allowed to touch.
Designing an agent system that has to pass an audit?
LetuxTech designs agent architectures around permission boundaries, approval gates, and audit trails, using private, managed, or hybrid models.
We help define the scope of each agent, the credentials it may hold, the actions it may take without a human, and the evidence it leaves behind.
