You hand an AI agent a task, watch it work for thirty turns, and end up with something that is close. Close, but not it. The flow works but ignores the edge case you cared about. The migration ran but quietly dropped the records that didn't fit the mold. You got most of what you asked for, which is the problem, because you didn't ask for the thing you wanted. You asked for the steps you assumed would get there.
That gap — between what you asked for and what you meant — is where most AI work goes sideways. A new command in two of the major coding tools is built to close it. It is called /goal, and using it well takes a kind of upfront thinking most of us have been able to dodge until now.
What /goal does
OpenAI's Codex shipped /goal first, behind a config flag you switch on once. Claude Code added a near-identical version within a couple of weeks. The mechanics are nearly the same in both.
Normally these tools work one turn at a time. You prompt, the agent responds, you read it, you prompt again. You are the steering wheel. /goal changes the shape of the session. You describe a finish line, an end state you can check, and the agent runs on its own, looping through plan, act, test, and review for as many turns as it takes to get there. You can step away. It keeps going.
A separate model does the checking. After each turn, it reads what happened and answers one question: has the finish line been reached? If not, it says why, and that reason becomes the next instruction. In Claude Code the checker is Haiku by default, running on its own budget. A model that didn't write the code decides whether the code is done, so the agent never grades its own paper.
Codex gives you a small set of controls around the same idea. You start a goal, ask it for status, pause it, resume it, or clear it, which lets you look in on a long run without breaking the agent's train of thought. The shape is the same in both tools: a verifiable target, an autonomous loop, and an independent judge of when to stop.
The work moves to the front
Turn-by-turn prompting spreads your thinking across the whole session. You don't have to know exactly what you want at the start, because you correct course every few minutes. Vague is survivable when you are in the loop.
/goal takes the loop away. Whatever you define at the start is what runs for the next hour. A vague goal sprints confidently in the wrong direction until it hits the turn limit, with nobody there to catch it. The quality of everything that happens after you walk away is set by how well you defined "done" before you left.
This is harder than prompting. The difficulty is the feature. Most of the frustration with AI tools comes from handing them a fuzzy target and being surprised by a fuzzy result. /goal pushes the fuzziness out into the open, at the start, where you can still do something about it.
What a good goal looks like
OpenAI's own guidance breaks a strong goal into a handful of parts. In plain language: the outcome you want, the evidence that proves you got it, the things that must not break along the way, and the condition that tells the agent to stop and ask for help instead of grinding.
Take Not Really Wines — our fictional demo winery, which we run as a working showcase of the kind of systems we set up for real clients (notreallywines.vercel.app). Say Priya, who runs their subscription program, needs to move two years of wine-club member records out of a tangle of spreadsheets and into a new database.
The weak goal is the one most people would type: "Clean up the member data and move it into the new system." It names an outcome and nothing else. No definition of clean. No proof of done. No guardrail against losing rows. The agent will do something, declare victory, and you will spend the next afternoon discovering what it decided "clean" meant.
The strong goal names the finish line and how to check it: "Migrate every wine-club member record into the new schema. Done means every row validates against the schema, the member count in the new system matches the source count exactly, and the test suite passes with the output shown. Don't touch the billing records. If any row can't be mapped, stop and list it instead of guessing."
Same task. One version can run unattended. The other can't, and the difference lives entirely in what you decided before you hit enter.
The trap: the checker only reads the conversation
The checker works in a way that trips people up the first time. It doesn't run your tests. It doesn't open your files. It reads the transcript of the conversation and nothing else. It can only judge what the agent said out loud.
So a goal that ends with "until the tests pass" isn't enough on its own. The agent can write the words "tests pass," and the checker, reading only the transcript, has no way to know better. You have to force the evidence into the conversation: run the suite and show the output, print the before-and-after row counts, paste the failing case. If the proof isn't in the transcript, it doesn't count. Write your finish line so that meeting it requires showing the work, not claiming it.
Use AI to sharpen the rubric, but you own it
None of this means you have to write the perfect goal alone on a blank screen. The same models are good at finding the holes in your own definition of done. Before you commit a goal, hand it to the model and ask it to break it: what's ambiguous here, where you could satisfy this goal while still doing something I'd hate, what guardrail is missing. It will find gaps you didn't see.
Run Priya's migration goal past the model before you commit it, and it will ask the questions you would want asked: what happens to a member whose email is missing, does "matches the source count" still hold for the members who cancelled last month, which record wins when the two systems disagree on a renewal date. Those are the holes that turn into an afternoon of cleanup if nobody catches them up front.
What the model can't do is decide what you want. It will optimize whatever finish line you give it, including one you put in the wrong place. Tell it the member count just needs to be "about right," and it will deliver about right. The judgment about what "done" means for your business stays with you. The model sharpens the rubric. You own it.
When it earns its keep, and when it doesn't
/goal isn't for everything. It earns its keep on work that runs long, has a clear finish, and can prove itself: data migrations, large refactors, a build-and-deploy loop that keeps failing, getting a prototype to match a reference. Each of those has a "done" you can point at.
It is the wrong tool when the answer is a single response, when the task is genuinely exploratory, or when you can't yet say what finished looks like. If you can't write the finish line, that isn't a failure of the tool. It is a signal that you don't yet know what you want, and that is worth learning before you spend an hour and a budget finding out the expensive way.
What it can cost you
Walking away from a running agent carries an obvious risk: it keeps running. /goal does not ship with an automatic spending cap. A loose goal with no stopping condition can loop for hours, and people have reported burning money — a couple hundred dollars in a single overnight run — on a goal that never resolved.
The fix takes one line, and you should treat it as mandatory. Put a hard limit in every goal: stop after forty turns, or stop after ninety minutes, whichever comes first. Watch the first few runs before you trust it overnight. Run it in daylight on a task you understand before you hand it something big and go to bed. The autonomy is the value and the risk in the same package, and a turn cap is the cheapest insurance you will buy.
The skill that's left
/goal looks like one more productivity feature. What it asks of you is harder than that. As these tools get better at the doing, the scarce skill becomes knowing exactly what you want, precisely enough to write it down and check it.
That skill has a plain business name. It is the difference between a project that lands and one that comes back "almost right" for the third time. Wineries bringing AI in already feel this. The teams that get value aren't the ones with the fanciest prompts. They are the ones who can say, clearly, what a good outcome looks like and how they would know they got it.
/goal just makes that requirement literal. You write the finish line. The machine runs to it. If the line sits in the right place, you get back what you wanted, which, after enough rounds of "almost," is the whole game.
If you want help working out what "done" should look like for the AI work at your winery, that is the kind of problem we work on at NunnCurtis Labs.