A factory, underneath the word, is a loop. A line that runs the same cycle over and over, each turn producing one more unit, the whole point being that you set it going and it keeps itself going. The agentic software factory, the version being built right now, puts the models inside that loop: they propose the work, do it, check it, and go round again, and you are promoted from typing to supervising. One loop, turning on its own.
I built one of these factories to improve clive, a tool that drives a shell to carry out command-line tasks with agents; the factory's job is to propose changes to clive and keep the ones that help. Simple enough to say. But a factory pointed at a real target that is itself moving does not turn out to have a single loop, but three. These three loops are not the same kind of thing, they emerged from the building the way the shape of a path emerges from walking it.
Two of the three loops are engines, and they are the ones the hype is describing. The factory improves itself, proposing a change to its own workings and grading it against its own fixed checks. clive improves under the factory, every proposed change measured against the real end state of a real shell, did the file get written, did the service come up. Those two are the same machine at two addresses. Each grinds. Each keeps or discards on a check that sits entirely inside its own world, so the factory never has to look at clive to know whether its own change helped, and clive's loop never has to look at the factory. That locality is the point of them, because a loop whose test is wholly inside itself is a loop you can let run fast and walk away from. Nothing outside it has to be asked before it knows the truth.
The third loop, however, is a different kind of thing. The two engines cannot see across the boundary between them, by design, which means something has to, or the two halves drift apart while each stays convinced it is fine. When I went to push a batch of clive's improvements out to its repository, the retries and self-repairing plans the push could not happen, because the part of the system that does it did not exist yet. Graduating the work onto the shared branch, pushing it where other people can see it, updating the notes, closing the issues it resolved, none of it was automated. So I did it by hand, and then turned straight round to start teaching the factory to do it. That is the third loop. It crosses the boundary and re-grounds each layer against the actual state of the other, it produces nothing you would call grunt work, it reconciles, and it runs slow, because checking one layer against the real state of the other costs more than checking a layer against itself. Three loops, then, but two kinds: two fast engines, and one slower loop connecting the gap between them.
Typically, the picture in everyone's head is a human above the loops, supervising, ready to step in. But it turns out, the engines do not need supervising; they are local and fast, the easiest part of all this to automate. The part that needs a person is the slow loop that crosses the boundary, because that is where the judgments live that no local test can make. Is the yardstick still valid, now that clive has changed under it. Did clive outgrow the test? Is this real progress, or is it the two engines agreeing with each other while both quietly drift from the world? You do not stand over that loop. You are it.
I noticed this in probably the most ordinary corner imaginable, the issue tracker. Teaching the factory to close resolved issues, my first instinct was the obvious one: a shipped commit names an issue, close the issue. The factory plans its own next work by reading its open issues. An epic that ships in slices would be closed the moment the first slice landed, and the moment it closed it would drop out of the factory's view, and the factory would forget to build the rest of its own plan. I had, earlier that same week, manually reopened exactly that kind of premature done. So closing got gated behind an explicit keyword in the commit, the developer saying close this and meaning it, instead of a blanket rule. Closing an issue is an actuator writing onto the factory's own input. The issue tracker is not a side system here; it is part of the surface the factory grounds its planning on, and an actuator free to scribble on it corrupts the ground the next decision stands on.
There is one more thing from that session worth seeing, because it is the same shape from another side. Every step in it that could not be undone waited for me. Merging the work onto a main branch, pushing to a repository other people can see, choosing to close an issue or only comment on it, each one stopped and asked, even in the middle of a long run the machine was otherwise driving itself. The engines ran wide and free; the irreversible acts queued behind a single human yes. It is the only arrangement in which a wide, fast system still has someone who can answer for what it does to the world outside it.
The bottom line is that automating the grinding of the factory is kind of easy. The factory can tell you its checks are green, but it cannot tell you the checks still mean what they meant last week. So steering the factory needs your judgment for the time being. To get to a fully automated factory and to close the slower loop still needs work. Time to point the factory it itself and let it figure this out.
Unlock the Future of Business with AI
Dive into our immersive workshops and equip your team with the tools and knowledge to lead in the AI era.