A Factory Needs a Goal Loop

Give an agent a clean backlog and it can work through tasks with impressive speed. It can open a change, answer review, update the ticket, and move to the next item. That is useful automation. It is not yet a software factory, because the queue can be perfectly maintained while the project quietly stops solving the problem that created it.

The missing piece is a loop around the work. The factory needs to know the goal, how that goal will be measured, what the evidence says now, and which task should exist next. Without that outer loop, people still carry the most important state in their heads. They decide whether the plan is stale, notice the missing work, and remember to check whether the release helped. The agents are busy, but the operation still depends on human memory.

A real factory does more than execute the list. It inspects the system that produced the list. If the goal is vague, it stops and sharpens it. If measurement is missing, it creates the path to evidence. If the evidence changes, it changes the work. That is the difference between automating tickets and operating toward an outcome.

Broad goals are not a problem for agents because they are written in plain English. They are a problem when the factory cannot test whether its actions are helping. “Improve adoption” cannot steer a loop by itself. The system needs an explicit definition of the behavior that should change, a way to observe that behavior, and boundaries around the actions it may take in response.

That turns the goal into an interface. On one side sits human judgment: what matters, which tradeoffs are acceptable, and when the destination should change. On the other side sits the machinery: current evidence, project state, available work, and the next safe action. The interface lets people own the decision without manually carrying every step between decision and result.

This is where many agent programs stall. They add a stronger model or a better coding tool, but leave the destination trapped in a planning document and the evidence trapped in a dashboard. A person remains the integration layer. The factory only becomes autonomous when it can connect those systems under a contract that says what to read, what to update, and when to ask for judgment.

A project cannot run autonomously while one person is quietly holding the real map. If the written plan is stale, priorities live in a meeting, or the reason behind a task exists only in memory, an agent can execute the visible record and still be wrong. The problem is not that the agent lacks intuition. The operating state was never made available to the operation.

The fix is not to paste more conversation into a prompt. Put the goal, decisions, work state, and evidence in durable systems with clear owners and write paths. The factory should be able to tell when the project description has gone stale. It should update task state as reality changes. It should add newly discovered work without pretending that every discovery deserves automatic approval.

This discipline is uncomfortable because it reveals how much coordination depends on somebody remembering what everyone else forgot to record. That hidden work feels efficient right up until the person is unavailable or the number of parallel projects grows. Then it becomes the ceiling. A factory forces the state out of private memory because machinery cannot reliably operate on context it cannot inspect.

Most delivery systems treat release as the finish line. The change merged, the deployment completed, and the ticket closed. But the goal was rarely to deploy code. The goal was to change something in the real system: reduce failure, remove friction, increase use, or make an operation cheaper. None of those outcomes is proven by a successful release.

A goal loop returns after production has had time to answer. It checks the evidence on a cadence that fits the decision, looks for movement or regression, and creates work when the result demands it. That post-release pass matters because a feature can work exactly as specified and still fail to produce the intended outcome. It can also succeed, attract more use, and expose the next constraint.

This is where agents have an advantage over human coordination. People forget to reopen finished projects because a new fire takes their attention. A scheduled loop does not need to remember. It needs permission to observe, a rule for what counts as a meaningful change, and a route for the next action. The factory can keep watching without turning every signal into an emergency.

Our position is simple: more agents will magnify whatever operating system you already have. If goals are vague, state is fragmented, and nobody returns after release, the factory will produce more motion around the same blind spots. Faster task completion does not rescue a system that cannot tell whether the tasks still matter.

Start with one outcome. Make its definition explicit. Connect it to evidence the factory can inspect. Give the work one durable home. Define which updates are routine, which actions need approval, and which conditions mean stop. Then run the loop often enough to discover where a person is still acting as invisible glue.

The valuable result is not an agent that never asks a question. It is a system that knows which questions belong to people and keeps everything else moving. The goal chooses the direction. Evidence corrects the route. Durable state lets another worker continue. The loop turns all three into an operation that can run after the excitement of the first release is gone.