Skip to content

4.1 Inside the Loop: Gather, Act, Verify

Every competent agent on earth runs the same three-beat rhythm. This lesson dissects one beat at a time — what the agent is actually doing, what good looks like, and where you fit — so that watching a session becomes like watching a game you know instead of static.

What you will learn

  • Describe what happens inside each phase: gather, act, verify.
  • Recognize healthy loop behavior vs. warning signs, live.
  • Know your role in each phase — where to lean in, where to let it run.

Builder principle

Watch the loop, not the text. The quality of an agent's process predicts the quality of its output several minutes before you see the output.

Phase 1: Gather

Before acting, a good agent builds situational awareness — it reads files, searches the project, checks configuration, runs read-only commands. In Claude Code you literally watch this: Read, Grep, List operations scrolling by.

Why this phase decides everything: the model can only reason about what's in its context window (Lesson 2.2). Gathering is context construction. An agent that reads your existing styles before adding a page produces a matching page; one that doesn't produces a Frankenstein. Same model — different gather.

Healthy signs: it reads the files it's about to change; it checks how similar things are already done in your project; its questions (if any) are sharp and few.

Warning signs: it starts writing immediately into a project it's never looked at; or the opposite failure — it wanders through dozens of irrelevant files (usually means your brief gave it no target).

Your role: point the gather. A brief that names files, folders, or examples ("match the style of index.html") turns minutes of searching into seconds of reading.

Phase 2: Act

Creating files, editing code, running commands — visible as Write, Edit, and Bash operations, each passing through your permission gates (Lesson 3.5).

What good acting looks like:

  • Small moves. Competent agents edit incrementally — a file here, a function there — rather than one gigantic rewrite. Small moves are reviewable and reversible.
  • Announced intentions. You should generally know what it's about to do before it does it, because it said so.
  • The project's idiom. New work should look like existing work — naming, formatting, structure. (This becomes enforceable in Chapter 5 with CLAUDE.md.)

Warning signs: sweeping multi-file rewrites for a small request; installing dependencies you didn't discuss; touching files unrelated to the goal. None of these are catastrophes — they're moments for ++esc++ and a steering question: "Why are you modifying the config? The task was the header."

Your role: gatekeeper at the permission prompts, brake operator when direction drifts. Steer early — interrupting a wrong turn at second 30 is cheap; unwinding it at minute 20 is not.

Phase 3: Verify

The beat that separates agents from autocomplete. After acting, a good agent checks its own work: runs the code, executes the tests, re-reads the output, opens the build. And when verification fails, it feeds the error straight back into a new gather-act-verify turn — that self-correction cycle is the engine of agentic quality.

Healthy signs: it runs something after building; it reports evidence ("tests pass, 14/14" — not "should work now"); when something fails, it reads the error and fixes the cause rather than trying random variations.

Warning signs: "Done!" with nothing executed; the same error attacked three times with the same approach (context is polluted or the brief is fighting itself — /clear and re-brief); success claims that don't survive your own eyes.

Your role: demand evidence, then perform the last verification personally — as the user, on the real thing (Lesson 4.4 goes deep). The agent's checks reduce your work; they never replace it.

One loop, many turns

Real tasks run the loop many times — gather, act, verify, adjust, act again, verify again. Watch a session with this lens and agent behavior stops being mysterious:

  • When an agent is stuck, check for missing context and missing verification first, then consider capability, tool, environment, or scope limits.
  • Great sessions are boring: read, small change, check, repeat, done.

Boring is the goal. Boring ships.

Try it now

Run a session on your quick-win project with a deliberately medium brief — real but not huge:

Add a simple contact section to my site: email link, GitHub link,
and a one-line invitation to reach out. Match the existing style.

Your only job this session: narrate the loop in your journal. For each turn, one line — G: what did it read? A: what did it change? V: what did it check? At the end, grade the session: where was it strongest? Where would better gathering have helped?

This observation exercise, done once carefully, permanently changes how you watch sessions.

Check your understanding

  • What is the agent actually building during the gather phase, in Lesson 2.2 terms?
  • Name two warning signs in the act phase and the correct response to each.
  • What's the difference between "should work now" and evidence? Give an example of each.
  • Why are boring sessions the goal?