The Feature List Is Not the Factory

The market is filling with products that look like software factories. They show agents at work, projects moving, budgets changing, and people stepping in to approve results. Those surfaces can be useful. They can also give a coding agent a more impressive lobby without changing how software reaches production.

The distinction is not cosmetic. A dashboard matters when a blocked task leads to the evidence, decision, or intervention that can unblock it. An agent directory matters when it exposes responsibility, authority, and ownership. A project record matters when the original request, the chosen tradeoffs, the generated artifacts, and the acceptance decision stay connected. The feature is only real when it changes the route.

So do not compare platforms by counting screens. Ask the operating question behind each one. What decision does this surface support? Which state can it change? What evidence travels with that change? Who is allowed to make it? If the answer ends with a person copying context into another tool, the interface has documented the handoff without automating it.

A factory begins when a defined request enters a governed route. The system gathers the context that request is allowed to use, assigns work to a capable agent, limits what that agent may change, checks the result, collects the required judgment, releases the accepted change, and watches what happens next. Each stage consumes the last stage's output. Each transition has a reason to proceed or stop.

This is why adding more agents is not the same as adding more capacity. Five specialists can produce five partial answers and a sixth problem: somebody still has to reconcile them. Specialization earns its place when the factory can define the split, preserve the shared decisions, verify each contribution, and join the work without making a person reconstruct the whole story.

The same rule applies to human collaboration. A focused intervention is valuable when a real judgment call has appeared. The decision must then become durable state in the project and a constraint on the next run. If the meeting produces advice that the system cannot carry forward, the human remains a temporary memory device. That is coordination, not factory control.

Operational visibility is often sold as the control layer. It is not. Visibility tells you what happened. Control changes what can happen next. A spending anomaly that nobody can route, a failed task that can restart without a changed condition, and a review queue with no service boundary are facts on a screen. They do not govern the machine.

Make every important signal point toward an allowed response. A repeated failure can narrow the route, increase the proof required, change the worker, or stop the class of work. A reliable route can earn broader authority. A budget crossing can pause execution before the money is gone. An unresolved product decision can return the request to its owner instead of inviting the builder to guess.

Measure the finished route as well. Tasks completed, tokens spent, and pull requests opened are activity. The useful unit is an accepted change that survived release, including the failed attempts, review effort, recovery work, and human intervention it consumed. Otherwise the dashboard rewards the factory for moving inventory toward a bottleneck it created.

An agent is more than a prompt, but a long configuration page does not make it governed. Instructions describe the job. Permissions decide what the worker can actually touch. Tests decide which claims survive. Release controls decide what reaches customers. Those boundaries have to exist outside the agent's ability to reinterpret them.

That separation makes reusable skills useful instead of dangerous. A team should be able to share a proven workflow without silently sharing the creator's credentials, authority, or assumptions. Reuse the capability, then bind it to the new task's inputs, access limits, proof requirements, and owner. The skill travels. The permission does not hitch a ride.

Human approval needs the same precision. Discussing a release is not approving one. Giving feedback on a design is not accepting its production consequences. The factory should know which decision occurred, who had authority to make it, what evidence they saw, and what part of the route may now proceed. A generic approval button hides exactly the distinction governance is supposed to preserve.

Start with one recurring kind of change. Write down how intent becomes scope, how context is selected, what the worker may do, what proof is required, who owns the remaining judgment, how release happens, and how production evidence writes back. Then ask a platform to show that whole route with a real failure in the middle. The failure is important. Happy paths conceal the humans doing the repair.

You do not need a new application for every stage. Existing repositories, delivery pipelines, issue trackers, test systems, and observability tools may already carry much of the work. Replace them only when the replacement improves the route. A factory is not made more complete by moving every familiar function behind one fresh interface.

Our position is simple: the winning software factories will not be the ones with the richest agent theater. They will be the ones that connect intent, authority, execution, proof, release, and feedback tightly enough that repeatable work no longer depends on repeatable human coordination. People will still choose the destination and own the consequences. The machinery should carry everything between those judgments—and prove that it did.