Orchestrating Agents Is Organizational Design
An agent gets good at whatever you make it responsible for. The choice is functional or process accountability.
We have run hundreds of autonomous coding agents, each running 8 to 24 hours at a time with no human in the loop. That holds together only because of how they are organized: each agent owns a clear mission end to end, not a function.
What surprised me was how closely managing them mirrored managing people. Make an agent responsible for a skill and you get quality; make it responsible for a job and you get the job done.
Much of what I read about the software factory now is about craft, better prompts and cleaner code. Craft matters, but more of it does not finish the job. A perfect part is not a finished product.
An old problem in organizational design
The instinct is to organize agents by craft, and it recreates the oldest problem in management. People are doing it right now: a builder agent, a QA agent, a PM agent, each a prompt in its own silo, passing work down the line. That instinct is reasonable, since a narrow agent is more reliable at one craft. But reliable parts do not add up to a finished job, because the job crossed all of them and belonged to none.
Every company faces the same fork. Group people by craft, all the engineers together and all the designers together, and you get a functional structure with real leverage: pooled expertise, shared standards, economies of scale. Group them around an outcome instead and you get a process-oriented one, where a single unit owns a result from start to finish. Stay purely functional and the business stalls, because no one is accountable for what the customer receives. Agents are no different. The wiring is new, but the failure is as old as organizations.
A job you can check, a skill requires judgment
A job has a result you can check; the worth of a skill is a matter of judgment. The process is the path from a customer’s need to that result, and one owner runs it end to end. The result carries a number you can read: more sales than yesterday, more users back this week, a shorter support queue than last week. Point an agent at one of those and you can tell, every day, whether it is winning.
Grade an agent on a number it has to move, not on its craft, and its behavior changes. It stops polishing the parts that already look finished and starts changing the ones that move the number, and those are rarely the same parts. “Write good code” gives you no such number. The craft was never tied to an outcome you could watch move, so nothing in it tells you whether the business got better. That is why a room full of skilled agents can feel productive and change nothing.
The same thing happens in code
The same split decides how you instruct a coding agent. Tell it to write good API endpoints and it hands you clean code that no user asked for. Tell it to build the endpoint that saves a draft, and to confirm it takes the right inputs and returns the right outputs, and it owns a job end to end. The first instruction grades a skill. The second grades a result.
That second instruction is how a software factory is built. You break the product into small blocks, each with a clear contract, each checked at its own inputs and outputs, so every block owns a job you can check against what the user wanted. Organize the same work by craft instead, spread across a dozen blocks, and no block is accountable for whether the user got it.
The human ends up in the loop
The cost is not just a worse product, it is where the work lands. When no agent owns the outcome, you do. You sit in the inner loop, carrying the builder’s code to the QA agent, the QA notes back to the PM agent, deciding each round whether the result is close enough and sending it around again. The agents run their crafts and you run the integration, revision after revision, because the one thing none of them owns is whether the job is done.
This is the same job I know from managing people. Put a head of design, a head of engineering, and a head of data under you, and you become the general manager who has to make their work land, and that integration is most of the job. Organize instead around a mission, with one autonomous team and one person driving it, and the integration is theirs while the steering is yours. Agents run the same way.
Make a single agent accountable for the job and the loop changes hands. A job has clean inputs and outputs, a boundary the agent runs inside on its own, looping against the outcome until it holds. A craft has no such boundary; spread across everything, it adds a check to every piece of work, and the checks fall to you. You move to the outer loop, scoping the job on the way in and deciding whether to ship on the way out, while the agent owns the inner loop. You cannot sit in the inner loop of many agents at once; the gates are the only place a human fits.
The final look stays human
None of this means craft stops mattering. An agent needs both: a job to own and the craft to do it well. We spend real effort training craft into our agents and verifying it automatically on every run, so each one owns the technique as much as the outcome.
But the instinct is still backwards. People pour themselves into the process, hand-carrying the work, when the process is exactly what an agent can own. Hand it over, and keep your judgment for what no rubric reaches: a look at the finished product, from the right altitude, to see whether it is actually good.
Give an agent a function and you get a specialist who needs you in the loop. Give it a job and you get an owner that runs without you. Orchestrating agents is organizational design.