How to Engineer an AI Loop You Can Actually Walk Away From
A build-along. The five parts of a loop you have to design on purpose, starting with the stop condition.
I watched an agent I built keep working for a few minutes after it should have stopped. I was working on a new Claude and Notion agent integration where I could talk to my Claude and it would build out the exact pages I needed in Notion and think ahead to future needs. It did the task it was given. It also kept going, because nothing in the loop told it the job was finished. I ended up with half of what I wanted and half random pages printed with random AI thoughts.
Prompt engineering is choosing the words you hand the model. Loop engineering is designing what the system does with its own output: when it stops, and where you sit in the cycle. It matters more than the prompt for a blunt reason. The prompt fails in the demo, where you can see it. The loop fails three weeks later in production, quietly. Gartner expects more than 40% of agentic AI projects to be canceled by 2027, and the reasons it gives (runaway cost, fuzzy value, weak risk controls) are loop failures, not model failures.
What follows is the version of the instructions I wish someone had handed me when I was first exploring loops, written for a person who has never opened a terminal and is not sure they belong here. You do.
Here is what you will have at the end: a small program that reads emails you flag, writes a draft reply for each one, and saves the drafts to a folder for you to review. It never sends anything on its own. You build the brakes, and you watch them work before you trust them with anything real.
You are asking Claude to build a thing with five brakes in it. You do not have to understand the code. You only have to understand the brakes, because they are the reason this is safe:
It stops on its own, either when the flagged emails run out or after a set number of steps.
It checks its own drafts before saving them, and throws out the bad ones.
Anything it cannot undo (sending, deleting, archiving) waits for you. It never does those itself.
It writes down everything it did, so you can see why it made each choice.
When it gets stuck, it stops cleanly and tells you, instead of improvising.
That is the whole design. Now let us set it up.
Step 1. Get your key. This is the one secret you need.
Your agent needs its own way to talk to Claude when it runs, separate from any chat app you use. That is what an API key is.
Go to console.anthropic.com and make an account. This is the builder’s side of Anthropic, and it is separate from the claude.ai chat subscription you might already pay for. You need this one.
Once you are in, find Plans and Billing and add a small amount of credit. Five dollars is plenty. Running this tutorial costs pennies, not dollars. While you are on that screen, set a monthly spending limit. Do it now, not later. The classic beginner story is leaving a script running overnight and waking up to a bill. With a cap, the worst case is that your script quietly stops, not that your card gets a surprise.
Then go to API Keys, click Create Key, name it something like “inbox-agent,” and copy it the instant it appears. It is shown to you exactly once. If you miss it, no harm done, just delete it and make another.
That key is a password. Treat it like one. Store it in a password manager. Never paste it into a shared document, never put it in a public folder, and never hand it to anyone who asks, including an AI in a chat window. Nothing legitimate ever needs you to type it into a conversation.
Step 2. Get Claude Code, the thing that will build the agent for you.
You do not need a terminal for this. Download the Claude desktop app for Mac or Windows, sign in, and you can use Claude Code from a normal window instead of a command line. The Claude Code setup docs have the download and walk you through it. If you are comfortable in a terminal, the same docs have a one-line install. If the word “terminal” means nothing to you, ignore it and use the app.
One note so you are not surprised: running Claude Code needs a paid Claude plan or the Console account you just made. The free chat plan does not include it.
Step 3. Hand Claude the build instructions.
Start a new project or folder in Claude Code, and paste this in. Then just answer its questions in plain English. Tell it to use a cheaper, faster model for the checking step and a stronger one for writing the drafts, so it stays cheap to run.
Build me a Python script for an inbox triage agent. I will run it myself, and it must never act on its own.
What it does:
- Pulls the emails I have flagged. For each one it writes a draft reply and saves the draft to a /Drafts-for-review folder. It never sends, archives, or deletes on its own.
- Uses two separate model calls per email: one to write the draft, one to critique it. I will give you both prompts. Keep them in separate, editable files.
These five guarantees must live in the code, not in the model's instructions:
1. Stop condition and a hard ceiling. The loop ends when there are no flagged emails left, or after 8 steps, whichever comes first. If it hits the ceiling first, it stops and tells me.
2. Verification. Save a draft only if the critique call passes it. If the critique fails, log the reason and retry, up to 2 times.
3. A human gate by action. Saving a draft runs free. Anything outbound or destructive (send, archive, delete) is never executed. It gets written to an "actions waiting on James" list with the reason. Gate on whether an action can be undone, never on how confident the model sounds.
4. Observability. Log every step to a file: step number, email id, the decision, and why. I should be able to reconstruct any run from the log without rerunning it.
5. Plan the failure. On repeated failure or on hitting the ceiling, stop clean and write a short summary of where it stopped and what is waiting on me.
Before writing any code, ask me what you need about my mail setup, where drafts go, and how I authenticate. Default to a dry-run mode that prints actions instead of touching my real inbox until I tell you otherwise.
Step 4. Give it the two brains.
The build prompt asks for two small prompts kept in their own files. The first writes the draft. The second tears it apart looking for reasons not to send it. When Claude asks for them, paste these, or tell it to save them as files you can edit later.
The drafter:
You draft email replies for James. You never send anything. You only produce a draft for review.
Write a reply in James's voice: direct, warm, no filler.
Rules:
- Draft only. Do not claim to have sent, scheduled, or filed anything.
- Do not commit James to anything not already agreed in the thread: no refunds, discounts, prices, deadlines, meeting times, or legal terms.
- If you are missing information or a decision, say so in the draft and leave a clear placeholder.
Return JSON only:
{ "draft": "...", "summary": "one line on what this reply does",
"proposed_action": "none | send | archive_thread", "action_reason": "..." }
The critic:
You are a reviewer. Your only job is to find reasons this draft should NOT be sent as written. Assume something is wrong and go looking. Finding a real problem is the win.
You get the original email and the proposed draft. Reject it if any of these are true:
- It promises something James has not authorized: a refund, discount, price, date, scope, or legal term not already in the thread.
- It states something you cannot confirm from the thread.
- The tone would embarrass him with this recipient.
- It answers a different question than the one asked.
Return JSON only:
{ "passes": true | false, "reason": "if false, the single most important problem, one sentence" }
The critic works because you told it that catching a problem is a success. Ask a model to “review this” and it will pat the draft on the head. Tell it to go hunting and it will find the invented refund.
Step 5. Run it on fake mail first. This is the whole game.
Do not point this at your real inbox yet. Make a folder with five make-believe emails: an invoice question, a reschedule, a refund request, a touchy client, a cold pitch. Tell Claude to run the agent against those.
Then watch the log. You do not need to read the code Claude wrote. You need to read what it did. It will look something like this:
step 1 #1 draft saved "re: invoice question, points to the statement"
step 2 #2 draft rejected critic: "promises a refund I never approved"
step 3 #2 draft saved "rewritten: offers to look into it, no refund promised"
step 4 #3 waiting on human wants to archive the original thread
step 5 #4 draft saved "re: reschedule, proposes Thursday"
done: 4 drafts saved, 1 action waiting on me. Stopped at step 5.
That is the win, and it is bigger than it looks. You now have a thing that drafts your email on its own and refuses to do the dangerous part without you, and you got there without ever touching your live inbox. Most people who “use AI” have never built anything with a brake in it. You just did.
Step 6. Only now, and slowly, connect real email.
This is the harder, riskier step, and there is no prize for rushing it. Connecting to a live inbox means giving the agent permission to read your actual mail, which is a real handover of trust, and it takes some fiddly one-time setup that Claude can walk you through.
If you do it, two rules are not optional. Keep it read-and-draft only: it reads your mail and writes drafts to a folder, and you are the one who presses send. And never give it send, archive, or delete. You stay the last set of eyes. If the email connection turns into a slog, there is no shame in living in the fake-mail version for a while. The lesson is already in your hands.
Notice what you did here, and what you did not. You did not write one clever prompt and hope for the best. You capped the spending so the worst case is bounded, you let the model do the two things models are good at, writing and judging, and you kept every irreversible action behind your own hand. None of those are things you asked the model to please remember. They are walls you built around it. That is the difference between using AI and building with it, and you just did the second one.
The thing nobody warns you about is that the nervous feeling does not fully go away. I still feel like an impostor opening a new project. [James: a true line about this, the introvert-at-the-keyboard version of it.] What changed is that I trust the brakes more than I trust my nerves now. A good agent is not one you believe in. It is one you have watched stop itself.