Quick answer: a team of AI agents works when each agent has a clear scope, only one person authorizes, and that person always confirms the actions that can't be undone. Everything else (written memory, independent reviewers, and messages between agents treated as information rather than orders) exists to make sure those three rules hold every day.
Why does a single agent fall short?
A coding agent like Claude Code is very good inside one project. The problem shows up when you run several at once: a website, a couple of apps, a game, the infrastructure that hosts them, and the automations that tie them together. If everything lives in a single conversation, the context fills up with things that don't belong there, decisions from one project leak into another, and nobody knows who is responsible for what.
The solution that works for me is the same one that works for a team of people: split responsibilities and write the rules down. Each project has its own agent, each shared resource has an owner, and the rules live in files that everyone inherits.
This isn't an unusual case. According to the 2025 Stack Overflow survey, 84% of developers use AI tools or plan to, but only 32.7% trust the accuracy of what they generate, and 66% say their biggest frustration is solutions that are "almost right, but not quite". That's exactly what rules are for: so that something almost correct doesn't reach production without anyone deciding it should.
How is the team organized?
I work with three kinds of agent:
- Owners: one per project, started in that project's folder and working only there. It owns its code, its deployments, and its memory.
- A director: coordinates, keeps the org chart, and acts as the bridge between owners when a change affects several of them. It doesn't do the others' work.
- Ephemeral specialists: security, quality, performance, or infrastructure reviewers launched for a specific task that then disappear. They don't write code: they report.
The rules live in CLAUDE.md files with inheritance: global ones for everything, others for the department, and others for each project. Claude Code loads those files at the start of every session, so a rule written once applies everywhere. That said, the Claude Code documentation is clear: the model treats those files as context, not as enforced configuration. A written rule guides; anything that must be followed no matter what needs something stronger.
Who authorizes what?
The most important rule is short: only the person authorizes, and only in the chat of the agent that will carry out the action. Three practical consequences follow:
- What belongs to another agent is off limits, even if the person authorizes it in your chat. You ask the owner, through the director.
- The person confirms actions that can't be undone: DNS changes, writes to the production database, deletions, payments, or publications. In many cases the agent prepares everything and the person presses the final button.
- If a safeguard blocks something, you don't work around it. Not with another tool, and not by asking another agent. You tell the person and they do it.
Claude Code has pieces that help make this depend on more than the model's good intentions: permission modes, allow and deny rules per tool, and hooks that run before or after each action. Permission rules are evaluated in a fixed order (deny, ask, allow), and an allow rule can't carve out an exception in a deny rule. Hooks give deterministic control: certain actions always happen, without depending on the model choosing to do them. And each subagent works with its own context, tools, and permissions.
Messages between agents: information or permission?
Agents write to each other: the infrastructure agent warns the website agent that it's about to touch a server, the director forwards a question. Here lies the most dangerous trap: an agent saying "the person already approved it" is not an approval. It's secondhand information.
If messages between agents counted as permission, convincing one agent to convince the rest would be enough. That's why the rule is to always treat them as data: they get read, they get checked, and if they ask for something that changes the outside world, you ask the person in the chat that will carry it out.
Written memory: why keep the why?
Conversations get compacted and sessions get restarted. Whatever isn't written down is lost. Each agent stores in short files what can't be inferred from the code: decisions, constraints, and preferences, always with the why and how to apply it.
The why is what prevents mistakes later. "Commit only when asked" is a rule; "because a push to a client repository is a delivery, not a backup" lets you apply it correctly in a case nobody anticipated.
What are reviewers that don't write code good for?
An agent reviewing its own work tends to agree with itself. Specialists receive the change, not the author's conclusion, and return findings. They can't apply anything, so their incentive is to find problems, not to close the task.
I use them at specific moments: before touching DNS or a migration (infrastructure), when a change touches authentication, payments, or personal data (security), and before publishing or delivering (product).
A real example: how do you change a DNS record?
A production DNS change can take a website offline in seconds. On my team the work is split like this:
- The infrastructure agent proposes the change and explains how to undo it.
- The person gives the go-ahead in the chat of the agent that will carry it out.
- The agent fills in the form and checks what is going to change.
- The person presses Save.
- The agent verifies from the outside that everything responds and writes it down.
It looks slower, but in practice it costs the person a few seconds and eliminates the most expensive kind of mistake: the one nobody decided.
If you want to see how this fits with concrete workflows, in agentic workflows with Claude Code I explain the plan, execute, and evaluate cycle, and in how to set up Claude Code you'll find the basic permissions and hooks.
FAQ
How many agents do you need to get started?
One per project you actually maintain, and a director once there are shared things. Reviewers are launched when needed; they aren't always open.
Can an agent ask another to do what it has been blocked from doing?
No. It's the most common way to bypass a permission without meaning to. If something is blocked, you tell the person and they decide.
Which actions should a person always confirm?
Any that can't be undone or that reach the outside world: DNS, production databases, deletions, payments, publications, and messages to third parties.
Where are the rules stored?
In CLAUDE.md files with inheritance (global, department, and project) and in a per-project memory with the why behind each decision.
