The Other Mode: Depth Instead of Width
Most of the current conversation about AI coding agents is about scaling outward: more agents, more worktrees, more tickets running at once. We devoted an entire article to that pattern – Parallel Development with AI Agents: Git Worktrees as a Productivity Multiplier – because it unlocks real throughput for teams with many independent tasks.
But there's a second, quieter pattern that matters just as much for businesses looking to deploy autonomous agents in their own processes: what happens when you point a single agent at a single hard problem and let it run for hours without checking in at every step? Not more agents – one agent going deeper.
Anthropic turned exactly this pattern into a concrete tool with the /goal command in Claude Code. According to Anthropic's official changelog, it shipped with Claude Code v2.1.139 in the week of May 11–15, 2026 – part of the same release cycle as the new "Agent view" dashboard for running sessions.
What the /goal Command Actually Does
The core idea is simple to state but precisely implemented: you set a completion condition, and Claude Code then works toward it on its own – across many turns – without you approving every single step.
# Set a goal – kicks off the first turn immediately /goal all tests in test/auth pass and the lint step is clean # Check status: duration, turns, tokens, evaluator's latest reason /goal # Clear the goal early (aliases: stop, off, reset, none, cancel) /goal clear # Headless: runs the loop to completion in a single invocation claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"
Per Anthropic's own documentation, /goal is technically a wrapper around a session-scoped, prompt-based Stop hook. After every turn, Claude Code sends the condition together with the conversation so far to a small, fast model – Haiku by default. That evaluator model returns a yes-or-no decision plus a short reason. On "no," Claude keeps working in the next turn, using the reason as guidance for what's still missing. On "yes," the goal clears automatically and the achievement is recorded in the transcript.
Crucially, the evaluator does not call tools itself. It only reads what Claude has already surfaced in the conversation – a test run, a build exit code, a diff output. That's why a condition like "all tests in test/auth pass" works well: Claude runs the tests itself, the result lands in the transcript, and the evaluator can read it. The condition can be up to 4,000 characters long, and Anthropic's documentation explicitly recommends building in an upper bound, such as "or stop after 20 turns" – without such a clause, a session can in theory keep running for a very long time.
Only one goal can be active per session. It's also worth distinguishing /goal from so-called Auto Mode: Auto Mode automatically approves tool calls within a turn but doesn't decide whether a new turn starts. /goal adds a second, independent layer of judgment between turns – a fresh model decides whether the work is really done, instead of relying on the model that wrote the code.
Depth vs. Width: /goal Compared to Parallel Agents
This is where the explicit comparison to our article on Git Worktrees and parallel AI agents is worth making. Both patterns solve an autonomy problem – but a different one.
Parallel agents via Git Worktrees spread multiple independent tasks across several agents running at the same time: feature A in worktree 1, refactor B in worktree 2, migration C in worktree 3. That's width – more throughput through parallelization. Anthropic pushed this pattern even further with "dynamic workflows" (introduced alongside Opus 4.8, in the week of May 25–29, 2026): a script that Claude itself writes then orchestrates dozens to hundreds of subagents.
/goal does the opposite: one agent, one goal, many turns in sequence on the same branch. Instead of finishing ten small tasks in parallel, one agent works its way through a single, larger task – for example, a complete module migration, until every call site compiles and every test passes. That's depth.
| Criterion | Depth: /goal | Width: worktrees / dynamic workflows |
|---|---|---|
| Number of agents | One agent | Several agents at once |
| Task structure | One large, connected task | Several independent subtasks |
| What triggers the next turn | Evaluator model checks the completion condition | A new agent starts on a new worktree |
| Typical use | Migration, refactoring until coverage is met, clearing a backlog | Parallel feature tickets, model comparison, scout exploration |
| Review effort | One diff at the end of a long session | Several diffs from several branches |
Nothing stops you from setting a /goal inside each worktree of a parallel run. Then you get several deep loops running in parallel instead of several shallow interactions. Width and depth aren't mutually exclusive.
A Case Example: From Prototype to MVP
Clawgency founder Joshua Heller described a concrete example from his own practice in a LinkedIn post – and we want to frame it deliberately as a single case, not as a general benchmark.
The starting point was migrating an application from prototype to MVP: a new database, a new backend, a new storage layer, new authentication – changes that touch nearly every part of the application. Instead of clicking through every test case by hand, he set a /goal that drove Claude Code to run end-to-end tests and security checks on its own: start the app, walk through core flows, interpret failures, fix code, retest – repeating until the agent itself concluded the condition held.
By his own account, the agent caught most bugs automatically and saved him, by his own estimate, roughly a day of manual testing. Some edge cases still needed manual review afterward. That second part matters – more on it in the human-review section below. The example shows what /goal can do in one concrete situation – it is not a reliable benchmark for "what percentage of bugs AI agents catch automatically." Sweeping percentage claims like that circulate in social-media discussions about agents but aren't rigorously substantiated and should be treated with caution.
Best Practices for Using It Safely
Official documentation and practical experience both point to clear guardrails before you point /goal at anything that matters:
- A tightly bounded scope: one module, one feature, one directory – not "make the whole codebase better."
- One testable success condition: "all tests pass" works because the evaluator can read it in the transcript. Vague goals like "the code is cleaner" don't.
- Explicit constraints: what must not change? Which files are off-limits? That belongs in the condition, not just in your head.
- Context the agent can't infer: business rules, compliance requirements, existing architectural decisions.
- Always on a version-controlled branch: never on main. A long autonomous run belongs in isolation.
- A diff review before merging: without exception – more on why in the next section.
The Industry Context: What the Numbers Really Show
Why does this matter right now? Because software testing is an expensive, labor-intensive field – and because the industry is visibly moving toward automation in 2026, without the underlying problem being solved yet.
On pure cost: the U.S. Bureau of Labor Statistics puts the median annual wage for software quality assurance analysts and testers, in its Occupational Outlook Handbook (May 2024 data), at $102,610 (about $49 per hour); for the broader combined category of software developers plus QA analysts and testers, the figure is $131,450 per year ($63.20 per hour).
Industry trend reports paint a picture of growing automation: ThinkSys's "QA Trends Report 2026" reports that over 60% of enterprise QA pipelines are now automated. That's a trend finding from one vendor's research, not a universal fact – but the direction is clear. At the same time, Tricentis's "2026 Quality Transformation Report" shows an interesting counterpoint: despite AI acceleration, 60% of surveyed organizations say they are still shipping untested code to production. Autonomous testing agents, in other words, are not a solved problem — they sit at an active tension point between development speed and testing capacity.
On the cost side, testing vendor Bug0 estimates in its blog post "The 2026 Quality Tax" that manual QA at a fast-growing startup creates hidden costs of roughly $55,000 to $78,000 per developer per year – explicitly one testing vendor's own estimate, not an industry-wide benchmark.
What Still Needs Human Review
As capable as the loop is, it has a structural limit that follows directly from how the evaluator works: it doesn't run commands itself and can only judge what Claude has surfaced in the conversation. Whatever Claude doesn't test or doesn't mention, the evaluator cannot assess. A "yes" means "the condition holds according to what's in the transcript" – not "the code is bug-free."
Concretely, at least these things remain a human responsibility:
- Business-logic edge cases: cases no test covers because nobody thought to write one.
- Security-sensitive code: even with a "security check" written into the goal, that's no substitute for a dedicated security review around auth, payments, or personal data.
- Data migrations: a green test run doesn't prove historical production data migrated correctly.
- Compliance questions: automated tests check function, not legal compliance.
- UX and product decisions: "it works" and "it's the right solution for users" are two different questions.
The honest framing: autonomous agents like a /goal run shift where human attention is spent – from "watch every intermediate step" to "review the final result." They don't remove the review.
The Parallel to OpenClaw in the Enterprise
This trust question isn't unique to software development. Anyone embedding OpenClaw agents into their own business processes – customer service automation, quote preparation, document processing – faces the same underlying question as a developer watching a long /goal run: how do you review autonomous work without watching every step?
Claude Code and OpenClaw are deliberately separate here: Claude Code is Anthropic's CLI for coding agents, while OpenClaw is the open-source agent framework Clawgency implements for business-process automation across the German-speaking Mittelstand – built in part on tools like Claude Code, but a distinct product with its own governance layer. The core pattern from this article – a tightly bounded scope, a testable success condition, review at the end rather than at every step – carries over directly to our OpenClaw implementations for enterprises and to the concrete use cases and ROI patterns for the Mittelstand we describe there.
Clawgency implements OpenClaw agents for DACH businesses – with clearly defined approval boundaries, audit logging, and review processes that answer exactly the questions this article raises for Claude Code: where can the agent act autonomously, and where does it need a human in the loop?
FAQ: Claude Code /goal and Autonomous Testing Agents
/goal sets a completion condition (e.g. "all tests in test/auth pass and the lint step is clean"). Claude then keeps working turn after turn without waiting for approval at each step. After every turn, a small fast model (Haiku by default) checks whether the condition holds. If not, the next turn starts automatically. Once the condition is met, the goal clears itself.
Git Worktrees spread multiple independent tasks across several agents running at the same time – width. /goal keeps a single agent focused on one concrete objective across many turns – depth. Both patterns solve different problems and can be combined.
A /goal session runs until the condition is met or you run "/goal clear". Since the evaluator has no built-in time limit, Anthropic's own documentation recommends adding an explicit bound to the condition itself, such as "or stop after 20 turns". Without such a clause, a session can in theory run for a very long time.
No. The evaluator does not run commands itself and only reads what Claude has already surfaced in the conversation. It cannot judge what Claude didn't test or didn't mention. Autonomous output is not automatically shippable – a diff review before merging remains mandatory, especially for security-sensitive code and edge cases.
Claude Code and OpenClaw are different systems – Claude Code is Anthropic's CLI for coding agents, OpenClaw is the agent framework Clawgency implements for business processes. But the trust question is identical: how do you review autonomous agent work without watching every step? That is exactly the question Clawgency answers for OpenClaw deployments in the Mittelstand.
Ready for agents that work independently – under control?
Clawgency implements OpenClaw agents for businesses in Germany, Austria, and Switzerland – with clear approval boundaries, audit logging, and a compliance-ready review process. Live in 2 to 4 weeks.
Book a Free Call →