Today I learned something new about Claude Code.
That doesn't happen every day anymore. Not because Claude Code is boring, but because after you spend enough time with a tool, most updates feel like variations of things you already know. A new flag here. A better diff there. Useful, yes. Surprising, not really.
But /goal and /loop caught my attention.
Two small commands, one bigger pattern
The idea is simple enough.
/goal lets you tell Claude Code what “done” means. Not in the vague project-management sense, but as a condition: keep working until the tests pass, until the lint is clean, until the migration is complete, until the PR is ready.
/loop is the other side of that. It tells Claude Code to come back and check again. Every few minutes, or whenever it decides the next check makes sense. Watch the CI. Check the deploy. Review the PR again. Keep an eye on the thing that is still moving.
For anyone building with agents, this is the real pattern:
- a goal is a stopping condition;
- a loop is a return mechanism;
- autonomy only becomes useful when both are connected to tools that can verify reality.
That last part matters. Without verification, an agent is just confidently narrating progress. With verification, it can actually work.
The expensive version is easy
I immediately had the obvious reaction: this can burn tokens like crazy.
And yes, it can.
A loop that keeps waking up a strong model to ask “are we done yet?” is expensive. It is also a little stupid. You don't need the smartest model in the room to check whether a command returned zero, whether a workflow is still running, or whether a deployment URL contains the expected version string.
The interesting part is not copying Claude Code's feature exactly. The interesting part is moving the pattern into OpenClaw.
The cheap version is orchestration
OpenClaw already has most of the pieces:
- cron jobs and wake events for the outer loop;
- tool calls that can inspect real state;
- sessions that can continue work;
- cheaper models that can judge simple conditions;
- stronger models that can be brought in only when the work becomes hard.
That changes the economics.
Instead of spending premium tokens on every heartbeat, a cheap model can ask boring questions:
- Did the test suite pass?
- Did the file count change?
- Is the process still alive?
- Did the API return the expected status and content?
- Is there a real blocker, or should we just wait?
Most of the time, that is enough.
When it isn't enough, the system escalates. The expensive model comes in when there is ambiguity, a failing test that needs reasoning, a broken migration, a code change that requires judgment. Not before.
That is the good, nice, cheap version of agentic work.
Bounded autonomy
I don't believe much in the fully autonomous magic framing. It usually hides the cost, the failure modes, or both.
What I do believe in is bounded autonomy: give the agent a goal, give it a loop, give it tools to check the world, and give it a budget-aware way to decide when it needs help.
This is where these commands become more than Claude Code shortcuts. They describe a useful architecture.
A goal says: don't stop until this is true.
A loop says: come back and check.
A verifier says: don't trust your own story; look at the evidence.
A router says: use the cheap brain first, and only call the expensive brain when the cheap one is out of its depth.
That is the part I want to keep building.
Because the future of agents is not only better reasoning. It is better orchestration. Knowing when to think, when to wait, when to verify, when to retry, and when to shut up because the job is already done.
That last one might be the hardest feature of all.