I had the factory, but I was mostly thinking about the floor
Today I read a piece about governing AI agent loops, and about halfway through I stopped and wrote down two words: control room.
I’ve already written an article called My Path to the Dark Factory, so it would be silly to pretend the factory metaphor just occurred to me. I got the term from Dan Shapiro’s five levels of AI-assisted software development. At Level 5, you put specs in and software comes out.
At the time, I was thinking mostly about the darkness. Fewer people standing beside the machines. More work moving without a person writing every line or watching every step. I wasn’t really thinking about the full factory, where the lines coordinate, how the work on one line affects another, and who has the authority to stop production.
The control room was the part of the metaphor I hadn’t followed through.
That probably says something about how my brain works. When I was twelve, I wrote assembly-language games on a graphing calculator, mostly so I could show them off to my friends. Before that, I packed drawings with so many little details that they looked like homemade Where’s Waldo pages. I’ve always liked the big picture, but I tend to get stuck on the little pieces and how they fit together.
I can see the same trail through the last few months of this newsletter. The State of Agentic Development and Why Most AI Coding Rollouts Stall were about tools improving faster than the habits around them. Pencil-Whipping the Agent was about approvals that look like review but aren’t. Generation Got Cheap. Deciding Didn’t., The Meter Is Always Running, and The Work Has to Survive the Handoff kept pulling me toward decisions, stopping conditions, and the context that has to survive after one agent session ends.
I didn’t plan those as a series about a control room. They were just the same problems showing up from different directions.
Agents are outrunning the natural coordination points
Because agents move so much faster, there’s less time for the natural coordination events to happen.
In a traditional agile team, you discuss the work up front, plan a sprint, and use whatever system you have to decide what you think can fit. If you’re using something like Shape Up, maybe you’re focused on vertical slices instead. Either way, you’re tackling some amount of work in a time-boxed period.
That time box usually gives you a few weeks. You can call a heads-up ahead of time and say, “These two features are related. We need to coordinate around that.” People have time to notice the overlap before both sides are done.
Agents compress that time. If you give them loose specs without spending enough time on what really needs to be built, the opportunity for them to step on each other’s toes gets bigger. By the time the conflict becomes visible, both agents may be trying to check in completed code and somebody is coordinating merge requests that don’t agree with each other.
At that point, engineers can end up sledgehammering the changes together. I keep thinking about this as using AI as a sledgehammer. Instead of fully understanding the product need, the customer problem, how you want to solve it, and how it should fit into the rest of the system, you give an agent vague requirements and see what comes back.
I’ve heard the advice that the newer models are really good and you shouldn’t over-prompt them. Just let them work. I think that can be fine for a specific, narrow problem. When you’re talking about a new product feature, though, the agent doesn’t necessarily understand the whole picture because the whole picture was never given to it.
The sledgehammer version is to have three agents build the feature three different ways. If the engineer doesn’t like the result, do it again. That’s wasteful, it uses a lot of tokens, and it takes away the opportunity for a person to slow down long enough to understand the actual product decision points.
I think this is also where some of the AI slop comes from. If you don’t spend enough time at the beginning thinking through what you’re trying to do, you’re outsourcing the product thought process to the agent doing the work.
There are really two bookends here. At the beginning, the team has to coordinate what it is trying to accomplish. At the other end, somebody has to decide whether the result actually solved the problem the way the team intended.
That isn’t too hard for a solo developer working on one project because most of the picture can stay in one person’s brain. Add more engineers, product people, and agents, and I don’t think we can assume everyone understands the full picture anymore. The number of people using agentic coding tools goes up, the amount of work in motion goes up, and the mess grows with it.
This is how I make sense of stories where a company goes heavily into agentic development but sees little improvement in overall throughput, even though individual engineers feel like they’re doing ten times as much work. There is more work happening, but there isn’t necessarily more value being generated. The apparent gain gets eaten up by coordination.
The constraint didn’t disappear
A close friend recommended both Eliyahu Goldratt’s The Goal and Gene Kim, Kevin Behr, and George Spafford’s The Phoenix Project to me. I listened to both at different times. When we were talking recently about how their ideas apply to agentic development, I realized I might be blending a few scenes together.
That makes sense because The Phoenix Project intentionally carries much of The Goal into technology work. One of its authors has described it as an homage that mirrors much of the earlier book.
The idea I’m carrying from both is the constraint. You can make every station look busy without improving the output of the factory. The whole system still moves at the pace of the thing holding it back.
Software has inventory, even if it doesn’t sit in a physical pile. A spec is waiting for clarification. A file is waiting for review. A decision is waiting in somebody’s inbox. Test results are waiting for somebody to decide whether they matter.
Coding used to be one of the slower stations. Agents speed that up, but the constraint doesn’t disappear. It moves into product decisions, review, context, and coordination. Faster machines can make the pile bigger if they keep producing while the next decision waits.
This is part of why I’m less interested in autonomy as the main measure of progress. It’s impressive that an agent can run longer without help. I’m more interested in whether it’s still doing the right work, who can redirect it, and what happens when it should stop.
The source article makes the same point from the runtime side. A loop can keep accumulating model charges while a dashboard accurately displays the spend. The dashboard isn’t broken. It’s watching the accident.
A control room needs more than visibility. Somewhere outside the loop, there has to be real authority to stop it. The team needs a version of that authority too, because ambiguous work sometimes shouldn’t start and a completed process shouldn’t be the only judge of whether the result is done.
I’ll play the con first
I keep asking myself the same question, and I struggle sometimes with accurately describing the difference. So I’ll play the con first.
A team can fairly say, “I already have project management. It logs tickets. I can see what everybody is working on. I can coordinate that.”
The problem is that the context doesn’t really get injected into the agentic coding flow throughout the process. Agents need to coordinate what they’re doing against the big picture and understand, along the way, what other agents are working on.
If you leave that handoff to humans, it’s just not going to happen consistently. You’re not going to stop a productive session every few minutes and say, “Let me get a summary of where my agent is. Now let me hand that back to the other people on my team so they can make sure their agents aren’t stepping on its toes.”
That creates more work. It also depends on everyone knowing who needs the context before the collision happens.
The daily stand-up is the human version of this. People get together, explain what changed, find the overlap, and bring the right person into a decision. Agents need something like that, but they don’t have to operate on the human schedule of one stand-up and then “don’t bother me again until tomorrow.” They can surface those decision points as the work moves.
That’s the distinction I’m trying to get at. A task board can say three tasks are in progress. A control room should be able to see that one agent made a decision that changes another agent’s work and bring the right human into that decision before both sides keep building.
If it can’t do that, then I agree with the objection. It’s project management with robot icons.
I know where the edges aren’t
Right now, the control room isn’t intending to do the coding itself. It isn’t trying to displace the coding tools. It isn’t a harness.
I’ve heard the term “meta-harness” thrown around, although that depends on the definition. If a meta-harness coordinates the robots doing the coding, I picture that more like a line foreman in the factory. It helps the robots coordinate handoffs with one another on the line.
The control room has to coordinate across a larger picture. Different projects can affect each other. Different product teams can be working toward related outcomes. Work on the floor still has to connect to what the rest of the company is trying to accomplish.
I’m not really good at putting the boundary into words yet, but I know I don’t want the control room to become the harness. That’s also why I don’t think it should own the robots. The App Is Not the Point Anymore made a version of this argument earlier. People should be able to keep using the coding tools that work for them. Requiring every machine to come from one manufacturer might make the diagram cleaner, but it would get in the way of the factory.
On the other side, the control room isn’t trying to displace product knowledge, product synthesis, or product strategy. There are tools trying to blend customer calls, product analytics, and other inputs to decide what a product needs next. I don’t think the control room should make that decision.
What I think it should do is understand the pieces that have to be coordinated to get an intentional product change implemented into a real system. It should keep the product decision connected to the execution, and bring people back into the decision when the work exposes something new.
Those two extremes are still a little fuzzy for me. I know what it shouldn’t own more clearly than I can draw the exact border around what it should.
I also know this isn’t coming from one source. “Own the Outer Loop” makes a related argument about agents handling execution while people retain the verdict at the boundary. An analysis of roughly 400,000 coding-agent sessions found people making more of the planning decisions about what to do while agents made more execution decisions about how to do it. A 2026 survey found organizations generating AI code faster than they were building the policies and connected workflows needed to control it. Recent requests for startups are circling company memory and long-running shared agent work from another direction.
Those aren’t all the same idea, and they aren’t all describing the same product. I think they’re different signs that the coordination around execution is becoming a problem worth naming.
I still don’t know whether the control room is one product or a set of controls owned by different systems and people. I don’t know how much governance a team will tolerate before it becomes drag. I don’t know how much evidence is enough before review becomes another wall of text nobody reads.
What I do know is that leaving humans to stop every agent session and manually pass the context around isn’t going to work. Agents are moving too fast for that, and they’re only going to get faster. That’s the part of the factory I’m trying to understand now.