Agentic Loop Simulator
Watch a coding agent run an agentic loop, one step at a time. A planner, a builder, and a judge cycle through plan, build, verify, and repeat until the goal is met. Toggle the separate judge off to see why an agent grading its own work ships confident bugs. An animation-first, interactive explainer of loop engineering and how it maps to Claude Code.
Category: DevOps
What You Will Learn
- What an agentic loop is: plan, build, judge, then repeat until the goal is met
- Why a coding agent finishes multi-step work on its own instead of answering once
- How the decision at the end of each loop chooses to keep going or stop
- Why the judge should be a separate agent, and what happens when it is not
- Why token cost compounds as the context window grows each loop
- How the phases map to Claude Code: subagents, the Read/Edit/Bash tools, and a stop condition
Topics covered: ai, agents, agentic, loops, loop-engineering, claude-code, llm, coding-agents, automation, educational, interactive
// simulator
Agentic Loop Simulator
Watch a coding agent run an agentic loop, one step at a time. A planner, a builder, and a judge cycle through plan, build, verify, and repeat until the goal is met. Toggle the separate judge off to see why an agent grading its own work ships confident bugs. An animation-first, interactive explainer of loop engineering and how it maps to Claude Code.
Agentic loop · three agents
A loop of three agents: plan, build, judge
Decide the single next step toward the goal.
Do it: read, edit, run a command.
Grade the result against the goal and spec.
Loop state
Context window (grows each loop)
Illustrative model of the multi-agent loop pattern (plan → build → judge → repeat) used by coding agents like Claude Code. It shows the harness and the role split, not any model's internal reasoning. Turn the separate judge off to see why an agent grading its own work ships confident bugs.
About this agentic loop simulator
What you'll learn
- How a coding agent runs a loop instead of answering a single prompt
- The three roles: a planner picks the next step, a builder does it, a judge checks it
- Why "the tests pass" is not the same as "the goal is met"
- Why the judge being a separate agent is what stops the loop shipping confident bugs
- How the context window grows each loop, and why that makes cost climb
- What each phase maps to in Claude Code
How the loop works
- Plan: gather the goal and the last result, decide the single next step
- Build: take one action, read a file, edit code, run a command
- Judge: grade the result against the goal and the spec, not just the tests
- Decide: goal met means stop, not met means loop back to plan
Watch the verifier make the difference
The single most important control in the simulator is the "separate judge agent" toggle. With it on, a second agent reviews the work against the spec and catches a status code the builder got wrong. Turn it off and the builder grades its own work, sees green tests, and stops, shipping a confident bug. That is the whole reason serious agent loops split the agent that writes the code from the agent that checks it.
How this maps to Claude Code
Plan and Judge are the kind of work you hand to a subagent, often a different model, so the judge is not grading its own homework. Build is the main agent using the Read, Edit, and Bash tools. The loop runs until a goal condition or a turn limit, the same way a real harness keeps an agent going until the work is actually done.
Go deeper
The companion post, Stop Prompting, Start Looping, covers why engineers at Anthropic, NVIDIA, and beyond say the job is shifting from writing prompts to designing loops, and what actually makes a loop reliable rather than an expensive way to ship bugs.
Why learn it this way?
- The loop is a simple cycle, but it is the thing that turns a chatbot into an agent.
- Seeing the plan, build, and judge steps hand off makes the pattern concrete.
- Watching an unverified loop finish wrong is the fastest way to learn why verification matters.
Overview
Coding agents such as Claude Code do not write a change in one pass. They run a loop: plan the work, build it, judge the result, and go round again until a check says the task is done. This simulator plays one task through that loop slowly enough to follow. One phase lights up at a time, a decision gate shows whether the loop continues or stops, and a context window fills up as the attempts accumulate, which is why long loops eventually need summarizing or a fresh start. The most important control is a toggle that replaces the separate judge with the agent checking its own work. With an independent verifier, such as tests or a second reviewer, the loop catches the bug and ends with work that was actually verified. With a self-check, the same agent tends to approve what it just wrote, and the run can stop early or ship a confident bug. The takeaway is that the quality of an agentic workflow depends more on the verifier than on the builder.
Try this
- Play the task through the loop and watch the decision gate choose to loop again or stop after each judge phase.
- Turn the separate judge into a self-check and replay the task to see how it ends with a confident bug instead of verified work.
- Use the previous and next buttons to step through a run and watch the context window grow with every attempt.
Frequently asked questions
- What is an agentic loop?
- A pattern where an AI agent repeatedly plans, acts and checks the result, feeding what it learned into the next attempt, until a stopping condition such as passing tests is met.
- Why should a coding agent not grade its own work?
- An agent that checks its own output shares the same blind spots that produced it, so it tends to approve its own mistakes. An independent verifier, such as tests, a linter or a separate reviewer, catches more real bugs.
- Why does the context window matter in a long agent run?
- Every step adds tokens. As the window fills, older details get less attention or must be summarized, so long loops benefit from clear checkpoints and fresh context.
Try next
// simulator
Preview Environment Simulator
See how a pull request becomes a temporary copy of your app, complete with a private URL, safe test data, review checks, and automatic cleanup.
// game
Heroku-Style Name Generator
Generate names the way Heroku, Docker, Kubernetes, and petname do, see how the word lists combine, and learn when the birthday problem makes random names collide.
// simulator
How Docker Works Under the Hood
Watch what really happens when you run docker run -p 8080:80 nginx, one layer at a time. Step down the whole stack: the CLI, the daemon, the registry pull, containerd, the OCI runtime bundle, runc, the running container, and the shared Linux kernel. Every stage shows the real low-level command you can run yourself, so it doubles as a tour of the primitives that make a container: namespaces, cgroups, and runc. A container is not a small VM, and this shows you why.