Designing a team of agents, not one monolithic AI

The instinctive way to build AI into a product is to make one agent that can do everything — a single assistant with access to all the data and all the actions, ready for any request. It demos beautifully and it's the wrong design. A monolithic super-agent is the hardest possible thing to trust, to bound, and to debug, precisely because it can do anything. The better pattern, and the one that scales, is a team of small agents, each scoped to a narrow role. Counterintuitively, breaking the AI into pieces makes it both safer and more capable. Here's why, and how to build it so the pieces stay governed.

Why the monolith is the wrong shape

A single agent that does everything has to be granted everything, and that's the root problem. It needs read access to all your data, write access to all your actions, and the destructive capabilities for the rare task that requires them — so it permanently holds permissions it uses one percent of the time. There's no least-privilege story, because least privilege is incompatible with 'one agent for all jobs.' The blast radius of any mistake is your entire workspace, all the time, because the agent always has the run of the place.

It's also undebuggable. When the monolith does something wrong, you're inspecting one enormous, general prompt that's trying to be good at triage and planning and reporting and cleanup simultaneously, and the behavior of any one task is tangled with all the others. You can't isolate what went wrong because nothing is isolated. And it's brittle: a prompt injection or a confused instruction lands on an agent that can act anywhere, so a single confident mistake has maximum reach. The monolith concentrates capability, risk, and opacity all in one place — exactly backwards from how you'd design any other system you needed to trust.

Small, scoped agents bound the blast radius

Now picture the same capability split into a team. A triage agent that reads inbound requests and routes them — it needs the tools to read and categorize and assign, and nothing else. A planning agent that helps shape cycles and roadmaps — it touches issues and projects within its scope. An audit agent that summarizes activity for review — read-only, by design. Each agent is clamped to exactly the tools its role requires, drawn from the canonical tool registry, so the blast radius of any single agent is bounded to its narrow capability. If the triage agent misbehaves, the worst it can do is mis-triage; it has no power to delete a project, because that tool was never in its set.

This is just least privilege applied to AI, and it pays the same dividends it always does. Each agent is legible on its own — a small, focused prompt doing one job, which you can read, test, and reason about in isolation. When something goes wrong, you know which agent and which narrow set of tools were involved, so debugging is bounded too. And capability actually goes up, not down: a specialist agent with a tight scope and a focused prompt outperforms a generalist trying to be everything at once, the same way a small expert team outperforms one overstretched person. You give up nothing by splitting; you gain safety, clarity, and quality.

The team only works under shared governance

A pile of independent agents isn't a team — it's chaos with extra steps. What makes a multi-agent system coherent is that every agent runs under the same governance, so their independence doesn't fragment the controls. Each agent's allowed-tools list comes from one canonical registry, so granting, restricting, or revoking a tool happens in a single place and applies everywhere at once. Every agent's queries run inside the same Postgres row-level-security tenant boundary, so no agent — however scoped — can reach another workspace's data; the database enforces it, not each agent's prompt. Every destructive action any agent attempts routes through the same propose/approve broker, so a human approves it regardless of which agent proposed it. And every read, write, proposal, and approval from every agent lands in the same immutable audit trail.

That shared foundation is what turns separate agents into a governed team. Coordination becomes legible: when the triage agent hands a shaped request to the planning agent, the handoff is on the record in the same trail as everything else, not buried in a black-box orchestration layer. You can see what each agent did, in order, attributed correctly, with the destructive steps brokered. The agents specialize, but they all answer to one set of rules — which is the only way a team of agents stays as trustworthy as a single well-bounded one, rather than multiplying the risk by the number of agents.

It mirrors how teams already work

The reason this pattern feels right once you see it is that it's how human organizations already operate. You don't hire one person to do triage, planning, reporting, and cleanup with unlimited authority over everything — you build a team of specialists, each with bounded authority appropriate to their role, coordinating through a shared system of record. Support routes to engineering; engineering plans in cycles; a reviewer reads the audit log. Nobody has the run of the whole company, and the handoffs go through a common tool everyone can see. A team of scoped agents under shared governance is the same structure, which is exactly why it's easier to reason about than a super-agent that answers to nothing.

It's also easier to grow and easier to bless. Need a new capability? Add one more scoped agent with its own narrow tool set, and it inherits the registry, the RLS boundary, the broker, and the audit trail for free — you've extended the team without widening anyone's authority. And when a security review asks 'what can your AI do,' the answer is a clean list of specialists with bounded scopes and a shared governance layer, which is far easier to verify than one opaque agent that can do everything. Design a team of agents, not a monolith, and you get a system that's safer to run, simpler to debug, more capable at each job, and honest enough to pass the review that decides whether any of it gets turned on at all.