This is where Claude stops being a chat window and starts being an agent: it can read files, write and edit code, run shell commands, and chain many of those actions together to complete a task you described in one sentence. Understanding the toolkit demystifies what’s actually happening.
The core tools
- Read / Write / Edit — open, create, or precisely modify files. Edit works on exact text matches, which is why Claude reads a file before changing it — it needs to know exactly what’s there.
- Bash — runs real shell commands: installing packages, running tests, starting a server, checking git status.
- Grep / Glob — the search tools from Post 3, used constantly mid-task to re-orient.
- WebFetch / WebSearch — look up current documentation or check how a library actually works, rather than relying purely on training data.
- Agent (subagents) — for complex tasks, Claude can delegate a self-contained piece of work to a separate agent instance and use just its final report, keeping the main conversation focused.
The agentic loop
A multi-step task — “add password reset to this app” — doesn’t happen in one shot. It runs a loop: plan the next step, act, observe the result, decide what’s next.
This is why a single instruction like “add password reset” can result in Claude reading the auth code, checking how email is sent elsewhere in the app, writing a new route, editing the user model, and running the test suite — all without you specifying each step. You described the destination; the loop handles the route.
Autonomy has a dial, not a switch
Recall the permission modes from Post 2. They control how much of this loop happens without stopping to ask you:
- In default mode, each risky action (a file edit, a shell command) pauses for your approval.
- In accept-edits mode, file changes flow automatically; higher-risk actions still pause.
- In bypass mode, the loop runs uninterrupted until the task is done or it hits a real blocker.
A useful pattern: start a new or unfamiliar task in default mode to see how Claude approaches it, then relax to accept-edits once you trust the direction it’s taking.
What “multi-step” looks like in practice
A task worth delegating fully isn’t “write one function.” It’s something with real shape: multiple files touched, a clear success condition, and steps that don’t require a decision only you can make. “Refactor this module to use the new API client, update its tests, and make sure the build still passes” is a good multi-step task. “Decide whether we should migrate off this database” is not — that’s a decision for you, informed by Claude’s research, not delegated to it.
Next: once Claude has made changes, how do you verify them properly — testing, debugging, and reviewing its work like you would a teammate’s pull request.