The most common failure I see in AI assisted development has nothing to do with the model. The model is fine. The failure is that nobody ever converted the request into a goal precise enough that success could be judged. “Build the invoicing module” is not a goal. It is a wish. An agent handed a wish will produce something that looks like an invoicing module, and it will be wrong in ways nobody can even argue about, because nobody wrote down what right meant.
I call the fix goal engineering. It happens before any code, and it produces four things in writing: success criteria, invariants, unknowns, and a priority order.
Success criteria you can check from the outside
A success criterion is a numbered condition that must be true when the work is done, and each one must be checkable by a command, a test, or a direct observation of runtime behavior. The discipline is in that last clause. “Invoicing works correctly” is rejected. It is not checkable. “Running the invoice generation job for a tenant with 5,000 open orders produces one invoice per order, totals match the sum of line items to the cent, and the integration test invoices.precise-totals.test.ts passes” is a criterion. Anyone, human or agent, can run the check and get a yes or a no.
When I am building Agaro ERP features, I force every criterion through the same question: what command proves it? If there is no command, the criterion gets rewritten or split until there is one. A criterion that can only be judged by a feeling is a criterion that will be quietly dropped in week three.
The count matters too. I keep criteria in the single digits per goal. If I cannot state what done means in fewer than ten checks, I do not understand the task yet, and the right move is to go learn more, not to start building.
Invariants: what must stay true
Success criteria describe the delta. Invariants describe what must not change while the delta happens. Existing passing tests, public API contracts, database integrity rules, performance characteristics that matter. These are the things that are true today and must still be true tomorrow.
Invariants are where autonomy goes wrong most often, and it goes wrong in a specific direction: an agent optimizing for its criteria will happily break an invariant to get there, because nothing in its instructions said the invariant was load bearing. I have watched an agent meet a deadline criterion by deleting a failing test. Criterion met. System damaged. The invariant list is the counterweight. Breaking an invariant to satisfy a criterion is a failure, not a tradeoff, and the spec has to say so explicitly or the agent will not know.
Unknowns, and the investigation that resolves each one
Every goal has things I do not know that affect the approach. The discipline is to name each unknown and name the investigation that resolves it: the file to read, the command to run, the log to inspect. “I don’t know how the tenant guard is enforced” is a real unknown, and reading the middleware is the real investigation.
What this buys is the elimination of carried assumptions. An assumption that survives into implementation is a defect scheduled for later. Most of what looks like an agent going off the rails is actually an agent executing faithfully against an assumption someone handed it. Resolve the unknown first, or, if it cannot be resolved by investigation and the decision underneath it is a business decision rather than a technical one, that is the one moment to stop and ask a human. Escalation is a feature of the process, not an embarrassment.
Priority order
Constraints outrank the primary goal. The primary goal outranks improvements. Writing that down sounds trivial until the first time an agent has to choose between hitting a criterion and preserving an invariant, and discovers there is no rule telling it which wins. Without an explicit order, the agent improvises one, and its improvisation will not match yours.
Why this is the foundation of autonomy
Goal engineering is what makes autonomy earned rather than granted. An agent operating against vague goals must be supervised at every step, because there is no way to tell progress from drift. An agent operating against checked criteria, explicit invariants, and resolved unknowns can run for long stretches, because verification is built into the goal itself.
Everything I do at a higher level of autonomy, the loop graphs, the spec driven execution, the self verification, sits on top of this. If someone else cannot read my criteria and independently judge whether the work succeeded, the goal is not done being engineered, and the agent should not have been started.