You Don't Trust the Agent. You Trust the Loop.

The three-stage loop I run to make an agent reliable enough to put near my customers

A friend asked me this week how I get an agent reliable enough to trust what it produces. He builds too, so this was not idle curiosity. He had a few agents running well, but he wasn't ready to let any of them produce work he hadn't checked. Which is the right instinct.

He was working from the assumption almost everyone starts with, including me. Reliability is something you verify up front. You read the output, you decide it is good, and then you trust it. Like checking a spec sheet before you buy the part.

My answer was shorter than he expected. You don't. Not on day one.

Day one you should trust an agent about as much as you trust a new hire on their first morning. You would not hand a new hire the company card because the resume was strong. You watch them work. You correct them. A month later you trust their judgment, and the thing that changed was not the person. It was that you did the watching.

Trust is not a property the agent has. It is the output of a loop you run around it.

The loop is simple: run it, watch what it actually did, correct it, then feed that correction back into what it reads before the next run.

There are three stages. You do the first once, to set the target. The second and third are the loop. Let me show you with the one agent I would actually let near my customers.

Stage 1: write the first version

The first version is where you state what you want before the agent runs once. The objective. What good output looks like. The judgment calls you want locked in so the agent does not invent its own. Then you give it tools.

I write the agent itself as an AgentUse agent, a single file that holds its instructions, its schedule, and its tools. The authoring happens in Claude Code with the AgentUse skill, so I am describing the agent in plain language and the skill turns that into the actual config.

My customer support agent is a clean example. The objective is small on purpose: work a bounded batch of the support inbox, never the whole thing. Good output is a drafted reply, classified correctly. The judgment is written down in plain rules. Only the support mailbox. Three conversations per run, no more. Cold outreach gets archived. Anything about billing, a refund, a cancellation, or a complaint gets a draft, an internal note, and a tag that says a human needs to look. For tools I hand it a skill, the `helpscout-cs-agent` skill, which already knows how to read a conversation, check the customer's status, and apply an action. Most of what I give an agent now is skills. Sometimes I write a new one for the job.

Version one is a hypothesis, not a product. I wrote down what good looked like and let it run. I did not expect it to be right.

Stage 2: the supervised run

Then you watch. Not the summary it gives you at the end. The actual run.

I use two things in AgentUse for this. The session viewer, which replays exactly what the agent did and why, step by step, so I am reading its real reasoning instead of its final answer. And the approval gate, which stops the agent on any mutation and waits for my sign-off before anything touches the real world.

There are two ways to gate, and the support agent uses the stricter one. The most important line in it is this: never send replies, draft only. The agent is not allowed to do the one thing it cannot take back. A wrong refund answer to a real customer is real damage. Money, trust, and a person on the other end who now thinks we do not know our own policy. So the agent drafts. I read. It sends nothing on its own. For agents where I do want the action to happen but only with my eyes on it, I use the AgentUse approval gate instead, so the mutation runs the moment I approve and not before.

This is the part people skip. They wire an agent straight to the irreversible action, then act surprised when it does something irreversible. Gate the mutation. Let the agent propose. Keep the commit for yourself, at least until you have watched it enough.

Stage 3: tune the instructions

Based on what you saw, you go back and sharpen. Back to Claude Code and the AgentUse skill, editing the agent's instructions to close the gaps you just watched it fall into.

Here is the part I like. I built a second AgentUse agent whose only job is to learn. It runs on a schedule, every Sunday morning, reads the last seven days of replies that actually went out, the ones I edited before they sent, finds the patterns in how I changed them, and rewrites the knowledge base the drafting agent reads. My corrections do not live in my head. They become the instructions the next draft starts from.

That is what closes the loop. The agent drafts. I fix. A second agent turns my fixes into next week's starting point. Week over week the drafts need less editing, because the thing the agent reads before it drafts is shaped by every correction I have already made.

The next move tightens it further. AgentUse is adding learning to the approval gate itself, so instead of a weekly agent harvesting my corrections, the comment I leave when I review a draft teaches the agent the reason on the spot. Not "change this word" but "you keep being too stiff on cancellations, warm it up." The edit becomes a lesson the moment I make it, which folds stage 2 and stage 3 into one motion.

What the loop actually buys you

That is the whole method. Three stages: you do the first once to set the target, and the last two are the loop you run as many times as it takes. Though here is what surprises people: a single pass through the loop often produces something good enough to use. You are not trapped waiting for a broken thing to work. You are sharpening one that mostly works already, and most of the sharpening happens in the first few passes.

So when my friend asks how I trust the output, the honest answer is that I don't trust the output. I trust the loop that produces it. The agent on day one is a guess. The agent after ten passes is something I watched get better, with my own corrections baked into what it reads before it writes a word.

Trust was never something I granted the agent. It is the residue of the loop.

Build the loop first. The trust shows up on its own.