On April 30, OpenAI's Codex CLI v0.128.0 quietly added a /goal command. On May 11, Claude Code 2.1.139 shipped it. Nous Research's Hermes had a working version earlier in April. In between, Anthropic posted a tweet about the feature that picked up 606,000 views in 24 hours.
Three frontier agent tools shipped the same primitive in 11 days. That's not coincidence — it's industry consensus reaching the surface at the same time.
What it actually is
The /goal command lets you give an agent a goal in plain language, and then runs a small validator model after every turn to check: was the goal met? If yes, stop. If no, continue. The agent's loop is now bounded by a definition of done, not by a turn count or a "feels done to the model" judgment.
Operationally, this is the Ralph loop — the agentic pattern named informally for the way the validator nags the agent to keep going until the work is actually finished. Production teams have been hand-rolling versions of this for months. Each tool now ships it as a first-class command.
The version that works in practice is straightforward to describe:
- The user invokes
/goal <description>. The description is a testable completion condition, not a vague aim. - The agent runs its normal turn — tool calls, generation, observation.
- After the turn, a small fast validator (Haiku-class) reads the agent's trajectory and the goal description and returns
{ done: bool, reason: string }. - If
done, the loop stops and the agent reports. If not, the next turn fires with the validator's reason appended to context. - A hard turn cap (50, 100) keeps the loop bounded even when the goal is unachievable.
Goals that work
The key word above is "testable." /goal find the bug doesn't work — there's no validator response that can say "yes, the bug is found." /goal find the bug and make the test in src/foo.test.ts pass works — the test either passes or it doesn't.
Good /goal invocations share three properties: a concrete completion artifact (a file, a passing test, a deployed change), an observable side effect (something the validator can check), and a bounded scope (no "fix everything" goals).
Bad invocations share their own pattern: open-ended quality goals ("make it good"), goals that require the validator to be smarter than the agent, and goals whose completion is subjective.
The bigger shift
Three tools shipping the same primitive in 11 days is a signal. The primitive is the validator-in-the-loop, and the bet underneath it is that the agent's loop should be bounded by checking, not by guessing. The agent isn't smart enough to know when it's done. The validator doesn't have to be smart — it has to be different. Same pattern as the agentic-ETL "agent proposes, validator confirms" sandwich, applied one layer up.
The 606K views on a single feature announcement are a separate signal. People who don't usually pay attention to CLI changelogs paid attention to this one. The vibe in the comments was less "cool feature" and more "finally, someone shipped it." That's the tell — a lot of teams had been waiting for the industry to converge on a name and a shape.
What to watch
Three things to track over the next quarter.
First, whether the validator gets pulled out as a separate layer the way RAG retrievers did. Right now the validator is built into each tool. The natural next step is a shared validator service that all three tools (and your own agent harness) can call into.
Second, whether /goal goals start composing — nested goals, or goal stacks. The current syntax is one goal at a time. Production usage will push for hierarchies.
Third, whether your spend graph survives. A loose goal with a high turn cap is the easiest way to burn $5,000 of agent budget in an afternoon. Cost circuit breakers (covered in the Harness Engineering drip) become non-optional as /goal adoption climbs.
Three tools. Eleven days. One primitive. The Ralph loop is no longer a hack — it's a command.
Comments
No comments yet. Be the first.