Most advice about AI agents is about the agent: which model, which prompt, which tools. Once you run more than one, that stops being the hard part. The hard part is the same one every engineering leader has: people doing work you can't see, on intent they half understood, making decisions nobody signed off on.
Here's my argument. A team of bots needs management, not better prompts. The rules that keep a human team pointed in the right direction (clear ownership, a decision format, verification, visibility and goals) work on bots too, and they break down in the same places.
I run about a dozen bots. Each has a job: a lead bot that dispatches work, one for strategy, one that acts on approved plays, one for the web, and others. These are the rules I've had to write down so far, mostly by catching a bot doing the wrong thing.
My first instruction to my lead bot was about initiative: "from now on you find answers out and bring questions that require a decision or clarity from me."
That's the same bar I'd set for a person. Great work means gathering the context yourself before you come to me. A bot that asks me where a file is, or what a tool returned, is handing its work back to me.
That rule has a counterweight, and I learned it the hard way. A bot that never asks questions will run ahead on its own reading of what you meant. After one did exactly that, I put it plainly: "Do you see what happens when you don't ask me questions? You go off and do things without understanding my intent."
The split I've landed on: resolve facts yourself, but ask about intent. Facts are findable. What I actually want is only in my head until I say it.
One way I force this now is to make the bot show its thinking before it builds anything. When I needed KPIs designed, I didn't ask for KPIs. I asked: "list the requirements for the KPIs, then I want you to list basic physics of how this works. List them here, I will agree/disagree-- grade your output against industry precedent." Agreeing or disagreeing line by line takes me a few minutes. Unwinding a finished design built on the wrong premise takes much longer.
Bots are confident. That's useful until they confidently report something that isn't there. After catching one, I set the standard: "Verify a claim id where you say it is before sharing with me."
If a bot says a row exists, it should have read the row. If it says a task is done, it should have checked. Reporting is a claim, and claims get checked at the source.
Early on, a bot created a rule for the team on its own. It was a reasonable rule, but that wasn't the point. My reply: "Ask my permission next time, because you just made a rule and I ... have to live with it."
Bots should have a lot of autonomy over how they do their work. They shouldn't have autonomy over the rules everyone else then has to follow. That's a decision, and decisions come to me.
When a bot does bring me a decision, the format matters. I told my lead bot: "Your response should be your recommendation first and the other options. If you have to fish or reach for options there is likely only one sane option, and that's yes/no/discuss."
This rules out the most common failure in bot output: five padded options with no opinion. If the bot has done the research, it has a view. Lead with it.
I don't want my lead bot's chat to be where the details get worked out. My instruction was: "feel free to offload to specific agents so our conversations leave the details to a sub agent."
The same goes for building. My web bot doesn't write code itself. It hands the build to a Cursor cloud agent, which makes the change and opens the pull request. When I saw that, my reaction was: "cool. so you just pass it off to cursor to build." Each layer does the part it's good at, and the top layer stays readable.
I tried morning briefs and didn't like them. As I told my lead bot: "the briefs don't really please me, but the event driven workflows do. ... Most of the time I query things as I need them."
A brief is a report nobody asked for, delivered on the bot's schedule. An event-driven workflow wakes up when something actually happened. I'd rather get one message that matters than a daily summary I skim.
A bot that has to come back to you for access isn't agentic. I set a task to fix that: "You need to have access to web, cli, MCP, and browser so that I can message you or any bot and you have the resources to be agentic."
If I can do something from my desk, the bot I hand the task to should be able to do it too. Otherwise I'm the bottleneck again.
The bot that acts on plays was the first one that needed a leash. It's built to move fast, and fast without direction is dangerous. My rule: "hunter can't be a runaway bot, he has to have goal and is direct action. I need a strategist that controls hunter ... We are data driven and move based on data."
So the action bot is always aimed by a strategy bot that has goals and KPIs. My expectation is that every bot has a KPI and reports to a shared pebble, which is a small database my bots can all read and write. When I added revenue work, I asked whether it should be its own bot, and I added: "It need KPIs and to report to pebblebase as well."
Even with goals in place, I hit a wall: "I also need to see our tasks, scheduled tasks, and actions. I have no visibility into what we are doing, is that in the pebble too?" I asked for a red, yellow and green stoplight view of the KPIs, and for the bots' work to live in the same place as the numbers.
A manager who can't see the work ends up managing by asking for status. With bots, the fix is cheap: make every action a row, and look at the rows.
After a day of bots proposing plays on their own and drifting from what I wanted, I wrote it down as an operating contract. The loop: "We set the contract and write it as a play. We dispatch through you (chief) as the only front door. Execution and systems actors act inside the written rules and log. Weekly retro cites measurements and can force change. Only then stack the next strategy."
And the roles, in one line each: "Bots are pure actors. You are the dispatcher. Do not invent strategy." Then I had the 17 plays the bots had proposed parked or killed, to flatten the floor and start from what I'd actually approved.
The contract got its first real test the next day. The action bot's first weekly report came back with weak numbers, and it proposed changing its own target. My lead bot passed the proposal along and even recommended one of the options. My reply was one line: "Why is Hunter proposing anything?"
The lead bot owned the miss. The action bot withdrew the proposal, and its report was narrowed to measurements with their source rows, actions taken and blockers. Changes to tactics go through the weekly retro, through strategy, and nowhere else.
That's the lesson I'd pass on. Role separation only holds if whoever routes the work enforces it. A well-meaning bot will drift into strategy the moment the numbers look bad, the same way a well-meaning person would.
None of this is free. Each rule here came from a mistake I had to catch, and the contract means more structure than a single chat with a single bot. Management is work, whether the team is people or bots.
But the alternative is a dozen confident workers with no shared goals, no visibility and no line between acting and deciding. That doesn't scale for people, and it doesn't scale for bots.
My bots coordinate through pebblebase, my tool for building and hosting small apps through AI chat. The goals, KPIs, plays and action logs are pebbles: one SQLite file each, with rules that refuse bad writes, connected to every bot through one MCP URL. It's a free pilot at https://pebblebase.dev. If you run more than one agent, I'd like to hear which of these rules you've had to write too, and which ones you'd argue with.