/goal is not a bigger prompt — it's a finish-line contract. You state the durable outcome, the evidence that proves it, the boundaries it must respect, and the conditions to stop. The agent then loops on its own: work → check evidence against the finish line → decide continue, complete, or stop-because-blocked. It fits work with a fixed target but an uncertain path (audits, migrations, bug hunts, research, vendor scorecards), and it explicitly does not fit small tasks or tasks whose success can't be made inspectable. For Dab → Claude Code, the actionable rule is: for any substantial multi-step delegation, define the outcome, verification surface, and stop conditions before handing it off — don't sit there pushing "keep going."
Notice Board Explainer · The AI Daily Brief (NLW)
How to Use /goal to Do More With AI
A 22-minute AI Daily Brief episode on /goal — the new agent primitive that shipped in OpenAI Codex and was then adopted, name and all, by Claude Code. The core shift: stop telling the agent what to do and start telling it what you want to be true when it's done, then let it loop, self-check, and stop on its own. This explainer is the full episode synthesized into a durable reference for how Dab should shape work for Claude Code.
Why this is having a moment
/goal shipped first in OpenAI Codex (early May). Within weeks Claude Code shipped the same feature and — smartly — also called it /goal rather than fighting over the name, because it had already become a shared primitive.
The episode frames it as the top of an autonomy ladder Swix described: skill → plan → goal. It's the productized version of hand-rolled loops people already loved — the "Ralph Wiggum loop," Karpathy's auto-research loop. As Nicolas Bustamante put it: in 2024 you wrote your own while loop, in 2025 you wrote prompt files and hooks, in 2026 the loop becomes a product primitive.
"LLMs are exceptionally good at looping until they meet specific goals. Don't tell it what to do, give it success criteria and watch it go." — Andrej Karpathy
Prompt vs. goal — a different kind of thing
The episode is emphatic: a goal is not a larger prompt, it's a fundamentally different object. Codex itself described a goal as a finish-line contract: what should be true, how success is checked, and what must stay intact along the way.
- Prompt loop: you ask for a result → the model does the immediate work → it reports back → it waits for your feedback → repeat. The turn-based paradigm.
- Goal loop: the agent (1) works toward the durable objective, (2) checks current evidence against the finish line, and (3) decides for itself whether to continue, declare complete, or stop because it's genuinely blocked.
Pavel Hurin's one-liner: "You state the outcome, the model loops, self-evaluates, and stops when it's done." The skill that wins, he added, is engineering the intent — the why, the strategic context, and how success is measured.
The /goal loop
Goal exists because much real work is sequential in a way where you can't know the next step until the last step taught you something. Without it, you sit there after every intermediate step saying "keep going, now check this, now rerun that." Goal pushes that button for you.
WorkMake bounded progress toward the durable objective.
→
Check evidenceCompare current state against the finish-line definition.
→
DecideContinue · Complete · or Stop — no defensible path remains.
Under the hood (Bustamante's description): an initializer agent turns fuzzy intent into a durable workspace + plan.md, worker agents make bounded progress against it, and a judge agent decides whether the stated completion condition is actually met — or keeps it running.
1 · Durable objective
The target must stay true across every turn. It does not drift or get redefined mid-run. If the goalpost itself moves as work proceeds, it's not a goal.
2 · Uncertain path
The agent may need to inspect, compare, rerun, revise, or investigate before it knows the next best move. If the path is obvious and fixed, you don't need the loop — a prompt is enough.
3 · Evidence finish line
Completion can't depend on vibes. It must rest on tests, sources, artifacts, citations, logs — proof the AI can inspect and self-judge against. No inspectable proof, no good goal.
The six things a strong goal defines
Per OpenAI's tip document (as summarized in the episode), the strongest goals spell out all six. Dab should treat this as the checklist before any substantial handoff.
① Outcome
What should be true when the work is done — the concrete end state, not the activity.
② Verification surface
How success is checked: the tests, citations, matrices, logs, rubrics, or artifacts that decide completion.
③ Constraints
Which files, tools, or data may be used — and the standards the work must hold to.
④ Boundaries
What must stay intact / off-limits. The non-goals and the things not to touch.
⑤ Iteration policy
How it should loop — when to revisit, retry, revise, or escalate borderline cases instead of barreling ahead.
⑥ Block / stop condition
When to stop and say no defensible path remains — rather than spinning or fabricating progress.
Goal stays user-controlled, not fire-and-forget. Lifecycle authority stays with you: goal pause, goal resume, goal clear. If the path looks wrong or the success rubric needs to change, you intervene without throwing away the work done so far.
Goldilocks scope
Early experiments point to a sweet spot between two failure modes:
- Too narrow — "fix this one line." Even if that is what you want changed, it denies the agent room to discover the real issue, which may sit in a dependency or upstream.
- Too broad — "improve the whole system." Now there's no concrete evidence surface, so the agent can't tell whether it actually succeeded.
- Just right — bounded enough to define clear finish-line evidence, open enough to let the path be discovered.
The same logic applies to the output artifact. "Write docs for this feature" is a weak target. Stronger:
"Produce a docs page that explains the lifecycle command surface in two examples. Verify that the page builds locally, and all referenced commands match current CLI behavior."
A defined artifact is the evidence surface.
Where the success rubric comes from
The tell for a good non-coding goal: the output isn't just an answer, it's an audit — a ledger of what was checked, what was supported, what was contradicted, what was weak, and what remains unknown.
Two sources of "success":
- External rubric — published criteria, official docs, a third-party dataset, existing logs/transcripts, RFP questions.
- User-supplied rubric — you articulate the criteria so the AI can test against them. Hiring criteria, vendor scorecards, editorial standards, lead-qual rules, investment-diligence priorities.
NLW's bet: the user-supplied-rubric case will be the most common pattern in knowledge work. Working backwards — if a task implicitly carries a rubric, it's worth checking whether it fits /goal.
Knowledge-work candidates the episode flags
Goals aren't just for code. Ten areas NLW calls out as good places to experiment — the common thread is messy inputs → structured, auditable output:
Worked examples from the episode
Each one earns the goal shape by turning a research question into an audit with an inspectable finish line. Expand to see the goal phrasing NLW used.
Claim audit — the clearest fit
"Audit this memo claim by claim. Verify each claim against the provided sources and reputable external sources, with a table labeling each claim as supported, contradicted, partially supported, or unverified — with citations and uncertainty notes."
It works because every conclusion traces back to evidence. The output is an audit trail, not an opinion. Sample shape of the deliverable:
| Claim | Verdict | Evidence |
|---|---|---|
| "Market grew 40% YoY" | Supported | Filing p.12; analyst report |
| "We are the category leader" | Partially supported | True by revenue, not by units — see note |
| "Competitor X is exiting" | Unverified | No public source found |
Market landscape — not just "a research question"
"Create a market landscape for X market, verified by cited company pages, filings, analyst reports, pricing pages, and product docs — with a comparison table, confidence levels, and gaps where evidence was unavailable."
What lifts it out of general research and into a goal is the move to audit-as-process: the artifact is a comparison table showing what's verified, what's inferred, and where the evidence runs out.
Literature review — live with the conflict, don't flatten it
"Provide an evidence-backed literature review on X topic. Build a source matrix covering methods, sample sizes, findings, limitations, and conflicts. End with confirmed themes, disputed findings, and open questions."
A goal-shaped review highlights conflicting evidence and disagreement rather than smoothing it over. It works wherever evidence can be inventoried and presented in complete form.
Vendor / application review — prompt vs. goal, side by side
Prompt is enough when inputs are small and the read is one-pass:
"Review these five applications against this rubric. Cite evidence and suggest interview questions."
Goal takes the same task and makes it the architecture for an entire process: extract evidence → apply the rubric → check consistency → revisit borderline cases → flag missing info → produce a continuously updated document as more entries come in. This is the user-supplied-rubric pattern — the vendor scorecard mirrors what you care about, not an external standard.
Reusable goal template — Dab → Claude Code
The six-part checklist, the Goldilocks scope, and the audit-output idea collapsed into a block Dab can fill in before any substantial handoff.
Goal: Produce [artifact] so Ananth can decide [decision].
The artifact is done when [inspectable finish-line state] is true.
Verification surface (how "done" is judged):
- [tests / citations / comparison matrix / build passes / rubric scores]
- Every major claim traces to an attached source or evidence link.
Constraints:
- May read: [paths / sources / items].
- May write only: [exact output path(s)].
- Standards: [tone, schema, style, accuracy bar].
Boundaries (must stay intact):
- Do not edit [protected files — e.g. brain.json, render.py, index.html, inbox.md].
- Non-goals: [what is explicitly out of scope].
Iteration policy:
- Loop: gather evidence -> draft -> self-check against the finish line -> revise.
- Revisit borderline / low-confidence items before finishing.
Stop condition:
- Stop and report if no defensible path remains, a protected boundary blocks
the outcome, or required evidence cannot be found.
Return:
- Files written (paths + one-line summary each).
- 5-bullet executive summary.
- Verification evidence (commands run + observed output).
- Open questions, gaps, and risks.
When not to use /goal
The episode is explicit that maybe the majority of tasks are still better served by the ordinary turn-based pattern. Skip /goal when:
- The outcome is small — a one-line fix, a quick lookup, a single-pass summary. The loop is pure ceremony.
- Success can't be made clean or definable — if you can't name inspectable evidence, the judge agent has nothing to judge against.
- You want to stay in the loop — taste calls, exploratory thinking, or anything where your steering each turn is the point. Jason Liu's "codex maxing" tips (steering, voice, side-panel inspection) matter precisely because you often don't want to be as disconnected as goal allows.
Think of it as a spectrum of interaction autonomy — goal is the far end, not the default for everything.
Application to Mission Control
This maps almost directly onto how Dab already delegates to Claude Code. The pattern cuts token waste and follow-up thrash by turning "please explore this" into a bounded work order.
- Capture: raw WhatsApp links stay as triage items until a useful artifact is worth building.
- Scope: hand Claude Code one exact page or change with a named output path — not a vague repo-wide edit. (This very explainer was produced under a goal-shaped brief: one target file, protected files listed, sanity check required.)
- Verification: Dab independently runs render / tests / browser checks before committing.
- Handoff: the Notice Board card links to the artifact; Ananth sees only the decision surface.
Fit score for Ananth / Dab
Immediate workflow value
Reusable across domains
Conceptual novelty
Risk of over-systemizing
High value, low novelty — Dab already works this way intuitively; the episode gives it a vocabulary and a six-part checklist. The main risk is turning every small capture into a ceremony. Reserve the full goal block for work that needs autonomy over more than one step.
Experiments worth running
- Goal-ify Link Triage: convert the autonomous Link Triage brief into a standard goal block and compare artifact quality across 5 links.
- Vendor review goal: score two OSS task/project substrates for Mission Control against a Dab-supplied rubric (the user-supplied-rubric pattern).
- Claim audit goal: point it at a memo or product page and demand the supported / contradicted / unverified ledger.
- Repo audit goal: "security + deployability + UX risk" on one repo, with exact output sections and verification commands.
Decision
Read/listen if you want the framing; the operational takeaway is already actionable. For substantial agent work, Dab should define the finish line, verification surface, constraints/boundaries, iteration policy, and stop condition before handing work to Claude Code — and skip the whole apparatus for small or taste-driven tasks. The six-part checklist and the template above are the durable artifacts to keep.
Source
- The AI Daily Brief — "How to Use /Goal to Do More With AI" (NLW, ~22 min).
- Synthesized from the full episode transcript. Built on OpenAI's "How to Use Goal" guide and Jason Liu's "Codex Maxing" interaction patterns, as discussed in the episode.
- Quotes attributed in-episode to Thibault, Pavel Hurin, Andrej Karpathy, Nicolas Bustamante, and Sean "Swix" Wang.