One of my AI agents found a bug. Three other agents, each working on its own problem in its own copy of the code, needed to know about it, because their problems were all related to the same piece of work. Getting that one finding to those three agents is where the trouble started.
I often work on large problems that have many moving parts. They need to be broken into smaller problems, and on this codebase each of those gets its own git worktree, its own AI agent, and often its own handoff document. That part is fine. The hard part is coordinating them, because the pieces depend on each other.
For a long time the coordination ran through handoff files, and I found it error-prone. A finding in one agent’s work had to be written up and forwarded to every other agent it affected. Every forward was a chance to leave something out. If one agent never heard about it, its piece drifted, and I found out when the pieces were put back together.
What fire-and-forget sub-agents don’t fix
The obvious tool for this is letting an agent spawn its own sub-agents. It does help get through some tasks faster, and it burns credits doing it. What it doesn’t give me is any visibility on what is happening, or any way to influence the direction once the sub-agent is running. I get a summary back when it finishes, which is exactly where the detail goes missing. If the sub-agent misread a file, the parent doesn’t know. If the parent misread the sub-agent’s report, I don’t know either.
For a small contained lookup that is fine. “Find every place this property is assigned” is a good job to hand off and forget about. Nothing gets changed. For real work on a piece of the problem, it isn’t fine, because I can’t see it and I can’t steer it.
What did fix it: sub-agents you can talk to
Learning that agents can send messages to a sub-agent by that sub-agent’s short name was a game changer for me.
Now there is a top agent coordinating many sub-agents, each on its own part of the problem, in its own worktree. If one sub-agent finds a problem, the parent agent can elect that a certain set of sub-agents needs to be updated, or brought back in line with the big picture, and it sends them the message directly. The communication goes both ways. A sub-agent can push a correction up to the parent, and the parent can push it across to whoever needs it. Nothing is forwarded by hand through a file.
That bug at the top of this piece now goes: sub-agent finds it, tells the parent, parent decides which three need to hear it, three messages go out, and I can read all four of them.
In effect the parent agent is orchestrating all the sub-agents through two-way communication, and I, as the human, am observing and orchestrating the parent and the sub-agents overall. I can read every exchange. I can step into any of them. That is the difference from a sub-agent that runs off on its own: same delegation, but I can see the middle layer and I can talk to it.
I want to be precise about scope. This is for sessions running locally on my machine. I am not claiming it for cloud-hosted sessions, because I haven’t run the workflow that way.
Writing a novel with many chapters
The way I think about it is writing a novel with a lot of chapters. Each chapter goes to a different writer. There is one outline, and it is locked. Someone has to make sure the whole novel comes home at the end, with every chapter still telling the same story.
On this project the outline is a real document. It is the design document for the forensic scoring model, marked as locked, and the rule in the repository is blunt: if the code and the document disagree, the document is right and the code is a defect. Every agent that touches scoring reads it first. Nobody, human or agent, changes it without a stated reason and a review. That is what lets many agents work at once without the story drifting. They all agree with the outline, rather than with each other.
What it looks like on one codebase
At the moment there are around thirty worktrees open on this project, one of them for this article. Some are two-hour fixes. Some are research streams that have been running for weeks. One agent works in each folder and nowhere else, and the agent’s short name is the task, so when I want to know where the cutover work is, I ask the cutover agent.
Nothing lands on the main branch without me. I open the worktree folder, read the diff, and approve the commit. Pushing to production is a separate decision, made by me, after that. This is the same rule I wrote about in AI-Assisted Development vs the Old Outsourcing Model: trust nothing until I have verified it myself, whoever or whatever wrote it. Every agent knows this because it is written down as a hard rule, and every agent reads the rules before it starts.
Handoff documents are insurance
A live session holds its full context: every file it read, every decision it made and why, every correction I gave it. A handoff document, however good, holds part of that. Something is always left out, and it is usually the thing you needed.
So the workflow does not run on handoffs any more. It runs on keeping the local sessions alive and talking to each other. The handoff files still exist, more than twenty of them in the repository now, for the day a session dies anyway. One research stream has a trigger phrase: say two words at the start of a fresh session and it reads that stream’s handoff file before doing anything else. That is a recovery path for a dead session, nothing more.
Where it goes wrong
None of this is tidy in practice. Three failure modes have cost me real time.
Agents trusting a stale view. With around thirty worktrees, the main branch is routinely the least current view of the project. Each stream updates its own copy of the task list. An agent reading the main branch once told me, twice in one session, that a feature was “not started” when it was already built, deployed, and collecting data in production. The fix was a rule: before claiming anything is not started, list the worktrees and read the branch that owns that stream.
An agent waiting for a message that never comes. A review agent kicks off a long test run in the background, then ends its turn saying it will wait for the completion notification. That notification never arrives on its own. Three times in one session I got back a report that stopped halfway with no test numbers in it. Now the instruction is explicit: do not end the turn, block until the result exists, then report.
Deciding when a review agent is worth it. Every agent costs credits. A second independent review is worth paying for on a security change or a new architectural pattern. For a well-scoped fix across a handful of files, careful self-verification against real data has caught the actual bugs, and the review agent would have been a cost with no finding. I now default to self-verification and reserve the review round for work that earns it.
How a lesson sticks
Each of those failures became a short rule file in the repository. There are more than sixty of them now. Every agent reads the index before starting, so the correction lives in the project, not in one conversation that will be gone tomorrow. I wrote about why that matters in How a Corrected Rule Stays Corrected: a correction inside a chat competes with the model’s training and loses. A rule outside the chat, that every agent reads, holds.
Why this works
We engineers have always broken big problems up into smaller ones. That part isn’t new. What is new is having an AI run off with each of those smaller pieces, with a human in the loop coordinating and orchestrating the whole, and a parent agent doing the same one level down. I have found a tremendous improvement in both quality and productivity from this setup. The gain comes from being able to see every piece, talk to every piece, and still hold the outline.
If you’re running many agents on one codebase and have found a way to keep fire-and-forget sub-agents visible, I’d like to know how, because I haven’t.
Kenneth Springer is the founder of snapWONDERS, a digital forensic analysis platform for images and video. Every forensic check on the platform was built this way: many agents on small pieces, one locked design, and a person approving every change before it ships. snapWONDERS forensic analysis — no account required.