Autonomous agents in Claude Code sound scarier than they are. Underneath, autonomous agents run on one simple idea that repeats, wrapped in a few commands you can learn over a coffee break. Here is the thing, explained for someone who has just started.
The patterns to understand first
Let me start with the foundation, because everything else builds on it.
All autonomous agents do four things in a row, over and over: they think, call a tool, look at the result, and repeat until the goal is met. That is the whole agent loop, and it is what makes autonomous agents autonomous. Picture a colleague who reads a task, opens the terminal, runs a command, reads what happened, and decides the next step from there. No magic. Just a loop.
When Claude Code edits a file, runs the tests, reads the error, and tries again, that loop is what you are watching. Each tool call is one round. The rest of this guide is about how much of that loop you let run without sitting there approving every step.
/loop: run the same thing again on recurrence
The first tool is /loop. It re-runs the same task at a regular interval, inside the session you are already in.
Say you are waiting on a deploy. Instead of checking yourself every five minutes, you type:
/loop 5m check if the deploy finished and tell me what happened
Now Claude runs that same prompt every five minutes until you stop it. You can also point it at your pull requests, watch a long build, or have it remind you of something later in the session.
You can also let Claude set the pace itself. Drop the interval and it picks a wait between one minute and one hour after each round, based on what it saw: short waits while something is in progress, longer waits when things go quiet.
/loop check whether CI passed and address any review comments
Two things to know about /loop. It lives in your session, so it stops when you close the session or press Esc. And it repeats on a cadence. It does not ask “are we there yet?”, it just fires the prompt again on a fixed or self-chosen interval. The keyword is CADENCE: /loop is about how often, not about an end state.
/goal: work toward a condition, with its own judge
/goal flips that around. Instead of saying how often something should run, you give Claude an end state and let it work continuously until that state holds. It arrived in Claude Code v2.1.139 in May 2026.
The difference between an instruction and a condition is worth a moment, because it is the whole point. An instruction says what to do (“fix the tests”). A condition describes a state you can verify (“every test in test/auth passes and the lint step is clean”). You give it the second one, not the first:
/goal all tests in test/auth pass and the lint step is clean
Claude then keeps working, turn after turn, until the condition holds or you run /goal clear.
Here is the new part, and the reason /goal is more than /loop with a target bolted on. After every turn, a separate, smaller model checks whether the condition is met. The model doing the work is no longer the one deciding the work is done. Think of a proofreader sitting next to the writer: the writer writes, the proofreader reads after each turn and says “not yet” or “now we are there”. That smaller model runs no commands of its own. It only reads what Claude has surfaced in the conversation. So the condition has to be something Claude’s own work can show, like a test result printed in the transcript.
This solves a known problem with most unconfigured agents. An agent that grades its own homework tends to call “done” a little early. Put a separate judge after every turn and “done” stops being self-reported.
In practice: you have one active goal at a time, you can check status, pause, resume, and clear it, and /goal is built on a Stop hook under the hood. Where /loop repeats per invocation, /goal loops tighter, one step at a time, toward a state.
Claude Managed Agents: the agent that runs without your terminal
/loop and /goal both run in the session in front of you. Close the laptop and they stop. Claude Managed Agents (in beta) take the last step and detach the agent from your terminal entirely.
A Claude Managed Agent is a production agent that Anthropic hosts for you, or that you self-host in a sandbox. Four words are worth knowing, and they are simpler than they look:
- Agent: the recipe. The model, system prompt, tools, MCP servers, and skills, all versioned.
- Environment: the sandbox the agent runs in. Either an Anthropic-managed cloud sandbox, or one on your own infrastructure.
- Session: a running instance of the agent working on one task.
- Events: the messages streamed between your application and the agent while it works.
The flow is the same agent loop from the start of this guide, just hosted somewhere else. You send a message. The agent provisions a sandbox, runs the agent loop, and executes tools (bash, files, web search) inside it. As it goes, it streams events back to you. When it runs out of work, it goes idle.
The point of a Claude Managed Agent is that the agent does not need you present. You trigger it through the API or on a schedule, and it works in its own sandbox. If you want to try it, there is a guided setup: run /claude-api managed-agents-onboard in Claude Code.
launch-your-agent: the scaffold from idea to deployed agent
If a Claude Managed Agent sounds like a big jump from /goal, it is. Anthropic published a reference pack on GitHub, launch-your-agent. It walks you the whole way from idea to a deployed Claude Managed Agent, in four phases. First an interview about what you want to build. Then staging and launching a v0. Then grading and iterating against your own “definition of done”. Last, putting it on a schedule. It also ships a /wrap-up companion command for the end.
You walk away with a my-agent/ folder: a build sheet, the exact API payloads, a launch script, an eval scaffold, and a NEXT-DIRECTIONS.md for what v1 and v2 look like. Worth flagging: the pack is Apache 2.0 licensed and stated to be NOT maintained. It is a reference to learn from, not a product to run production on.
The autonomy ladder: four levels of autonomous agents
Here is the whole picture in one place. Autonomous agents are not four different things. They are the same pattern, the agent loop, climbing in how much it gets to run on its own.
| Level | What it is | What loops | What drives it | Where it runs |
|---|---|---|---|---|
| L1 | The agent loop | Per tool call | The next step | The core of everything |
| L2 | /goal | The whole loop, step by step, with a judge gate | A CONDITION | Your session |
| L3 | /loop | The whole prompt again | A CADENCE (interval or self-paced) | Your session |
| L4 | CMA / deployed agent | The whole agent on a schedule | A DEPLOY | Detached infra |
The one contrast to carry with you: /goal CONVERGES on an end state, /loop REPEATS on a cadence, and a CMA detaches the whole thing from your session.
When do I use what
The four forms of autonomous agents each cover a different situation. Short version, based on what you are doing:
- You want to watch something that changes (a deploy, a PR, a build):
/loop. - You have a job with a clear, verifiable end state and you want Claude to stay on it until it is met:
/goal. - You want an agent to run without you sitting in front of the screen, triggered by API or schedule: a CMA.
- You want help going from idea to a running CMA the first time: launch-your-agent.
These are harness features, not model magic
One last thing that is easy to get wrong, and worth getting right early. Autonomous agents in Claude Code rest on features in the harness and the platform around the model, not on properties of the model itself. /loop, /goal, and CMA are those kinds of features. The agent loop, the four-step round, you already have, as long as the model can call tools.
That means you can reproduce the patterns on open weights too. A model like Nous Hermes, trained for function-calling and JSON, gives you the agent loop locally. /loop on a fixed interval is a cron job or a while loop with sleep. The self-paced /loop and /goal are a supervisor that keeps state on disk. For /goal you add a separate evaluator model that judges after each step. The CMA equivalent is the same agent deployed and scheduled on your own infrastructure. The concepts are transferable glue code around an agent loop, not a secret locked inside one vendor.
Where to go next
Start with the official docs and read one thing at a time. For /goal, the completion conditions in Claude Code. For /loop, running prompts on a schedule. For hosted agents, the Claude Managed Agents quickstart. And to build your first one end to end, launch-your-agent on GitHub.
Out of curiosity, which job do you let one stand in alone against a /goal, and what do you still want to approve step by step in your daily work with the agent tools? Share what you have let run, and what made you take a moment to sit back and evaluate your work.
I’m mostly inspired based on how you all put these to use in practice.
Leave a Reply