How I Manage a Team of AI Agents: One Inbox, Steering Agents and a Dev Agent

In the stock bot post and the mail agent post I described single agents. This post is about what happens when there are many of them. My short answer: I manage AI agents the way you would manage a small team. One inbox for me, a steering agent per area, narrow specialists that read before they write, and a dev agent that turns every build into an issue I approve.

I run more agents than I can watch. Some follow trends, some read analytics, some keep my inbox and costs in check, and some write code. Building each agent was the easy part. The hard part was knowing what is going on, deciding what runs, and making sure nothing important happens without me. What fixed that was not a smarter model. It was an org chart.

TL;DR: key takeaways

• One inbox for the human. Specialists never message me. A steering agent per area collects their output and sends me one bundled message.
• Three tags. Every message to me is INFO (no notification), QUESTION or ACTION (both notify me). No “done” messages without news.
• Narrow specialists that read and alert first. Trends, analytics, legal and privacy, mail and calendar, marketing, site management and cost watching each have one job. Write access is earned, if ever.
• A dev agent that writes issues, not code. Everything that needs building becomes a GitHub issue with a goal and done criteria. I pick what runs, and a coding agent opens a draft pull request.
• Nothing merges, publishes or sends without my yes. An approval only counts when it is my own words, not when one agent tells another that I said yes.
• Quiet and cheap by default. Routines stay silent when nothing changed, and coding agents use the default model unless I ask for another.

The architecture in one picture

1. Me. I decide, prioritise and approve. That is the whole job description.
2. Steering agents. One per area: one for my own site, writing and visibility, and one for my company, which runs several small services. Each knows the context of its area and is the only agent that talks to me about it.
3. Specialists. Narrow agents that do the actual work, report to the steering agent and never act outside their scope.
4. The dev lane. A dev agent and the coding agents it hands work to. Code only moves forward through issues, a priority question and a draft pull request.
5. A human on every irreversible step. Merging, publishing, sending and spending wait for me.

One inbox, three tags

The first version had every agent talking to me directly. Within a week I stopped reading the messages, which defeats the point of having agents.

Now every specialist reports to the steering agent for its area, and the steering agent decides if, when and how something reaches me.

• INFO: something happened that I might want to know. It arrives without a notification.
• QUESTION: a decision only I can make, for example which of two angles to write about.
• ACTION: something only I can do, such as clicking an activation link or fixing a billing setting.

Two rules made the biggest difference. No acknowledgements: an agent never tells me it received something or that it is “done” unless there is news. And bundle: if three things happened, I get one message with three points, not three messages.

Narrow specialists that read before they write

Each specialist has one job and as few permissions as that job needs:

• Trends and news sends a short morning report with sources and a suggested angle.
• Site management watches this site: redirected or broken links, sitemaps, discoverability for AI assistants, and drafts of posts.
• Mail and calendar triages my inbox and writes reply drafts that I send myself.
• Content and SEO, analytics, legal and privacy and marketing do the same kind of narrow work for the company area.
• A cost watcher keeps track of quotas, caps and reset dates across tools.

The pattern is the same everywhere: read and alert first, write later. An agent that has spent a month pointing at the right problems has earned the right to draft. An agent that drafts well can earn a pull request. Very few earn more than that. It is the same idea as alerts instead of dashboards, applied to the agents themselves.

The specialists also feed each other on a schedule. The trend report arrives in the morning, and the site agent’s writing brief runs about half an hour later and builds on it. When an input is missing, the brief says so instead of guessing. And a routine that finds nothing new sends nothing. Silence is a valid report.

A dev agent that writes issues, not code

The rule I like best is the one for code. An agent that notices something to build is not allowed to start building it. Instead:

1. It sends the request to the dev agent.
2. The dev agent writes a GitHub issue in the right repository with a clear goal and done criteria, and flags whether the task is large or hard.
3. It asks me a priority question: here are the open issues, which ones should run?
4. Only the issues I pick go to a coding agent, which works on a branch and opens a draft pull request.
5. Checks run, I review, and the change is merged only after my yes.

That has two effects. Work that would otherwise disappear into chat history ends up as an issue that anyone, human or agent, can pick up. And I decide where the coding budget goes, instead of finding out afterwards. The issue-to-draft-PR loop on this site is described in Cursor Cloud Automations on This Site.

When does an approval count?

I expected the hard problem to be agents doing too much. The subtler problem was agents vouching for me.

Once agents talk to each other, a message like “he said it’s fine, go ahead” can arrive from another agent. It may even be true. But if agents accept it, any agent can approve anything on my behalf.

So the rule is explicit: an approval counts only when it is my own words for that exact action, said directly or quoted verbatim by a steering agent. A claim from another agent is a reason to ask me, not a reason to act. One yes covers one action, and a declined action is not retried another way. More on the general pattern in Guardrails in practice.

Cost and oversight

Many agents means many small costs. Three habits keep them in check:

• The default model for coding agents unless I name another for a specific task. Most tasks do not need the most expensive model.
• Spending caps on the tools. When a cap is reached, the work stops instead of spending more.
• A cost watcher that reports quotas and reset dates, so a stop is a known event and not a mystery.

Caps work, but they have a side effect I underestimated. One morning a brief simply did not arrive because a usage limit had been reached, and for a while automated checks on pull requests did not start because of a billing limit. Nothing broke, but nothing ran either. The plumbing needs monitoring as much as the agents do.

What did not work

• Every agent talking to me. Too many messages, so I stopped reading. Fixed with steering agents and bundling.
• One-off scheduled jobs for publishing. They misfired more than once, so publishing is now a manual step after my approval.
• Assuming agents can read each other’s output. Not every agent can see every other agent’s reports. The steering agent passes on what matters, and a brief says when an input is missing.
• Vague tasks. “Improve the site” produced activity, not results. A goal and done criteria in an issue produced results.

Why this matters beyond my own setup

Replace my areas with a company’s departments and very little changes:

This is what moving AI from pilot to operation looks like in practice. A pilot shows that one agent can do one task. Operation means many agents working at the same time without one person having to watch all of them, with clear roles, a single place where decisions are made, and a log of who approved what. It also makes the effect measurable, which is the point of proof of effect: issues opened, issues I chose to run, pull requests merged and messages that needed me are all countable.

What I would tell someone building their own

• Start smaller than you think. One steering agent and one specialist is enough to learn the rules.
• Write the forbidden list first. No sending, merging, publishing, deleting or spending without an explicit yes.
• Give the human one inbox. Specialists report to a steering agent, not to you.
• Make quiet days cheap. If nothing changed, nothing should arrive.
• Turn builds into issues. A goal and done criteria beat a request in chat.
• Only accept approvals from the human. Never from an agent speaking on their behalf.
• Earn write access. Read-only and alerting first, drafts next, and very little after that.

The models will keep getting better. The org chart is what makes them usable.