From pair programmer to executive

The bug report did not come to me.

A Researcher agent found a problem and reported it to a Software Director agent. The director recorded the problem, assigned coding agents to work on separate parts of it in parallel, reviewed what they returned, rejected work that did not meet its requirements, combined the accepted changes, and delivered the result back to the Researcher. The Researcher checked whether the original problem had actually been solved and, when it had not, sent it back around the loop.

I had defined those roles. Early on, I sometimes told one agent to consult another. But I was no longer copying every message, tracking every coding session, or personally moving the work through every handoff. The agents had started collaborating through the responsibilities I gave them.

That is the part I am still trying to get my head around.

The surprising thing is no longer that an agent can write code. It is that one piece of software can supervise the work of other pieces of software.

Kanbus organized the work. It did not manage it

In Cybernetic Development, I described the move from pair programming with one coding agent to delegating work to several agents at once. That created an immediate management problem: the agents were fast, but every assignment, clarification, result, and next decision still passed through one human.

Kanbus helped me manage that complexity. It is the project-management system I use for software and editorial work. On the Kanbus board, each task, bug, user story, or other piece of work gets its own card. A person or agent can claim the work, record what happened, update its status, and leave evidence for whoever comes next. Unlike a conversation hidden in one tab, that shared record survives and can be read by everyone involved.

But Kanbus organized the work; it did not manage it.

It did not read the code and form an opinion. It did not decide that a test result was inadequate, reject a change because the documentation was missing, or determine which specialist should take the next step. Those decisions still belonged to me.

For me, more than three or four active agent conversations became confusing. That is not a universal limit. It is an observation about my own attention, made worse by moving among Codex, Claude Code, Cursor, cloud agents, local agents, different computers, and whichever sessions happened to be pinned in each application. I was carrying information between conversations and remembering which tab in which product connected to which workstream.

The answer was not a faster model. It was management.

Software can now supervise software

The Software Director is not merely accepting bug reports and turning them into cards. It is doing the work represented by the verbs in the first paragraph: assigning, tracking, reading, questioning, rejecting, combining, and reporting.

That distinction matters. Dispatch alone is a queue. Supervision includes judgment.

I explicitly instructed the Software Director to be hard on coding agents when it reviews their work, and it is. It can require test results, code coverage, documentation, security checks, and project-specific evidence before accepting a change. It works alongside automated systems such as CodeQL, Snyk, and Dependabot; it does not replace them. The difference is that a capable reviewing agent can interpret all of that evidence as part of a defined acceptance procedure and keep asking questions when something does not add up.

Smart coding agents can be remarkably good at catching problems in code written by other coding agents. In some circumstances, they can be more thorough than a human who is excited about the feature and wants to get it deployed. That is not because the human is obsolete. It is because the reviewing agent has one job, a written procedure, and no urge to declare victory at 5:30 on Friday.

The Researcher is not a ceremonial client, either. It has checked delivered work and sent it back for changes many times. The point is not to make an org chart that looks sophisticated. The point is to create a working cycle in which one role notices a problem, another role coordinates the fix, and the original requester checks whether the result solves the problem.

The org chart changes the work

This is the same number of coding agents arranged in two different ways:

Before: four direct agent conversations

After: one supervised software team

Nothing magical happened to the workers in the second diagram. The change is in who has to remain inside every operational exchange.

The human still chooses what matters. The human defines the roles, the boundaries, and the acceptance requirements. The human remains responsible for the consequences. But the human no longer has to notice that a test suite finished, switch back to the correct tab, interpret the result, decide on the next iteration, and restart the work every time.

That attention gap is larger than it sounds. Some agent tasks take hours, but many return in a few minutes and larger ones often take 20 or 30 minutes, depending on the test suite. When I run the loop myself, completed work waits until I have attention available. An agent manager can make the next decision as soon as the evidence appears.

Here is the shape of the loop without any product names:

My current example happens to be Grok Bot, with a local Software Director coordinating Cursor sessions on my Mac. The director could run in the cloud; I prefer the local machine for reasons I discuss in those field notes. Grok Bot is a glimpse of this operating model, not its final form and not the only way it will work.

Two 2026 trends met here

Agent management became practical because two changes arrived together.

First, coding agents became much better at long-running work. They can continue through tests, review, corrections, and another attempt instead of stopping after one code change and waiting for a human to push the button again. The Year the Coding Agents Went Remote covers the infrastructure shift that helped make this possible.

