The /goal primitive is a durable-objective pattern for AI agents. Instead of asking for one response, you define what done means. The agent keeps working across turns until a verifiable condition is met, the goal is paused or cleared, the work is blocked, or the run hits a budget limit.
That sentence is the SEO answer, but it is also the practical point. Codex, Claude Code, and Hermes are converging on the same shape of work: clear objective, continuation across turns, a separate evaluator or judge, and a stopping condition the system can inspect.
This is bigger than one tool shipping a useful slash command. It is a sign that long-running AI agents are settling on a common interface. Codex can build. Claude Code can review. Hermes can orchestrate. The interesting part is that all three can now be driven by a similar goal contract.
What the /goal primitive is
A normal prompt asks for the next answer. A /goal asks an agent to keep moving toward a durable objective.
The difference is subtle until you run real work through it. With a normal prompt, the human becomes the continuation engine. You read the answer, decide what is missing, and say "continue", "fix that", or "now run the tests". With /goal, the continuation rule is part of the session itself.
Optimized for one response. The human decides after each turn whether the work should continue.
Optimized for long-running agent work. The agent keeps working until a stated condition is satisfied or control stops it.
A strong /goal prompt is not "make this better". It is closer to:
/goal Build the app described in SPEC.md.
Done means tests pass, build passes, README is accurate,
and git status only shows relevant project files.Notice the shape: source of truth, finish line, verification, and file hygiene. That is why the phrase AI agent goal primitive is useful. It describes the contract around the agent, not only the text you type.
How Codex, Claude Code, and Hermes implement it
The implementations are not identical. The pattern is.
| Tool | What the official docs say | Best fit |
|---|---|---|
Codex /goal |
OpenAI describes it as a durable objective for long-running work with a verifiable stopping condition. | Code migrations, refactors, prototypes, experiments, eval-driven prompt work. |
Claude Code /goal |
Anthropic describes it as a completion condition that Claude keeps working toward across turns, checked by a small fast model. | Review, spec compliance, issue queues, large code cleanup, acceptance criteria. |
| Hermes Persistent Goals | Hermes gives the agent a standing objective, checks it with a lightweight judge after each turn, and supports pause, resume, clear, budgets, and persistence. | Orchestration, tool routing, messaging gateways, subagents, Kanban-style multi-step work. |
Codex frames /goal around long-running coding work. Its docs recommend one objective, one stopping condition, source files to inspect, commands or artifacts that prove progress, and status checks while the run continues.
Claude Code now has its own official goal documentation. It requires Claude Code v2.1.139 or later. The condition is session-scoped, a small fast model evaluates whether the condition holds after each turn, and the goal clears when the condition is met.
Hermes calls the feature Persistent Goals. Hermes adds the orchestration context: CLI and gateway support, status/pause/resume/clear controls, a default continuation turn budget, goal state persistence, and a judge model that checks the latest agent response against the standing goal.
That is the convergence: three separate systems are describing the same operating contract for long-running AI agents.
Builder, reviewer, orchestrator
The cleanest mental model I have seen came from a Reddit post in r/ClaudeCode. I would not treat a Reddit post as documentation, but the framing is useful: Codex as builder, Claude Code as reviewer, Hermes as orchestrator.
That maps well to how I would design a real agent workflow.
- Codex builds: give it a spec, repo, constraints, and verification commands.
- Claude Code reviews: point it at the result and ask for spec compliance, edge cases, security, and maintainability.
- Hermes orchestrates: coordinate the run, create or route tasks, track state, and manage handoffs.
The Reddit example describes Hermes breaking one objective into cards: write a spec, have Codex build against it, have Claude Code review it, skip the fix loop if review passes, then summarize the final state. The interesting part is not the exact app. The interesting part is the interface: each worker can receive a goal-shaped instruction.
This is why convergence matters for AI agent architecture. If every tool invents a different job format, orchestration becomes glue-code misery. If the ecosystem converges on durable objectives with verifiable completion conditions, an orchestrator can route work more predictably.
Codex, Claude Code, and Hermes are not interchangeable. The useful pattern is composition: builder, reviewer, and orchestrator, each receiving goal-shaped work.
Why verification matters
/goal is only as good as its verification layer.
An agent can say "tests pass" without actually running the tests. It can say "the build is done" when it only edited files. It can claim a README is accurate while leaving setup steps out of date. This is not malice. It is the usual agent confidence problem at longer time horizons.
So the stopping condition needs evidence.
| Goal type | Weak stopping condition | Better verification |
|---|---|---|
| Build | "The app is complete." | npm test, npm run build, route smoke checks, README checked against commands. |
| Review | "Looks good." | Spec compliance, error states, security risks, test gaps, and blocking/non-blocking findings. |
| Migration | "Migration finished." | Old behavior preserved, new path tested, rollback documented, affected files listed. |
| Research | "Report done." | Source list, uncertainty notes, citations, dated facts, and clear exclusions. |
Hermes is interesting here because an orchestrator can independently run verification after a worker says it is done. That is the safer pattern: the builder builds, the reviewer reviews, and the orchestrator checks the output against the original goal.
This connects directly to the AI agent control plane idea. Long-running agents need logs, owners, permissions, review points, and shutdown paths. /goal gives the work a finish line. Governance makes the finish line trustworthy.
How to run parallel goals safely
The promise of long-running AI agents is not only that one agent can keep working. It is that several agents can work at once. That is also where people get into trouble.
The safe rule is simple: one writer per file at a time.
Parallel goals work best when the boundaries are clear:
- Different repos.
- Different branches or git worktrees.
- Separate packages or modules.
- Implementation in one lane, read-only review in another.
- Fix goals scoped to the specific findings they address.
The bad pattern is three workers editing the same files in the same repo with no shared state beyond terminal scrollback. That creates partial overwrites, hidden reversions, and "almost done" work that nobody can trust.
This is where Hermes' broader feature set matters. The Hermes repo describes delegation, parallel workstreams, gateways, terminal backends, and scheduled automations. In that context, a Kanban board is not decorative. It is how background goals become visible work: card, owner, status, handoff, verification.
Without that visibility, parallel agents feel powerful for ten minutes and messy by hour two.
When not to use /goal
/goal is not the right tool for every task. A good goal is bigger than one prompt but smaller than an open-ended backlog.
Avoid /goal when:
- The task is exploratory and you do not know what done means.
- The agent would need to make business, legal, financial, or brand-risk decisions without review.
- The work spans unrelated tasks that should be separate goals.
- The agent cannot access the files, tools, docs, or tests needed to verify completion.
- Multiple agents would need to write the same files at the same time.
Use a normal prompt for questions, planning, and quick edits. Use /goal when the work has a clear objective, a validation path, and enough room for the agent to make scoped progress.
For business automation, the same rule applies. Let an agent prepare, draft, compare, and validate. Add human approval before it sends, spends, publishes, deletes, or updates a system of record. That is the difference between useful autonomy and expensive surprise.
Further watching
I would treat videos as walkthroughs, not primary documentation. The official docs above are the factual spine. These two videos are useful if you want to see how people are thinking about the feature in live tool use.
Sources
This post is intentionally source-led. The broader interpretation is mine, but the mechanics come from official documentation wherever possible.
- Hermes Agent: Persistent Goals (
/goal) - NousResearch/hermes-agent GitHub repo
- OpenAI Codex: Follow a goal
- Claude Code: Keep Claude working toward a goal
- Reddit community example: /Goal 101 full guide
The short version: the future of coding agents is not one agent that does everything. It is a shared goal contract that lets builders, reviewers, and orchestrators work together without you steering every turn.