A Task Without A Check Command Is Not Automated

In an eight-stage automated production line, the final stage is the requirement of a verification command for each task to enter the pipeline. This rule prevents plausibility from being mistaken for completion. An agent can produce work for almost any instruction, but without verification, it's impossible to distinguish between finished and abandoned tasks.

A verification command can be as simple as a test suite, a build that must compile, or a count that must match a known figure. It must be mechanical and capable of failure.

Tasks that cannot be checked mechanically require human judgement, such as tone, design direction, or client acceptance. These do not enter the pipeline, as they are the responsibility of a person. However, engines are not interchangeable. In our setup, one engine cannot run verification commands in its sandbox, causing tasks with gates attached to silently fall back and consume a turn without doing any useful work.

Another engine cannot read from disk, preventing it from seeing existing code and leading to confident rewrites of unseen modifications.

The pipeline excels at tasks with a clear definition of done, but it struggles with determining what is worth doing, especially when the definition of done is not mechanical. This is the boundary of agentic setups today, not the model's reasoning or tool access, which are now routine. The problem lies in how much of your work can be stated as a condition that a machine can check. In our case, most of the production work is within this boundary, while almost none of the direction is.