Goal Engineering
Run longer tasks until verifiably done
What I love is the fact that vocabulary keeps moving and expanding…first it was Context Engineering, then Harness Engineering, then Loop Engineering, the discipline of designing systems that prompt your agents on a cadence instead of you doing it turn by turn.
Now xAI has shipped /goal in Grok Build, and we have a name for the layer above the harness: Goal Engineering. I guess Goal Engineering is important for long running tasks.
/goal is built for multi-turn, autonomous work that would otherwise need repeated prompt-verify-prompt cycles, which xAI markets as long-running execution.
But that does not mean every goal must be a marathon of course; it means the objective is bounded…you should know what “done” looks like.
So the objective is persistent across turns, compaction, pause/resume and verification via the GOAL.md file (more about this later in the blog).
I would say this functionality is not for open-ended or recurring work (that is /loop territory), and mega-goals without verifiable done conditions can burn budget endlessly, which is why goal engineering recommends scoping.
I get the sense that agent work fails in the gap between looks done and actually done, so it seems like Goals exist to close that gap.
What /goal actually does
On 22 June 2026, xAI introduced goals as a first-class mode in Grok Build, the terminal-based coding agent CLI.
The old workflow…write prompt, read output, write next prompt… still works.
But for bounded implementation work, you can now hand off the entire objective in one line:
/goal Migrate the auth module to the new API
Grok plans an approach, breaks the work into a visible checklist, fans out subagents where needed, and keeps executing across turns until the task is completed and verified.
Review code. Run tests. Inspect pages. Fix what breaks. Repeat.
You can steer without micromanaging:
/goal status # live progress panel
/goal pause # stop work, keep the objective
/goal resume # pick back up
/goal clear # drop the goal entirelyWhen the goal finishes, the panel flips to Complete with every checklist item checked.
The API surface
Under the hood, goal mode is not just a longer prompt but rather it is a lifecycle with explicit telemetry.
The update_goal tool is the quiet workhorse.
The agent calls it at meaningful milestones instead of flooding the chat:
{ “message”: “Migrated token refresh; 12/18 auth tests passing” }
Completion is explicit and should be earned:
{ “completed”: true, “message”: “All auth tests pass; legacy imports removed” }
When genuinely stuck after repeated failed attempts, the agent can pause with a blocker:
{ “blocked_reason”: “OAuth sandbox credentials expired; need human to rotate secrets” }
/goal appears when the goal feature is enabled and update_goal is in the session toolset. Humans check /goal status; the agent logs via update_goal . It’s a clean separation.
The four primitives
I have been building the canonical reference for this at github.com/cobusgreyling/goal-engineering with patterns, skills, audit tooling and the operating playbook for Grok Build’s goal mode.
I believe every reliable goal run needs four primitives:
Objective
One bounded sentence plus a verifiable done condition.
Not “make auth better.” Something like: migrate to lib/auth/v2; done when all tests/auth/ pass, zero legacy/auth imports remain, and GOAL.md checklist is complete.
Verifier
The agent that wrote the code is a poor judge of its own work.
This is structural, not a model limitation. Use tests, a goal-verifier skill, a reviewer sub-agent, or CI.
State
GOAL.md is the external memory file for goal mode.
Grok’s context can compact or reset between turns; GOAL.md lives in the repo and does not.
It holds the objective, the definition of “done,” guardrails, and a running log so work survives across sessions.
/goal persists an objective across turns, but the chat context does not. Without external state:
• Progress gets lost after compaction
• The agent may re-scope or declare victory early
• You cannot audit what was tried or why it stalled
Budget
Goals can run many turns.
Document turn caps, token guidance in goal-budget.md, deny lists for high-risk paths, and kill switches (/goal pause).
Unbounded autonomy is exciting in research. In production, it is a liability.
Goal vs Loop
I wrote about loops extensively in Loop Engineering. Goals and loops are complementary, not interchangeable.
Production setups often combine both: a daily loop triages CI failures and writes priorities to STATE.md; when it surfaces a fixable item, you hand off to /goal for run-until-done execution. Loops discover work. Goals finish it.
Decision tree:
Do you know what “done” looks like?
├─ No -> Plan mode or exploratory session first
└─ Yes -> Is the work recurring on a schedule?
├─ Yes -> Loop
└─ No -> GoalWhere this sits in the stack
I think of agentic engineering as layers, each answering a different question:
/goal is Grok Build’s native expression of the goal layer. The repo is the go-to reference when you teach, blog, or ship goal-driven workflows — link it, fork the patterns, run the audit on your own codebase.
The realities nobody should skip
Goals are powerful. They are also early.
“Done” is a claim until verified. The verifier helps. It does not replace you reading what landed in the repo.
Token costs multiply. A goal that spawns implementer + verifier subagents across dozens of turns will burn through a plan faster than a single chat session. Budget deliberately.
Comprehension debt grows faster with good goals. The agent shipped the migration. That does not mean you understand how it works. Build goals like someone who intends to stay the engineer.
Lastly
Boris Cherny at Anthropic says his job is to write loops, not individual prompts.
Peter Steinberger says you should design loops that prompt your agents.
xAI’s /goal pushes the same direction from the Grok side… hand off bounded objectives, let the agent run until verifiably done, steer with pause/resume/status instead of micromanaging every turn.
That is goal engineering.
Not a bigger prompt, a system with persistence, telemetry, explicit lifecycle and a verifier that does not let the implementer grade its own homework.
If you are experimenting with /goal in Grok Build, start with the audit, scaffold a pattern and ship one small objective before you trust it with a module migration.
Chief Evangelist @ Kore.ai | I’m passionate about exploring the intersection of AI and language. From Language Models, AI Agents to Agentic Applications, Development Frameworks & Data-Centric Productivity Tools, I share insights and ideas on how these technologies are shaping the future.
COBUS GREYLING - At the intersection of AI & Language
Cobus Greyling is an AI Evangelist & thought leader dedicated to exploring the intersection of artificial intelligence…www.cobusgreyling.com
GitHub - cobusgreyling/goal-engineering: The canonical reference for Grok Build CLI /goal …
The canonical reference for Grok Build CLI /goal - run-until-done objectives, patterns, verifier skills, and goal-audit…github.com
The Evolving Vocabulary of AI
We’re converging on a shared vocabulary and most of it is new…cobusgreyling.medium.com
Haha, vocabulary is moving for sure but the concepts stay intact. Get things done in safe and reliable way