Goal Engineering, or: Are We There Yet?
Three coding agents shipped /goal. Two of them disagree about what it’s for.
The vocabulary around agents has added a floor roughly every quarter. Prompt engineering, then context engineering, then harness engineering, then loop engineering, and now, since about June, goal engineering. It would be easy to file this under branding churn, another layer of nouns invented to sell the same thing.
Except that in the space of about eight weeks this spring, three different coding agents shipped a feature called /goal, and they shipped it to solve a problem none of the earlier layers touched. It isn’t getting the model to keep working. Models were always happy to keep working. It’s getting a credible answer to a much duller question: is this actually finished?
And the two major implementations, Claude Code’s and Codex’s, answer it in almost opposite ways.
Each layer of the stack answers a different question
Prompt engineering asks what you say in a single turn. Context engineering asks what the model can see when it reads that turn: the retrieved documents, the memory blocks, the project files. Harness and loop engineering move up a level, so that instead of you typing the next prompt, a system does. Loop engineering is the practice of building the thing that prompts your agent on a cadence, rather than prompting it by hand. Boris Cherny’s line, relayed in Greyling’s write-up, is that his job is to write loops, not individual prompts.
But a loop only answers what starts the next turn. It says nothing about what stops it. A loop with a time interval runs until you kill it. A loop with no termination logic burns tokens on a task it finished forty minutes ago, or abandons one it never finished at all.
Goal engineering is the layer that answers what ends this. You state a bounded objective with a verifiable done condition, the system keeps the objective alive across turns and compactions, and something checks the condition. That last clause is the whole argument. Greyling’s framing is that a goal needs four primitives: an objective, a verifier, external state, and a budget. His sharpest line is about the verifier. You need one that doesn’t let the implementer grade its own homework.
Hold onto that. It’s exactly where the two implementations diverge.
Claude Code takes the verdict away from the worker
Anthropic shipped /goal in Claude Code v2.1.139 in May. The mechanism, per the docs, is almost aggressively simple. /goal is a wrapper around a session-scoped, prompt-based Stop hook. You state a completion condition. Setting it immediately starts a turn with the condition as the directive. Then, every time Claude finishes a turn, the condition plus the conversation so far get handed to a small fast model, Haiku by default, which returns yes or no plus a short reason. A “no” sends Claude back to work with that reason as guidance. A “yes” clears the goal.
The design choice underneath is the interesting part. The model doing the work does not get to declare victory. A different model, with a different prompt and no stake in the outcome, reads the transcript and rules. VentureBeat, covering the launch, framed it as separating the agent that works from the one that decides it’s done. That framing is exactly right, and it describes a structural fix rather than a capability fix. Self-assessment doesn’t get better with a smarter model. It gets better with a second one.
What Claude Code gives up in exchange is durability. One goal per session. No pause and resume - you can clear a goal, but you can’t park it. Turn and time bounds live inside the condition as text (”or stop after 20 turns”), and the docs are candid that Claude reports progress against that clause and the evaluator judges it from the conversation. It’s a soft stop, not a mechanical one. A goal survives --resume, but the turn counter, timer, and token baseline all reset.
Codex makes the goal an object in the runtime
OpenAI took the other half of the problem. Codex’s /goal landed in the 0.128.0 release line at the start of May, behind a goals feature flag you enable with codex features enable goals. The CLI reference describes it as a persistent target attached to the active thread, with a real lifecycle: set, view, pause, resume, clear.
That lifecycle is the point. Someone who read the source noted an asymmetry that reads as deliberate. The model gets tools to start a goal and to mark it complete, but pause, resume, and budget transitions belong to the user and the runtime. The completion response carries a budget report: tokens used against tokens allotted, seconds spent. Goal state persists in the CLI’s own storage rather than living in the conversation, so it survives compaction and session resumption in a way a transcript-scoped condition does not.
But notice who signs off. In Codex, the model marks its own goal complete. There is no built-in second opinion. You can get one from /review, a subagent, CI, or an eval suite in the stop condition - you just have to wire it yourself. Codex separates control from the model and leaves judgment with it. Claude Code separates judgment and leaves control loose.
Grok Build, which shipped /goal on June 22, sits closer to the Codex end: a visible progress checklist, status, pause, resume, clear, and a panel that flips to Complete when the agent says so.
The evaluator can’t run anything, which changes what you’re actually writing
In the Claude Code implementation, the evaluator does not run commands or read files independently. It judges your condition against what Claude has already surfaced in the conversation. The judge is blind to everything except the transcript. Which means a condition like “the tests pass” is not a claim about your test suite. It’s a claim about whether the test output landed in the conversation where the evaluator could read it. If Claude fixes the code and never re-runs the suite, the condition fails on evidence, not on merit. If Claude runs the suite and reports a summary rather than the exit code, the evaluator is grading a summary.
So goal engineering, in practice, is less about writing objectives than about specifying evidence. You are designing what proof has to appear in the record. “All tests in test/auth pass” works because running tests produces transcript. “The production deployment succeeds” doesn’t, because nothing the agent can safely do will demonstrate it.
Codex has the mirror-image version of the same problem. Its budget report is precise about tokens and seconds and silent about correctness, because the entity reporting completion is the entity that did the work.
Correct and useless: what happens when the condition is the whole spec
The failure mode this creates is Goodhart’s law wearing a lanyard. Give an agent a verification-only condition - tests pass, build succeeds, no console errors - and you can get back something that clears every machine check and is visually embarrassing - a condition made only of machine checks selects for the cheapest artifact that passes them, which is rarely the artifact you wanted.
That’s the tax on mechanical verifiability. The conditions that evaluate cleanly are the ones that capture the least about whether the thing is good. Exit codes are honest and narrow. “The code is clean” is broad and unjudgeable. Most real work lives in between, and the goal will optimize hard for whichever half you wrote down.
What to do with this
If you’re picking up either tool this quarter, a few habits follow from the mechanics rather than from the marketing.
Write the check, not the wish. Every condition should name the command or artifact that proves it. npm test exits 0. git status is clean. The queue is empty. In Claude Code that’s literally what the evaluator reads, and in Codex it’s the only thing standing between you and a confident self-report.
Add the constraint clause. What must not change on the way there. Without it, deleting the failing test is a valid path to green.
Bound the run, and know how soft the bound is. In Claude Code, “or stop after 20 turns” is a sentence the evaluator interprets, not a counter that trips. In Codex, budgets are tracked by the runtime. Plan your blast radius accordingly.
If you’re on Codex, build the verifier yourself. A reviewer subagent, a CI gate, an eval in the stop condition - anything that isn’t the implementer. This is the one gap the tool leaves open by design, and Greyling’s four-primitive checklist is a reasonable place to start.
Keep external state for anything that spans sessions. A GOAL.md in the repo holding the objective, the definition of done, the guardrails, and a running log costs you nothing and survives compaction, session resets, and the turn counter zeroing out on resume.
And use goals for the right shape of work. A goal finishes a bounded thing with a knowable end state: a migration, a spec implementation, a backlog burndown. A loop discovers recurring work on a cadence. If you don’t yet know what done looks like, you want plan mode, not a goal.
Last: read the diff. A goal that clears is a claim that a condition held, nothing more. The migration shipped. That doesn’t mean you understand how it works, and comprehension debt compounds faster when the agent is good.
The honest caveat is that this is all extremely young. Claude Code’s /goal is roughly three months old, Codex’s is still flag-gated, and the same idea is propagating up the stack. Anthropic’s Managed Agents added rubric-based outcome grading at the API level in May. The specific commands in this piece will be stale by autumn.
What seems more durable is the shape of the disagreement. Persistence and adjudication are separable problems, both implementations solved one and punted the other, and the gap between looks done and is done is where the remaining engineering lives. Whichever tool you’re in, the useful question to keep asking is the same: who signs off, and what did they actually get to look at?