07.01 · Concept
When one agent is not enough
Justify a second agent in terms of context, tools or permissions — not vibes.
A second agent is warranted only when it marks a real system boundary: different context, different tool access, or different authority. Treat agents as scoped service components, not extra personalities. If another agent sees the same information and can do the same actions, it usually adds latency, coordination cost, and failure modes.
What this lesson answers
- when should I add another AI agent
- how to justify multiple agents in architecture
- multi-agent boundaries context tools permissions
Notes
A second agent is justified when it creates a real boundary in the system, not when it sounds more autonomous. Good boundaries usually come from context, tools, or permissions. One agent may not fit all relevant information into its working context, may need incompatible tool access, or may require a different authority level, review role, or operational responsibility. If none of those boundaries exists, a second agent is often just extra latency and failure surface.
Think of agents less like people in a meeting and more like separately scoped service components.
Common questions
- When is a second agent actually justified?
- Use another agent when it creates a meaningful boundary in the system. Typical reasons are separating large or sensitive context, restricting tool access, or enforcing different permissions and review responsibilities. If the agents share the same context, tools, and authority, the split is usually cosmetic rather than architectural.
- Why not just use multiple agents for better reasoning?
- Multiple agents do not automatically improve reasoning. If they are driven by similar prompts and similar models with the same information, they can duplicate work, reinforce bad assumptions, or create noisy disagreement. The value comes from specialisation that changes what an agent can see, do, or approve.
- How should I think about agents in a multi-agent system?
- Think of each agent like a separately scoped component with an input contract, goal, context, tools, and permitted actions. Orchestration is the logic that routes work, delegates tasks, handles handoffs, and combines results. That framing makes architecture decisions clearer than treating agents like people in a meeting.