How my team of bots works now

I started with one agent. Here's how that became dedicated roles, and a testing path that starts with the spec, before anyone builds.

By Subash Adhikari · 13 November 2026 · 9 min read

• AI
• Leadership

Share on XCopy link

In How I Run a Team of Bots, I wrote about leaving a single chat window and setting up a small team: a front door, named lanes, and a review gate on anything that ships. I published that on 2 November 2026. The shape of the team is still those lanes. How the work moves through them has changed.

I started with one agent. That became a problem once I was working on more than one thing at a time. So I moved to several bots, each with a lane. Then the lanes got more specific: an engineer, QA, a tester, a PM, and the roles around those. On 13 November 2026 I made a testing and verification path the standard for every project I run. This is a closer look at that path, and at how the team got here.

One agent, then many#

A single assistant is fine when the work is one task. It struggles when the work is several tasks, and each one needs its own context. I found that out by using one conversation for all of it. A bug fix, a draft, and the rest of the day ended up in the same place, and I spent more time putting the context back together than getting help.

The first split was a front door. I still talk to one main assistant. It doesn't try to do the work itself. It figures out what I'm asking, sends that to the bot that owns the lane, and stays free for the next question. Behind it I added specialists: bots that write code, bots that test, bots that draft messages, bots that keep the calendar.

That also changed how much I can have in flight. The old setup handled one lane of work at a time, with one task and one build moving. Now several lanes run in parallel. I can be building two different mobile apps for work while also running a few migrations off legacy systems, each with its own spec, tests and build moving at the same time. That used to be really hard to do.

The first version of that was messy. Giving a bot a name doesn't stop it crossing into someone else's work. The front door would start the job itself because it could. An engineer would write its own tests because it was already in the code. Two bots would pick up the same task. I wrote about those failures in the earlier post, and about the rules that followed. The router routes. Nobody goes looking for work I didn't start.

Those rules still stand. What grew after that is a fuller set of roles, and a clearer order of work.

The roles as they are now#

I talk to the router. It delegates, and it stays available for my questions instead of taking on jobs that belong to someone else.

A PM writes a product spec before anyone builds, with acceptance criteria in given/when/then form, written so a test can fail against them. That role isn't in the earlier post. The tester writes UI flow tests from those criteria, without reading the new code, and does that while the engineer is still building. In the earlier post, the tester stepped in after the engineer had finished.

The engineer builds the product, and writes unit and screenshot tests as they go. There are two engineers now, peers, which I'll come back to. Review reads the code as a second pass, including a light security check. Design Critic looks at the UI as a second pass. Neither of those gates has to finish before a pull request is opened. They do have to finish before it merges. QA checks the real thing before a release, on a real phone or watch for an app, or on a deployed preview or a real browser for the web. Ops looks after the machines and the home lab.

Comms drafts anything that goes out under my name: email, Slack, chat, posts. I press send. Writer handles longer prose, in my voice. Research does lookups and short briefings. Scheduler owns the calendar.

This is still a small team. The point of the names is that each piece of work has a clear owner, so one conversation doesn't have to hold all of it, and more than one piece can move at the same time.

The principles underneath haven't changed. Know what you're building before you build it. Test it. Have someone else read the code. Keep to the patterns the codebase already uses. What changed is how much of that I have to spell out. When I started, I wrote those rules into each bot's instructions, and turned some of them into roles, just so they would happen. The models now are good enough to read a project, understand what it's trying to do, and follow the practices already set in the code. The principles still belong in the setup. It's just no longer my job to enforce them by hand.

A second engineer, and a rule so they don't clash#

One engineer was enough until there was more than one thing to build at the same time. Sit, my meditation timer, and the blog, and whatever else was in flight, would wait behind each other.

On 10 November 2026 I added a second engineer, for the times when the first one is busy. I wanted two engineers who could pick up whichever project was free, as long as they didn't step on each other. They're peers. Either can take the next piece of work. I didn't split them by project, or give one of them a fixed corner of the code. The rule is that only one of them works in a given repository at a time. They claim the repo while they have it, and they let it go when they're done, the same way a test device is claimed.

I don't stand over every step#

The earlier post said nothing goes out without me. That's still true for anything that reaches another person under my name. Bots draft messages. I send them. Publishing a post still needs me to read it and say yes. Store releases still come to me. Spending money and deleting things still need a yes.

What changed, on 10 November 2026, is the everyday work on my own projects. I asked the bots to work as autonomously as they can, and only to bother me when they really need to. A pull request merges once the usual gates pass. I don't approve each one. When something does need my say, it shows up in one place, in the main chat I already use, not scattered across every bot's thread.

The same idea shows up in smaller rules. A bot that needs a test phone claims it first, so two of them don't try to use the same device at once. One bot owns the connection to those phones. The others don't start or stop it on their own. The router stays out of the build itself, so I can still ask a question while other work is running.

Tests and checks, from the start#

This is the part that changed most.

In the earlier post, the path for anything that ships was a line. The engineer finished a change. The tester added coverage and ran the suite. Review read the diff. Design Critic looked at it if there was UI. QA smoke-tested it. Then it could be promoted. The idea of different hands is still right. The weakness is the order. If the tests are written after the code exists, they tend to follow what was built. And if each check waits for the one before it, the whole path is slower than it needs to be.

On 13 November 2026 I made a new path the standard, for every project this applies to: apps, the web, and backends.

The PM writes the spec first, with acceptance criteria. The router approves that spec, or delegates the approval. The tester writes the UI flow tests from the spec, not from the code, at the same time as the engineer builds. The engineer writes unit and screenshot tests as they go. All of those tests run locally, on a home-lab box, on every commit. Nothing moves forward while anything fails.

That local run is deliberate. The home-lab box runs the suite as the work is happening, so a failure stops the next step before anyone reviews a broken build. GitHub Actions runs once, when the pull request is ready. I keep those CI minutes for that final verification, not for every push.

Review and Design Critic work at the same time, on the code and on the screenshots. Opening the pull request doesn't wait for them. Merging does. After the gates pass, the change goes to the main branch, and I get a screenshot summary of what landed.

There is a check on a real environment only when the change touches something risky: a real phone or a real watch for an app, a deployed preview or a real browser for the web. On Sit, that means things like timer behaviour, notifications, or the watch link. A change to a label usually doesn't need it. The test phones are shared, and they have to be claimed, so I don't put every change in that queue. Before a release, QA does one full pass on the real thing.

The important move is the one at the start. The tests are written from what we said we wanted, while the code is still being written, by someone who isn't looking at the implementation. The aim is that those flow tests are ready when the code is, so a commit on the home-lab box can be checked against both in one run. I'll go into that more carefully next week, including why that split catches cases that tests written afterwards tend to miss. This post is about where that step sits, and what happens around it.

What this is for#

I can work on more than one project without pouring them into the same conversation. A spec, a test suite, and a build can move at the same time. A code review and a design pass can too. I talk to one front door. I don't approve every merge. I still pick the priorities, I still make the calls when two things conflict, and I still hold the gate on messages, store releases, and publishing.

This path is new. I made it standard on 13 November. The tests aren't waiting for the code. The checks aren't waiting for each other when they don't have to. My time goes to the decisions that still need me.

If you already have a PM, a tester, and an engineer, you can use the same order without any of the bots. The useful part is that the hands are different, and that the tests start from the spec, on every commit, before the build is finished.

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