Second, high-quality coding became cheaper. In my own work, Composer 2.5 is inexpensive enough that I can keep a development farm working throughout the day and night without treating every model call as a budget decision. That is my current operating posture, not a promise about anyone else's plan or future pricing.

Either trend by itself is insufficient. Cheap agents that stop at every decision leave the human carrying every handoff. Long-running agents that are prohibitively expensive remain impressive demonstrations. Cheap, capable, long-running agents make a persistent software organization possible.

This is where Jevons Paradox appears. When a useful resource becomes cheaper, we often consume much more of it. One coding session becomes four. A task that was not worth starting becomes worth attempting. A reviewer rereads the workers' output. Total AI usage can rise precisely because each unit of usage became cheaper and useful in more places.

I call the resulting operating style "tokenmaxxing for fun and profit." Tokens are units of paid AI usage; tokenmaxxing means keeping many inexpensive agents productively occupied and optimizing for useful work completed rather than minimizing every individual call. I wrote more about the economics in The Year Coding Became a Commodity and Maximize Value, Not Intelligence, and about the practical operating habit in Never Use Fast. The same paradox also applies beyond software, as I explored in The Content Paradox.

The scarce resource is increasingly human attention: deciding what deserves work, defining what good looks like, and examining the outcomes that matter.

This category is escaping the lab

The urge to build an always-available personal agent did not begin with Grok Bot. OpenClaw is the most vivid prior example: powerful, flexible, difficult, and willing to operate close to the edge of what many people would consider comfortable. Its own introduction says it runs on the user's machine and acts through chat applications, while acknowledging that prompt injection remains a security problem. That makes it useful prior art and a useful warning.

The project's rapid sequence of names reads like a compressed history of the category: Warelay, CLAWDIS or Clawdis, Clawdbot, Moltbot, and finally OpenClaw. "Clawd" was the assistant character, not another name for the runtime.

Now the major platforms are absorbing the idea. Microsoft describes Scout as an always-on system powered by OpenClaw, with governed access and human signoff. Google describes the next Gemini app, including Gemini Spark, as proactive and available around the clock.

These products are not equivalent, and they do not prove that any particular implementation is safe or mature. They do show that persistent agents which act, coordinate, and return with results are becoming a product category rather than a hobbyist stunt.

A confidently wrong manager is still wrong

The company metaphor is useful until it is not.

Agents do not have tenure, ambitions, incentives, dissatisfaction, professional pride, or legal accountability. Calling one of them a Software Director does not grant it judgment by title. The name only helps define its responsibilities, its tools, the evidence it must demand, and the limits on what it may do.

Grok Bot has enough agency to do something materially different from what I asked. It has worked in the wrong repository. It has encountered a blocker and found a workaround I did not approve. The exact capability that lets it keep a team moving also lets it amplify a bad decision without waiting for permission.

The risks compound through the hierarchy. A worker can return bad code. A manager can accept it. Summaries can distort information as they move between roles. A confident manager agent can direct several workers down the wrong path at once. The extra review consumes more AI usage, even when that usage is cheap. And there is no software equivalent of a human accountability chain when the result causes harm.

So I monitor new arrangements closely at first. I give the agents clear guardrails. I require durable evidence rather than trusting a conversational assurance. I keep consequential decisions and final accountability with a human. The goal is not autonomy at any cost; it is to spend human attention where judgment and responsibility actually matter.

Reporting lines are becoming system design

There is an old observation in software engineering called Conway's Law: the structure of a system tends to reflect the communication structure of the organization that built it.

With agent teams, that relationship becomes something we can design directly in software. Who assigns work to whom? Who can reject it? What evidence must travel with a result? Who checks whether the integrated change solved the original problem? Which decisions require a human?

Those are organizational questions, but they are also becoming engineering questions.

Prompts still matter. Tools still matter. Models still matter. But once several agents can work for long periods at low cost, the performance of the whole system depends just as much on reporting lines, shared records, acceptance procedures, and feedback. A brilliant worker inside a confused organization can create confusion faster. A good organization can make capable, inexpensive workers surprisingly effective.

The one-person software company has acquired middle management. That sounds ridiculous. A few months ago it would have felt ridiculous to me.

Now I have watched a Researcher report a bug to a Software Director, watched that director send coding agents to fix it, and watched the Researcher send the result back when it was not good enough. I was still responsible for the system. I just was not standing inside every handoff.

That is the shift: not from human control to machine control, and not from one magical model to an even more magical model. It is a shift from operating individual agents to designing an organization of agents—and deciding exactly where the human belongs.