How I Run a Team of Bots

I stopped treating AI as one chat window and started treating it like a small team, with lanes, handoffs and a review gate. Here's how that works day to day, and what still needs me.

By Subash Adhikari · 2 November 2026 · 5 min read

Share on X

For a while I used AI the way most people do. One chat window, one long conversation, and me copy-pasting between it and everything else.

It worked, until it didn't. The context got muddy. The same assistant that was helping me fix a bug was also drafting an email and remembering my kids' swim class. Things leaked between topics, and I spent more time re-explaining than getting help.

So I tried something different. I set it up the way I'd set up a team.

One front door, many lanes#

I talk to one main assistant. That's the front door. It doesn't try to do everything itself. Its job is to understand what I'm asking and route it to the right place.

Behind it sit a handful of specialised bots, each with one lane:

Comms drafts anything that goes out under my name: email, Slack, chat messages, X posts.
Writer handles longer prose, like docs and blog posts.
Research does lookups and short briefings.
Scheduler owns my calendar.
Engineers build features in the codebases they're responsible for.
Test writes and runs the automated tests.
Review does a second pass on code, including a light security check.
Design Critic looks at anything visual before it goes further.
QA smoke-tests the real thing on a device or a deployed URL.
Ops looks after my machines and home lab.

None of this is clever. It's the same reason you don't ask your designer to run payroll. One generalist stays busy and mixes contexts. Named specialists keep each lane clean, and they can run in parallel when I've got a lot on. Clean context is most of what makes these tools useful.

Lanes need boundaries, not just names#

The first version of this was a mess, and it taught me that a name isn't a boundary.

Early on, the main assistant would happily start doing the work itself because it could. An engineer bot would write its own tests because it was already in the code. Two bots would pick up the same task.

What fixed it was writing the rules down, the same way you'd write them down for people:

The router routes. It stays free for my questions instead of running jobs in parallel when another bot owns that lane.
Engineers ship product code. They don't own the test suite. Test does.
Bots only pick up work I started or asked for. Nobody goes looking for tickets to "help" with.
Work for different areas of my life stays separate. Personal stuff never bleeds into work context, and one project's context doesn't wander into another's.

Each of those rules came from something going wrong first. That's fine. It's how most team norms get written.

The gate is the same for every change#

For anything that ships, there's one path:

Engineer finishes a change, Test adds coverage for it and runs the full suite, Review reads the diff, Design Critic looks at it if there's UI, QA smoke-tests it, and only then does it get promoted.

If you've read my post on code review in the age of AI-generated PRs, this will look familiar. The bots don't get a shortcut just because they're fast. If anything, the gate matters more because they're fast.

What surprised me is how much the separation helps. A reviewer bot that didn't write the code is genuinely better at spotting problems than the same bot asked to "check your own work." Fresh eyes still matter, even when the eyes are a model.

Routines do the boring, recurring stuff#

A lot of what I wanted help with wasn't one-off. It was the same thing every day or every week.

So those became routines. Things like:

A morning digest of email and calendar before I start the day.
Inbox clean-up a couple of times a day.
A reminder on bin night.
A Friday shortlist of blog topics, and a Monday draft once I've picked one. This post started that way.

Routines are where the time savings actually show up. Not in the impressive demos, but in the small things that used to eat ten minutes here and there and quietly stopped needing me.

Nothing goes out without me#

This is the rule I'm most strict about.

Bots can draft anything. They can't send anything to another person on my behalf unless I've explicitly said "send that". Not an email, not a Slack message, not a reply. A draft is cheap to throw away. A message under my name can't be taken back.

Same with money, deleting things, and publishing. This blog post, for example, was drafted on a branch. It doesn't go live until I've read it and said yes.

Most days I talk rather than type. Voxtype lets me tell the bot what I want out loud, rough and fast. Voice is easier, and it doesn't need to be polished. I spent years getting fast at Vim. Those skills get less of a workout now that talking covers most of what typing used to. What I don't do is let the bots invent the message. For anything I put out — blog posts, Slack, X, the lot — I decide what to say and what I mean. AI only fixes grammar, formats, and makes it readable. The thoughts are mine. The AI is the cleanup layer, not the author.

It sounds slow, but it isn't really. Most of the time I'm approving, not writing. And it means I trust the system enough to actually use it.

What still needs me#

Plenty.

Bots are good at following a process. They're not good at deciding which process is the right one. I still pick the priorities, make the calls when two things conflict, and decide what's worth doing at all.

They also don't know what they don't know. When something is ambiguous, the good behaviour is to ask me. Getting them to ask instead of guess took more tuning than anything else.

And taste is still mine. A bot can tell me a design passes a checklist. It can't tell me whether it feels right.

What I'd tell someone starting out#

Don't start with ten bots. Start with one assistant and notice where it gets confused. That's usually where a lane wants to split off.

Write your rules down. Every time something goes wrong, turn it into a sentence the bots can follow.

Keep a human gate on anything that leaves your hands.

It's less like using a tool and more like managing a small team that never sleeps and forgets everything you didn't write down. Treat it that way and it's genuinely useful.

Thanks for reading. You can also follow along on X or with RSS.