The Safe Agent Loop — Goal, Plan, Change, Verify, Checkpoint

"I want to work in a safe beginner loop.
Please do only this one task: [describe one tiny change].
Goal:
- outcome: [what should be true]
- scope: [files, pages, or systems in scope]
- proof: [test command, browser check, or manual check]

The easiest way to get in trouble with AI coding is to let the session turn into a blur.

You ask for a feature. The agent changes six files. It installs packages. It rewrites a config file. It adds a database table. It fixes a warning you did not ask about. It may even open a browser, run a command, and continue toward a broad goal. Then it tells you everything is done.

At that point, beginners usually do one of two things:

• accept it because the AI sounds confident
• panic because they no longer know what happened

The fix is a loop.

Why this matters

Beginners do not need more courage. They need more checkpoints.

A safe agent session should feel a little slow, a little deliberate, and very understandable. Without that discipline, specific things go wrong: the agent rewrites your config file and your app stops connecting to its database. It installs a package that conflicts with your existing setup and nothing runs. It adds a database table you did not ask for and now you have data you cannot explain. You only find these problems later, when the fix is harder and the cause is buried.

The loop prevents that.

The modern loop

Use this every time:

1. Set one bounded goal
2. Require a plain-English plan
3. Make one reviewable change
4. Verify the result
5. Checkpoint or rewind before the next step

That is it.

If you skip one of those steps, you lose control quickly.

Step 1: Set one bounded goal

Do not start with:

"Build my app."

Start with something smaller:

"Create a single-page calculator with one input, one button, and one result area."

One prompt should produce one meaningful outcome, not an entire product.

Modern agents often support explicit goals, plan modes, subagents, browser checks, hooks, MCP servers, GitHub access, and deployment tools. That is useful only if the goal is measurable.

Good:

"Add one calculator field, update the total, run the existing test command, and stop."

Too broad:

"Make this production-ready."

If your tool has a /goal command, use it to make the outcome visible. If it has a stronger reasoning mode or a frontier model like Fable, use that for planning and risky review, not as permission to let the session run without supervision.

The goal should always name:

• the outcome
• the files, systems, or surfaces in scope
• the proof that counts
• the stopping point
• the things the agent must not touch

Example:

"Goal: add one email field to the waitlist form. Scope: this page and its existing validation only. Proof: the app loads, empty input shows an error, valid input submits to the existing handler. Do not add auth, database tables, deployment changes, packages, or styling rewrites. Stop after verification."

Step 2: Require a plan before files change

The plan is your first safety gate.

Before the agent edits files, ask it to list:

• what it believes the task is
• which files it expects to change
• which commands it expects to run
• which external services it might touch
• what verification it will perform

If the plan mentions auth, payments, database migrations, DNS, deployment, secrets, or production data and you did not ask for those, stop. The task is expanding.

This is also where you use "think hard" or deeper planning. Use deeper reasoning to improve the plan, not to hide the plan.

Step 3: Inspect what changed

Before you ask for the next thing, stop and look at:

• which files changed
• what new dependencies were added
• whether the change matches the scope you asked for
• whether anything risky happened on the side
• whether the agent used any tools, credentials, browsers, databases, or deployment surfaces

You do not need to understand every line. You do need to understand the shape of the change.

Step 4: Verify the result

Run it. Click it. Break it on purpose.

For beginners, testing usually means:

• does the page load?
• does the button do what I asked?
• what happens with empty input?
• what happens with clearly bad input?
• does the UI still look sane on mobile width?

Do not accept "it should work." Make it prove itself.

For agentic tools, testing is not a nice final extra. It is the stop condition. Tell the agent what proof counts before it starts.

Step 5: Checkpoint or rewind

Once something small works, checkpoint it.

A checkpoint might be:

• a Git commit
• a saved branch
• a pushed repo state
• at minimum, a known-good saved copy

