Tom Hundley
🤖 Ghostwritten by Claude Opus 4.8 · Fact-checked & edited by GPT 5.5
The answer is no: Optimus Prime should not write code. It should route work to agents that do.
That design choice is not just a matter of taste. Agent engineering research consistently favors single-responsibility agents: narrow agents with bounded tool grants, clear success criteria, and clean handoffs. They are more reliable and easier to debug than monolithic agents that try to classify, plan, execute, review, and communicate inside one opaque loop.
The same pattern appears across current production guidance from Google, OpenAI, and UiPath: split agents by specialization, then use a supervisor or orchestrator to route work to the right sub-agent. CrewAI’s role-based team pattern is the closest public analog to this kind of crew structure.
The trade-off is real. Specialization improves isolation, but every handoff creates a new trust boundary. The architecture only works if delegation is typed, validated, logged, and protected by least-privilege tool access.
TL;DR: The dev orchestrator should decide what needs to happen, not perform every task itself.
The single-responsibility principle started in object-oriented design: a module should have one reason to change. Applied to AI agents, it means each agent should have one clear job, one bounded set of tools, and one definition of success.
For a development crew, the orchestrator’s job is routing: understand the request, decompose it into tasks, choose the right specialist, and track completion. The moment that same orchestrator also writes code, edits files, runs tests, and opens pull requests, it has two unrelated responsibilities: deciding what should happen and doing the work itself.
That creates tangled failure modes. A routing mistake and a code-generation mistake now live in the same context window, share the same trace, and may be hard to distinguish after the fact. Keeping the orchestrator in the routing seat makes evaluation sharper: did it delegate correctly? Keeping implementation inside a worker makes the worker easier to assess: did the code satisfy the task and pass review?
Two narrow questions are easier to answer than one sprawling one.
TL;DR: Monolithic agents accumulate tool surface area and mixed responsibilities; specialist agents keep failures isolated.
Every tool granted to an agent expands both its power and its risk. A do-everything agent may need access to source control, deployment systems, messaging, calendars, billing, and customer records. When something goes wrong, the investigation has to untangle tool misuse, context pollution, planning errors, prompt injection, and execution mistakes in one place.
A specialist agent gives the system a smaller blast radius. A coding worker should hold code-related tools and nothing else. A communications worker should hold communication tools and nothing else. If a task is malformed, out of scope, or malicious, the worker should lack the authority to act outside its lane.
This is the practical reason agent vendors and framework authors keep converging on supervisor-and-specialist architectures. Google, OpenAI, and UiPath all recommend splitting agents by specialization and routing work through an orchestrator. CrewAI’s role-based team pattern reflects the same idea: define distinct roles, give each role the tools it needs, and coordinate the team rather than stuffing every capability into one prompt.
The goal is not elegance for its own sake. The goal is failure isolation. When a specialist fails, the system can ask a bounded question: was the task contract wrong, was the specialist wrong, or was the tool call wrong? That is much easier than debugging a monolith that does everything behind one conversational interface.
TL;DR: A two-orchestrator, ten-worker fleet maps cleanly to a production-style control plane and execution-node architecture.
The topology has three conceptual layers. First, a front-door classifier receives inbound requests and determines the broad category of work. Second, the relevant orchestrator decomposes the request into discrete tasks. Third, specialist workers execute those tasks under scoped permissions.
The important rule is simple: orchestrators route; workers execute. Optimus Prime can understand a development request, break it into implementation and review tasks, and choose the right worker. It should not hold code-mutation tools itself.
The handoff should be a typed contract rather than a free-form prompt. A delegation envelope can make the boundary explicit:
export interface DelegatedTask {
taskId: string; // Traceable end-to-end identifier
kind: 'code.implement' | 'code.review' | 'comms.send';
issuedBy: string; // Orchestrator identity
assignedTo: string; // Worker agent identity
goal: string; // Single, concrete objective
contextSlice: ContextSlice; // Only what the worker needs
allowedTools: string[]; // Explicit least-privilege grant
deadlineMs: number;
}
export interface ContextSlice {
repo?: string;
branch?: string;
files?: string[];
// Not the full conversation history
}That contract does three useful things. It limits the worker’s objective, narrows the context passed downstream, and makes tool grants explicit. The worker can reject a malformed or unauthorized task before touching any external system.
The two-orchestrator plus ten-worker pattern also fits production fleet architecture. The orchestrators act as a centralized control plane: classify, decompose, route, and monitor. The workers act as execution nodes: pick up scoped tasks, perform work, and return results. A small control plane directing a larger worker pool is easier to reason about than a single agent trying to perform every function at once.
TL;DR: Specialization improves least privilege, but only if every agent-to-agent handoff is validated and constrained.
The honest cost of specialization is that every handoff becomes a trust boundary. When an orchestrator delegates to a worker, the worker receives a payload assembled by an LLM. If the orchestrator is confused, compromised by prompt injection, or simply wrong, it could emit a task that asks the worker to do something destructive or out of scope.
Three defenses are non-negotiable at the worker boundary:
DelegatedTask against the shared contract and reject anything malformed, unauthorized, or outside their role.allowedTools field should be enforced by the runtime, not treated as advice inside a prompt. A coding worker should not be able to send email; a communications worker should not be able to mutate code.taskId should follow the task from orchestration through execution, review, and completion. Destructive actions need attributable provenance.Context leakage is the subtler risk. A specialist should receive only the slice it needs: perhaps a repository name, branch, target files, and acceptance criteria. It should not receive the full conversation history by default. Smaller context slices reduce accidental disclosure and make it easier to audit why a worker acted.
The security model is therefore not agent-to-agent trust. It is agent-to-agent verification. The orchestrator may propose a task, but the worker boundary decides whether that task is valid, authorized, and executable.
TL;DR: Single-responsibility agents work best when roles, tools, handoffs, and evaluation criteria are explicit.
A single-responsibility agent is an AI agent with one narrow job, a bounded set of tools, and a clear definition of success. Instead of asking one agent to plan, code, test, review, and communicate, the system assigns each responsibility to a specialist and coordinates them through an orchestrator.
Because routing and execution fail in different ways. An orchestrator should be evaluated on whether it understood the request, decomposed it correctly, and chose the right worker. A worker should be evaluated on whether it completed its assigned task. Combining both responsibilities makes failures harder to isolate.
| Dimension | Monolithic Agent | Manager + Specialist Bench |
|---|---|---|
| Tool surface | Large and shared | Small and scoped per agent |
| Debuggability | Failures are tangled | Failures isolate to a layer |
| Credential scope | Broad access | Least privilege per specialist |
| Context handling | Often carries too much history | Passes a narrow task slice |
| Evaluation | One sprawling success condition | Multiple narrow success conditions |
Yes. Each handoff creates a new boundary where malformed tasks, prompt-injected instructions, or overbroad context can propagate. The mitigation is to validate the task at the worker, enforce scoped tools in the runtime, log delegation events, and pass only the context needed for that task.
The orchestrators form the control plane: they classify work, decompose requests, route tasks, and track state. The ten workers form the execution pool: they receive typed task envelopes and perform scoped work. That split aligns with production fleet patterns where centralized coordination directs a larger set of execution nodes.
TL;DR: Specialists win because they narrow tools, isolate failures, and make trust boundaries explicit.
TL;DR: Specialization is not just cleaner architecture; it is the foundation for safer, more testable agent systems.
Single-responsibility agents make production AI systems easier to reason about. They reduce mixed responsibilities, keep tool access scoped, and make failures easier to trace. A supervisor can decide where work should go, while specialist workers execute under narrow contracts and constrained permissions.
The pattern does not eliminate complexity. It moves complexity into the boundaries: task schemas, routing logic, validation, observability, and evaluation. That is the right place for it. Boundaries can be tested. Tool grants can be audited. Delegation events can be traced.
Once workers execute in isolation, the next hard question is measurement: how does the system know each specialist is doing its job well? Schema validation proves that the handoff was well formed; it does not prove the output was good. The natural next step is per-agent evaluation: testing each specialist against its own definition of success and catching regressions before they reach production work.
Discover more content: