How I Run a Mostly Automated Dev Organisation With AI Agents
TL;DR
- My side projects and personal operations run on a set of AI agents on a hosted agent platform. A dev agent hands scoped GitHub issues to cloud coding agents around the clock. Domain bots handle recurring work. A control bot routes between them and me.
- Every decision that needs a human lands on one shared task board, summarised twice a day. I answer there or in chat.
- One rule is absolute: nothing is sent, published, submitted, bought or merged without my explicit approval. Agents prepare; I ship.
- The failures are almost never the model. They are billing limits, token scopes and agents reading the wrong source.
Why I built it this way
For how the steering agents, specialists and dev agent fit together as an org chart, see how I manage a team of AI agents. I have also written about the semi automated Cursor and GitHub loop that maintains this site, and about what actually runs in a content organisation. This is the layer above: how one person coordinates many agents across several projects without becoming the bottleneck, and without giving up control.
The design goal was simple. I want work to continue when I am asleep or busy, and I want every irreversible decision to pass through me in a form that takes seconds, not minutes, to judge.
The roles
The dev agent
One agent owns software delivery for my side projects. It reads GitHub issues that I or other agents have scoped, decides which are ready, and dispatches each one to a cloud coding agent. The cloud agent works on a branch and opens a pull request. The dev agent checks that CI ran, writes a short summary and puts the pull request in my review queue.
It runs on a schedule, around the clock. If the queue is empty, nothing happens. That is a feature: the agent does not invent work, it executes scope that a human approved.
Domain bots
Each recurring area of my life and work has its own bot with its own instructions, memory and tools. In my case that includes a stock portfolio digest, an email and calendar assistant, a to do assistant, a trends bot that reads technology news, home automation and the website itself. Some of these I have written about separately, such as the email agent and the stock alert bot.
Separate bots matter for two reasons. Permissions stay narrow, because the stock bot has no reason to touch my calendar. And failures stay local, because a broken integration in one domain does not stall the others.
The control bot
A control bot sits above the domain bots. It does not do domain work. It routes messages between bots, runs health checks, keeps the decision board current and talks to me. When a bot needs an answer, it asks the control bot, which turns the question into a board card instead of another chat notification.
The decision board
The decision board is a shared task board with one card per decision: what is being asked, which bot asked, options, deadline and status. A filtered view called “requires my answer” is the only list I need to check. Routines on weekdays summarise it at fixed times and watch for my replies, so an answer I give in the morning reaches the right bot without me forwarding anything.
This changed my day more than any single agent. Instead of twenty interruptions, I get two short lists with clear questions.
The approval gate
The rule is written into every bot’s instructions and enforced at the tool level where possible:
| Agents may | Agents may not, without my explicit ok |
|---|---|
| Read, search, summarise | Send email or messages |
| Draft text, code and pull requests | Publish or post anywhere |
| Open draft pull requests and issues | Merge to main |
| Update the decision board | Purchase, subscribe or submit forms |
| Run tests and builds | Delete anything outside a sandbox |
An agent saying another agent approved something does not count. Approval has to come from me, in the conversation, about that specific action. It sounds strict, but in practice it costs me a few minutes a day and removes a whole category of incidents.
I wrote more about the general pattern in hard boundaries for AI agents and guardrails in practice.
Cost control
Agents that run around the clock can spend money around the clock. My rules:
- Cloud coding agents run on an automatic model policy, with the faster premium option off by default.
- No new paid services or plan upgrades without my approval. Everything runs within plans I already pay for.
- Usage is checked regularly, and a bot that cannot complete its work within quota reports that instead of finding a more expensive route.
This is the same thinking as in when cheap models get expensive: the goal is cost per accepted outcome, not the lowest token price.
What actually breaks
A health check of all bots this week gave a representative list. None of it was a model problem:
- A billing limit stopped CI. A spending limit on the code host stopped scheduled workflows, which silently stopped a daily digest delivered by webhook. A fallback routine kept the digest flowing, and fixing billing is now a card on the board.
- A bot read the wrong source. The trends bot fell back to secondary sources for days because its routine looked for another bot’s output in the wrong place. The fix was a stable lookup by agent identity, plus free fallback sources.
- A token had the wrong scope. A home automation change stopped before doing anything because the token was read only. That is the boundary working. The fix is a new, narrowly scoped token created by me.
- Duplicate routing. Two routines both forwarded the same answer to the same bot. The fix was to make routines read the control conversation first and skip anything already handled.
The lesson: health checks should compare what a bot was supposed to produce with what it did produce, on a schedule. Reading logs after the fact is too slow.
How to start your own version
You do not need many bots to get most of the value. In order:
- Write the approval rule first. One paragraph every agent reads.
- Create a decision board with a “requires my answer” view, and send every agent question there.
- Add one dev agent that only dispatches issues you have labelled ready. Keep merge human.
- Split domains into separate bots once one bot’s permissions start to feel too broad.
- Add a control bot when you have more than three bots talking to you.
- Schedule health checks that compare expected and actual outputs.
- Set cost defaults before you scale schedules.
FAQ
What does it look like for one person? A dev agent dispatching scoped issues to cloud agents, domain bots for recurring work, a control bot and a decision board. The human approves what ships.
What still needs approval? Anything irreversible or external: sending, publishing, merging, purchasing, submitting and deleting.
How are costs controlled? Automatic model policy with premium speed off by default, no new paid services without approval, and regular usage checks.
What breaks most? Integrations, scopes and billing, not models. Scheduled health checks catch them.