The point is simple: if the next AI step goes sideways, you can go back.

If your tool supports automatic checkpoints or rewind, learn that before you need it. Rewind is not a failure button. It is part of the loop.

Where loops fit

Some tools now expose loop commands or scheduled/background work. These are useful for monitoring, repeated checks, or controlled follow-through. They are dangerous when they become "keep coding until it feels done."

Use a loop when the task has a clear recurring check:

• watch the test suite until a known command passes
• monitor a deployment until it is ready
• retry a flaky read-only status check
• poll a queue or background job and report the result

Do not use a loop for open-ended product building:

• "keep improving the UI"
• "make it production-ready"
• "find and fix everything"
• "iterate until it is perfect"

The loop still needs a goal, a maximum time or iteration count, a safe command list, and a stopping rule.

What a good session feels like

A good beginner session feels like this:

• one clear request
• one clear output
• one quick review
• one quick test
• one saved checkpoint

For example: you ask the agent to add a button that clears the form. It changes one file. You see the change, click the button, confirm it works, and save. The whole cycle takes five minutes. That is the rhythm.

If the session starts feeling foggy, the task is too big.

Red flags

Stop and reset if any of these happen:

• the agent changed more files than expected
• it installed packages you do not recognize
• it started talking about auth, database schema, deployment, or secrets unexpectedly
• it connected to GitHub, Vercel, Supabase, Clerk, Stripe, Sentry, or another external service without a clear reason
• it used a loop, subagent, hook, MCP server, browser, or deployment tool without a bounded purpose
• you cannot explain what it just changed
• you are tempted to "just keep going" without running the app

That is not lost progress. That is good control.

Try this now

• Pick one tiny task you could complete in under 20 minutes.
• Write the prompt so it asks for only that one thing.
• Before you send it, write down what files you expect to change and how you will test the result.

That expectation-setting is what makes inspection possible.

Prompt to give your agent

"I want to work in a safe beginner loop. Please do only this one task: [describe one tiny change].

Goal:

• outcome: [what should be true]
• scope: [files, pages, or systems in scope]
• proof: [test command, browser check, or manual check]
• stop condition: [when to stop]
• do not touch: [auth, payments, database, deployment, packages, secrets, etc.]

Before making changes:

1. explain your plan in plain English
2. list the files, commands, and tools you expect to use
3. tell me if this needs a stronger model, deeper planning, a subagent, MCP, or a loop -- and why
4. do not add packages or change config unless absolutely necessary

After making changes: 5. tell me exactly what changed 6. tell me how to test it in one minute 7. run only the verification command or browser check we agreed on 8. stop so I can review before the next step"

What you must review yourself

• Whether the actual file changes match the requested scope
• Whether any dependency, config, or data change slipped in
• Whether the feature really works outside the happy path
• Whether the result is stable enough to checkpoint before moving on
• Whether any loop, goal, model switch, or external tool improved control or merely added motion

Common mistakes to avoid

• Letting one prompt become a whole roadmap. Big prompts make review fuzzy.
• Skipping inspection because the change "looks small." Small-looking diffs can still include risky side effects.
• Not running the app after each step. A working explanation is not a working feature.
• Moving forward without a checkpoint. Progress is only safe when you can undo the last jump.
• Using loops as a substitute for supervision. Loops are for bounded checks, not open-ended wandering.

Key takeaways

• Safe agent work follows a repeatable loop, not an unstructured stream of prompts
• One bounded change is easier to inspect, test, and undo than one giant session
• Agent goals are useful only when they include scope, proof, and a clear stopping point
• Loop commands are useful only when they have maximum bounds and a narrow check to perform
• Checkpoints are part of the workflow, not cleanup afterward
• When the session gets fuzzy, the correct move is to shrink scope again

What's next

Now you know the loop. Next, you need the right target for that loop: a tiny first project that teaches you the workflow without dragging you into auth, billing, or full-product complexity.