/goal, /loop or routines: stop babysitting your coding agent
If you still type a prompt, wait, read the answer and type the next one, your coding agent is exactly as fast as you are. Claude Code now has three ways to let it keep going on its own: /goal works until a condition is true, /loop repeats a prompt on an interval while your session is open, and cloud scheduled tasks, which most people still call routines, run when your laptop is closed. They look similar, but they solve different problems. Pick the wrong one and the task stops too early, runs forever or burns more of your plan than it saves. This is how I choose between them in client projects, and how I set each one up so I can review results instead of every single step.
10 min read
1. Why ping-pong is the real bottleneck
In a normal session the agent stops after every answer and waits for you. That is fine for a question, but a real engineering task, such as moving a module to a new API, needs dozens of turns: run the tests, read the failure, fix, run again. If every turn waits for a human, you spend the afternoon pressing Enter and the agent spends most of it idle. The Claude Code docs frame the three options around one question: what starts the next turn, and what stops the work? With /goal the next turn starts as soon as the previous one finishes, and it stops when a model confirms your condition or judges it impossible. With /loop the next turn starts when an interval elapses. With a routine, a schedule, an API call or a GitHub event starts a fresh cloud session. Once you think in those terms, the choice becomes mechanical, and you stop using a chat window as a job scheduler.
2. /goal: work until a condition is true
You type /goal followed by the condition, and the turn starts immediately; you don't send a separate prompt. Under the hood, the docs explain, /goal is a session-scoped prompt-based Stop hook: after every turn, Claude Code sends the condition and the conversation to your configured small fast model, which answers 'not yet met' (Claude continues and uses the reason as guidance), 'met' (the goal clears) or 'impossible' (the goal clears with a failed entry). The important consequence is that the evaluator doesn't run commands or read files. It only judges what Claude has already shown in the transcript, so 'npm test exits 0' works because the test output appears in the conversation, while 'the code is clean' does not. The condition can be up to 4,000 characters, typing /goal alone shows the condition, runtime, turns, token spend and the latest reason, and /goal clear stops it. It also works headless with claude -p, which is how I run long migrations in CI-like environments.
/goal all tests in test/billing pass (npm test -- test/billing exits 0),
npm run lint exits 0, no test is skipped or deleted,
no file outside src/billing and test/billing is modified,
and git status shows the work committed on the current branch.
Print the last 20 lines of the test output as proof.
Or stop after 25 turns and list what is still failing and why.Tip from practice
/goal doesn't change your permission mode. For unattended turns run it in auto mode; in manual mode Claude still asks before every tool call your settings don't already allow, and the goal waits for you.
3. Write a condition that survives 25 turns
The docs recommend three ingredients, and in my experience all three are needed. First, one measurable end state: a test result, a build exit code, a file count, an empty queue. Second, a stated check, so Claude knows how to prove it, for example 'npm test exits 0' or 'git status is clean'. Third, the constraints that matter on the way there, such as 'no other test file is modified', because an agent under pressure will happily make a test pass by weakening it. Add a turn or time clause like 'or stop after 25 turns', which the evaluator judges from the conversation, so a goal can't run all night. Two pitfalls I see often: conditions that depend on something the evaluator can't see, like a dashboard or a file Claude never printed, and work that keeps a subagent or background shell busy. In that case Claude Code skips evaluation until a turn ends with nothing running, and after 30 minutes it starts check-ins. And if Claude stops using tools for several turns, the loop halts and hands control back with the goal still set.
Tip from practice
Ask the agent to print its evidence (exit codes, counts, the last lines of the test run) at the end of each turn. The evaluator can only approve what it can read.
4. /loop: repeat a prompt while you work
/loop is the right tool when there is no finish line but something outside the session keeps changing: a pull request collecting review comments, a pipeline, a deployment. '/loop 10m check CI on my PR' runs on a fixed schedule; the docs list s, m, h and d as units and round odd intervals to a clean cron step, with one minute as the floor. Leave the interval out and Claude picks a delay between one minute and one hour after each iteration, short while a build is finishing and long when nothing happens. A bare /loop runs the built-in maintenance prompt, which continues unfinished work, tends the current branch's pull request and does cleanup passes, or your own .claude/loop.md if you have one. Three limits matter: the session and your machine must stay on, recurring tasks expire automatically after seven days, and Esc doesn't stop a fixed-interval loop. You ask Claude to cancel it, for example 'cancel the CI loop'.
/loop 10m check the CI status and review comments on my open PR.
If a check failed, read the log, fix the cause on this branch, push and say what you changed.
If a reviewer asked for something, address it or reply why not.
When all checks are green and no comment is open, tell me and stop the loop.5. Routines: run while your laptop is closed
A routine, which the docs now call a cloud scheduled task, is a saved configuration: a prompt, one or more repositories and a set of connectors, run on Anthropic-managed infrastructure as a full Claude Code session. It can have several triggers at once. A schedule runs hourly, nightly, weekly or once, with one hour as the minimum interval. An API trigger gives the task its own endpoint: you POST with a bearer token and can pass a 'text' field such as an alert body. A GitHub trigger reacts to events like pull_request.opened or a release, with filters on branches and labels. Each run clones the repositories fresh and pushes to claude/-prefixed branches unless the prompt says otherwise. It runs as you: commits carry your GitHub user, and runs count against your plan's limits. You create routines at claude.ai/code/routines or with /schedule in the CLI, which creates schedule triggers only, while API triggers are web-only. They are still a research preview, available on Pro, Max, Ultra, Team and Enterprise, and Team and Enterprise owners can switch them off for the whole organization.
# Fire a cloud scheduled task (routine) from an alerting hook.
# URL and token come from the task's API trigger panel on claude.ai/code/routines.
curl -X POST "$ROUTINE_FIRE_URL" \
-H "Authorization: Bearer $ROUTINE_TOKEN" \
-H "anthropic-beta: experimental-cc-routine-2026-04-01" \
-H "anthropic-version: 2023-06-01" \
-H "Content-Type: application/json" \
-d '{"text": "Error rate above 2% on checkout since 14:05 UTC. Stack trace attached."}'Tip from practice
Text sent to the API endpoint arrives wrapped as untrusted data, and Claude won't follow instructions inside it unless the saved prompt says so. Write the prompt to name the payload explicitly, and keep the token in your alerting tool's secret store.
6. Which one when
My decision fits in three questions. Does the task have an end state that tests or commands can prove? Then it's a /goal, whether it's 'make the build green', a framework upgrade or splitting a large file until every module is under a size budget. Does it need to run without you, on a clock or on an event? Then it's a routine in the cloud, or a Desktop scheduled task if it needs files that only exist on your machine. Is there no end, and you only need it while you're working anyway? Then it's /loop. In my projects that means /goal for migrations and red builds, /loop to watch a release or a pull request through review, and routines for the nightly dependency update, the weekly documentation drift check and a first review on every new pull request. Try the decision helper below with a task from your own backlog.
Interactive
Which mode fits your task?
Answer three questions about the task you want the agent to take off your hands.
1.Does it have a finish line a machine can check (tests green, file exists, metric reached)?
2.Should it repeat on an interval or keep watching something?
3.Must it run while your laptop is off, or start from a schedule, an API call or a GitHub event?
7. Guardrails before anything runs unattended
Autonomy is only cheap if a wrong turn is cheap. My baseline for every client: agents work on branches, never on main, and branch protection or rulesets enforce that, which is also what the routines docs recommend for controlling where runs can push. Every goal carries a turn limit. Auto mode runs with explicit deny rules for secrets such as .env files and credential folders, and nobody uses bypass mode on a machine that can reach production. Routines get only the repositories and connectors they need, because everything they do appears under your name. Watch the cost too: /usage shows session cost and plan usage, and a goal pauses on its own when you hit a usage limit instead of failing silently. Finally, a person reviews and merges. In practice that means I review a finished pull request with a clear summary instead of thirty intermediate steps, which is exactly where the time saving comes from.
Tip from practice
Start with routines that only read and report (triage, summaries, review comments) for two weeks. Once their output is consistently useful, allow the ones that push code.
8. What changes for the team
The biggest shift isn't technical. When agents iterate on their own, the scarce skill becomes defining 'done' precisely and reviewing well. Good teams write goals the way they write acceptance criteria, keep a small library of proven conditions and routine prompts in the repository, and treat changes to them like code, with review. They also measure: lead time from ticket to merged change, how often an agent's pull request needs rework, and what each merged change costs in plan usage. In my own projects this way of working is how a small team ships thousands of reviewed pull requests a year without anyone babysitting a chat window. The tools will keep changing names, as routines just did. The pattern stays: a clear finish line, an automatic trigger, a safe place to work and a human gate at the end.
Takeaway
Define done once, let the agent iterate in a safe place, and spend your attention on the review instead of on every step: that is where the real speed comes from.
Real projects behind this
Try it yourself
Sources and official guides
More articles
- 3,025 pull requests in ten months: an AI-assisted delivery process, from the inside
- The EU AI Act for mid-sized companies: what applies to you, and when
- FinOps for AI spend: tokens, caching, routing and budgets that hold
- Making a restaurant network visible in AI answers: a GEO project, step by step
- How this site is built: static where it can be, streaming where it must
- Kubernetes cost on EKS and GKE: the same playbook, different levers
- A landing zone for mid-sized companies, in Terraform or Bicep: the parts that matter
- The legacy migration playbook: waves, parallel runs, and identical row counts and checksums
- MCP security in depth: how to let AI assistants into your product without opening the doors
- Monitoring on business outcomes: green dashboards, empty checkout
- Phone AI agents: the architecture, and the pitfalls nobody shows in the demo
- Restore tests: a backup you have never restored is only a hope
- Streaming AI answers on Azure Static Web Apps: the one header that buffered everything
- Building an AI assistant for WhatsApp, end to end: what it takes beyond the demo
- Air-gapped systems: running critical software with no internet
- Production AI on AWS: Amazon Bedrock and AgentCore in a private setup
- Production AI on Microsoft Foundry: a private reference setup for agents
- Claude's new plans: Max, Ultra and what they mean for teams
- OpenAI Codex at the end of 2026: goal mode, dots and how to lock it down
- GitHub Copilot, Claude Code or Codex? How I'd choose for a company
- GEO basics: how to show up in AI answers
- Production AI on Google Cloud: from Vertex AI to Gemini Enterprise Agent Platform
- Local LLMs in an air-gapped network: AI for your most sensitive data
- I want to run a local LLM: which server should I buy?
- MiniMax M3: an open frontier model you can run yourself?
- Prompt research at scale with an open model
- SEO and GEO together: a practical audit in 6 steps
- Right-size Kubernetes: the playbook that took a cluster from 7 to 4 nodes
- Private AI for sensitive data: a local LLM setup that passes the security review
- From AI prototype to production: the eight layers I add, in order