The agentic loop

Every agentic coding tool — Claude Code, Cursor Agent, Cline, Windsurf — runs the same fundamental loop. The implementations differ, but the structure is identical. If you understand this loop, you understand how every agentic tool thinks.

The four phases

The agent does not run these phases once. It runs them in a loop, refining its understanding with each iteration. The first pass might be wrong. The verification step catches it, and the next iteration fixes it.

This is the single most important concept in agentic coding. Everything else builds on it.

Phase 1: Gather

Before Claude writes a single line of code, it reads. This is the phase most people skip when they work manually — and the phase that makes agentic tools powerful.

When I ask Claude to fix a bug, the first thing it does is not edit the file where the bug lives. It reads the error message. It greps for related function names. It reads the test file to understand expected behavior. It checks the git log to see when the file was last changed and why.

Read file: src/components/ContactForm.tsx
Grep: "handleSubmit" across src/
Read file: src/lib/validations/contact.ts
Bash: git log --oneline -5 src/components/ContactForm.tsx
Read file: src/app/api/contact/route.ts

This is not random exploration. Claude reads strategically. It starts from the point of failure and fans out to related code. Each file read costs context tokens, so the model has an incentive to be selective.

The quality of the gather phase determines everything. If Claude reads the wrong files — or too few files — it will build a flawed mental model and the plan will be wrong. If it reads too many files, it burns context and performance degrades later.

Phase 2: Plan

After gathering, Claude reasons about what to do. This is where model intelligence matters most.

With extended thinking enabled, you can sometimes see this phase explicitly — Claude working through options, considering edge cases, deciding which approach to take. Without extended thinking, the planning is implicit, embedded in the model's internal computation.

The plan phase is where Claude decides:

• Which files need to change
• In what order to make the changes
• Whether to create new files or modify existing ones
• What verification steps to run afterward

You cannot see most of this reasoning. But you can influence it. A clear CLAUDE.md, well-named files, consistent patterns — these all feed into the planning phase. Claude does not plan in a vacuum. It plans based on what it learned in the gather phase.

Phase 3: Act

This is the phase most people focus on — the actual edits. But by the time Claude starts editing, the important decisions are already made.

The act phase is a sequence of tool calls:

Edit file: src/components/ContactForm.tsx
  → Replace handleSubmit with async version
  → Add error state handling

Write file: src/lib/validations/contact.ts
  → New Zod schema for form fields

Bash: npx tsc --noEmit
  → Check types compile

Each tool call is a discrete action. Edit replaces specific strings in a file — it is surgical, not a full rewrite. Write creates new files. Bash runs commands. The model chains these together based on the plan.

One thing I have noticed: Claude tends to make multiple related edits before verifying, rather than verifying after every single edit. It batches changes that logically belong together. This is efficient — running the build after every line change would waste time and context.

Phase 4: Verify

This is where agentic tools separate themselves from everything else. Claude checks its own work.

The simplest form of verification is running the build. If TypeScript compiles, the changes are at least structurally correct. But verification can go much deeper.

What does that pipeline actually look like when codified?

Phase 1: Build        → pnpm build (structural correctness)
Phase 2: Types        → tsc --noEmit (type safety)
Phase 3: Lint         → eslint + biome (style + patterns)
Phase 4: Tests        → unit + integration + E2E (behavior)
Phase 5: Security     → OWASP Top 10 checklist (vulnerabilities)
Phase 6: Diff review  → pattern-violation detection (consistency)

In a fully configured system, a verification-loop skill loads this entire pipeline on demand. The security phase runs an OWASP Top 10 checklist — not because you remembered to ask for it, but because the skill includes it. The diff review catches pattern violations — inconsistencies with existing code that tests alone cannot detect. None of this requires you to remember anything. The skill loads it all when verification starts.

Here is what a real verification sequence looks like:

Bash: pnpm build
  → ✓ Build succeeded

Bash: pnpm lint
  → ✗ Warning: unused import in ContactForm.tsx

Edit file: src/components/ContactForm.tsx
  → Remove unused import

Bash: pnpm lint
  → ✓ No warnings

Bash: pnpm test -- --run contact
  → ✓ 4 tests passed

Notice what happened: the linter caught an issue, Claude fixed it immediately, then verified again. This is the loop in action — verify, find a problem, act, verify again. No human intervention required.

When the verification step fails and Claude cannot fix the issue after two attempts, that is your signal to intervene. We will cover this pattern — the "two corrections rule" — in Chapter 3.

The loop in action: a real bug fix

Let me walk you through a real example from my own work. I had a bug where the contact form's success toast was showing before the email was actually sent. Race condition.

Gather: Claude reads the ContactForm component, the TRPC mutation, and the server-side email function. It checks the toast library's API. Four file reads.

Plan: Claude identifies the issue — the toast fires on mutation call, not on mutation success. It needs to move the toast into the onSuccess callback.

Act: Claude edits the ContactForm component. Moves the toast call from after mutate() to inside the onSuccess option of useMutation. Two lines changed.

Verify: Claude runs the build. It passes. Claude runs the existing test for the form. The test was checking that the toast appeared immediately — which was the old (buggy) behavior. The test fails.

Loop back — Gather: Claude reads the test file more carefully.

Plan: The test needs to be updated to wait for the mutation to resolve before asserting the toast.

Act: Claude updates the test to use waitFor and assert the toast after the mock mutation resolves.

Verify: Build passes. Tests pass. Done.

Why this matters for you

Understanding the loop changes how you interact with the agent. Instead of giving Claude one instruction at a time ("read this file", "now edit this line", "now run the build"), you give it the goal and let the loop run.

Your job is not to micromanage the loop. Your job is to set it up for success:

• Good codebase structure makes the gather phase fast and accurate
• Clear CLAUDE.md makes the plan phase reliable
• Consistent patterns make the act phase predictable
• Verification pipelines make the verify phase thorough

Every chapter in this course maps to one of these four responsibilities. That is not a coincidence. The loop is the foundation. Everything else is optimization.

Right now, you understand the loop. That puts you ahead of 90% of developers using agentic tools. But understanding the loop and optimizing each phase are two different things. The developers who get 10x results are the ones who have built systems around each phase — infrastructure that makes gathering thorough, planning reliable, acting consistent, and verifying automatic.

That system is what the rest of this course builds. But first, there is something practical you need to understand: the tools Claude uses in each phase are not free. Every tool call has a cost. Let's look at what Claude can actually do — and what each action costs.