Claude Code Autonomous Agents: How the /goal Command Redefines Long-Running Task Completion
Claude Code autonomous agents now use /goal to set termination contracts upfront—learn how this replaces messy polling loops in long-running AI task completion.
TL;DR: As of 2026, Claude Code autonomous agents support a/goalcommand that lets developers declare a machine-evaluable completion condition before a run starts. Instead of relying on custom polling loops that re-evaluate "are we done?" on every turn,/goalis designed to encode a durable termination contract at the platform level through Claude Managed Agents infrastructure, so the agent runs until that specific condition is met and then stops cleanly.
Key Takeaways
/goalis designed as a platform-level termination contract: developers declare completion conditions as a first-class feature at task-start rather than writing custom turn-by-turn polling logic.- Good completion conditions must be machine-evaluable: vague goals like "finish the refactor" cause runs to drift or never terminate cleanly.
- The bottleneck in long autonomous runs shifted from duration to definition: practitioners already run agents for 90-plus days; the hard problem is specifying "done" precisely before the run starts.
/goaldoes not replace review gates: human checkpoints remain intra-run controls;/goalgoverns when the entire task ends.- Precise stopping conditions are intended to eliminate redundant per-turn completion queries that compound across the duration of a long run.
What Is the /goal Command and Why Does It Matter for Claude Code Autonomous Agents?
The /goal command, as described in the Claude Code and Managed Agents ecosystem, is a mechanism for encoding a durable termination contract: a machine-evaluable completion condition written before the first token of a run is generated. The practical significance is that it is designed to move the "are we done?" evaluation from a per-turn polling loop inside a user-built harness to a platform-level signal honoured by Claude Managed Agents infrastructure.
Multi-day autonomous runs are already proven in practice. Practitioners have documented 97-day autonomous runs with custom harnesses and mandatory review gates. Anthropic tracks agent autonomy duration as an active research metric. The infrastructure to sustain long runs exists. The gap that /goal is designed to address is knowing when to stop, and being able to specify that boundary in terms a machine can evaluate without a human watching the final turn.
Why Doesn't Custom Harness Logic Already Solve the Termination Problem?
Custom polling harnesses solve many problems, but they evaluate completion at the application layer on every turn, against a loosely specified end state. This works until scope drifts, costs compound across concurrent runs, and the agent continues past the logical end of a task because the exit condition was never precise enough to trigger.
Think of it as the difference between asking a contractor "are you done?" every morning versus handing them a signed punch list on day one. The punch list does not make the contractor smarter; it makes the definition of done explicit and enforceable before work begins.
/goal, as a platform-level construct within Managed Agents, is designed to encode that punch list as a machine-evaluable artifact at task-start. User-built harnesses sit at the application layer and can continue to poll and gate intra-run behavior. The intended distinction is that /goal provides a termination signal the platform itself is designed to honor, rather than one that a harness must simulate on every loop iteration.
What Makes a Completion Condition Machine-Evaluable?
A strong /goal condition references specific, observable artifacts rather than subjective states. The framework used in this guide distinguishes four condition types by evaluability and risk, named here as the /goal Termination Contract Rubric for ease of reference:
| Condition type | Example | Machine-evaluable? | Risk | Recommended for /goal? |
|---|---|---|---|---|
| Vague intent | "Finish the API refactor" | No | Run never terminates cleanly | No |
| Partial observable | "All files updated" | Partial | Misses correctness criteria | Use with caution |
| Strong observable | "CI passes, zero lint errors, PR merged to main" |
Yes | Low drift risk | Yes |
| Composite contract | "CI green + integration tests pass + no TODO markers in diff" |
Yes | Lowest drift risk | Preferred |
Writing a termination contract before a long run forces a question most teams defer: what does done actually mean? Anthropic measures agent autonomy by tracking elapsed time without human involvement, which means an undefined goal can translate into a run that outlasts its usefulness. As a practical rule of thumb: if evaluating a condition requires a human to read prose and make a judgment call, it belongs in a review gate, not a /goal declaration.
How Does /goal Interact with Review Gates and What Does It Replace?
/goal and review gates are orthogonal controls. Review gates are intra-run human checkpoints that govern whether the agent may proceed from one step to the next. /goal is an end-of-run control that governs whether the entire task is complete. Both can coexist in the same run.
The documented 97-day run used four mandatory review gates between every generated step. Those gates are intra-run safety controls. /goal adds the missing terminal boundary that review gates were never designed to provide.
What /goal is intended to replace is the final polling check: the per-turn "are we globally done?" evaluation that otherwise fires continuously throughout a run. Claude Code Remote Control, which lets developers continue a session across devices (Causal Inference Substack), makes cross-session runs practical. /goal is designed to make those runs terminable without requiring a human to monitor the last turn.
What Are the Compute Implications of /goal Versus a Polling Harness on a Long Run?
In a polling harness, every turn includes a completion check: send context, ask "are we done?", parse the response, loop. On a long autonomous run, that pattern repeats across every agent turn for the full duration of the task. /goal is designed to encode the condition once, with the agent evaluating it against observable artifacts such as CI status, file diffs, or test counts, rather than issuing a round-trip completion query each turn.
Developers have documented running large numbers of Claude Code agents simultaneously, a context where imprecise completion criteria carry costs that compound across every concurrent run. In this guide's framework, /goal is most valuable in multi-agent scenarios where scope definition at task-start is cheaper than scope correction mid-run.
Frequently Asked Questions
Does /goal work with existing Claude Code harnesses, or do I need to rebuild my setup?
/goal is designed to sit at the Managed Agents layer, below your application harness. The intended behavior is that you add a /goal condition at task-start and Managed Agents handles termination, while your harness continues managing intra-run behavior exactly as before. No full rebuild should be required.
What happens if a /goal condition is never met? Does the run continue indefinitely?
Managed Agents supports infrastructure-level constraints on runs. As a practical rule of thumb, define a fallback budget ceiling alongside your completion condition rather than relying on /goal alone to bound an open-ended run.
Can /goal handle multi-step tasks where "done" changes based on intermediate results?
/goal is best suited to a single terminal condition. For multi-phase tasks, the framework used in this guide recommends scoping each phase as its own agent run with its own termination condition, rather than encoding dynamic completion logic into one declaration.
How is /goal different from writing a detailed system prompt that tells the agent when to stop?
A system prompt instruction is advisory and interpreted probabilistically on each turn. /goal is designed as a platform-enforced contract evaluated against observable artifacts. The practical difference is telling a contractor "stop when it looks done" versus handing them a signed checklist with explicit pass/fail criteria that a third party can verify.
Conclusion
The /goal command does not make Claude Code agents smarter. It pushes developers to be more precise about what they are asking agents to do. Runtime duration was never the hard problem; a 97-day run proved that. Articulating "done" in machine-evaluable terms is where most long-running setups break down.
User-built polling harnesses paper over a real question: was the agent genuinely autonomous, or was the harness simulating autonomy by checking completion every turn? /goal is designed to settle that by moving the termination contract to the platform level, where it can be enforced rather than merely requested.
Before your next long autonomous run, write your /goal condition and ask: can the agent evaluate this without calling me? If not, rewrite it until it can.
Learn from me
Claude Code in Practice, my Maven cohort. Master Claude Code from fundamentals to advanced orchestration: skills, subagents, hooks, MCP, and production automation. Join the next cohort →
Hire us
Traversaal.ai. We're a team of forward deployed engineers solving the toughest AI problems for Fortune 100 companies: document intelligence, agentic data platforms, and real-time web intelligence, deployed in production. Work with our team to deploy your next agentic ecosystem. Talk to Traversaal.ai →
Join us
Want to solve these problems with us? We're always looking for forward deployed engineers who want to ship production AI. jobs@traversaal.ai
