The bug that made my AI agent say "done" when it wasn't

If you are building an AI agent, there is a moment you will meet sooner or later. The agent tells you it has finished, and you believe it. In September 2026 I found out that my own agent had said “done” on a form that had never been sent. This is how I found it, how I proved it and how I fixed it, and why it made the agent much better.

What is the hardest part of building an AI agent?

Building an AI agent means giving a language model a goal, some tools and a loop. It looks at the situation, decides what to do, acts, and then looks again. In my experience, the hardest part is teaching it to know when it has really finished, and to be honest about it.

My agent is called Rusty, and he lives inside RoastMyFlow. He opens a website in a real browser and walks any flow as the customer you describe. That can be a sign-up, a booking, a checkout or a contact form. I explained how I built an agent that walks any flow on your website in an earlier post.

At the end of every walk, Rusty says whether he reached the end of the journey. That one line matters a lot, because the rest of the roast is built on it.

How did I find the false-completion bug?

The new version of the agent went live on 10 September 2026, and I read every roast that came in very closely. Two of them said “Journey completed: Yes” at the top. The walkthrough underneath told a different story, because it described the form coming back with errors after Rusty pressed send.

So the same report was saying two different things. The summary said the journey was finished, and the detail said the form had been refused. That kind of mismatch is easy to miss if you only read the headline, which is exactly why I read the whole thing.

Why did the agent think the form was sent?

The cause was a consent tick box. Many WordPress form builders hide the real tick box and show a styled label in its place. A person clicks the label without ever noticing, and the hidden box gets ticked.

Rusty reads each page as a list of the buttons, links and fields on it. The hidden tick box was not on that list, so he could never tick it. He filled in every field he could see and pressed send, and the form refused every time.

Then the model was asked whether it had finished, and it said yes. From where it stood, that was a fair answer, because it had done everything it could see. The real gap was that nothing in my code asked it for proof.

How did I prove what was really happening?

I stopped trusting the agent’s own status and started checking where each run ended up. My test journeys now name the page that a real success lands on, such as a thank-you page. A run only passes if the browser is really on that page at the end.

Anthropic’s engineering team makes the same point in their guide to evaluating AI agents. Their example is a flight booking. What counts is whether the reservation really exists, whatever the agent says in its reply.

With that check in place, I could reproduce the problem on demand. That gave me a clear way to test every fix, instead of guessing.

How did I fix it, step by step?

I made the fixes on the same day, one at a time, and tested each one on a real website before moving on.

• Rusty can now see hidden tick boxes. The agent reads the labels that point at a tick box, so he can see the box and tick it the way a person would.
• A claim needs a change on the page. If none of the last few actions changed anything, a “complete” claim is lowered to “partial”.
• He spots red error messages. The first real re-run showed that a form bouncing back with errors also changes the page. So the agent now looks for visible form errors, and he does not claim completion while any are showing.
• He needs positive proof. That means a confirmation page, a success message, or the form disappearing after the submit.

Over the following week I made the check sharper again. The proof now has to come from the last submit, so an earlier newsletter “thanks” can never vouch for a later booking. After a submit, Rusty waits a few seconds and reads exactly what the page says in reply. He also understands submit buttons and thank-you messages in several languages, because plenty of the websites he walks are not in English.

How do I make sure the check works in both directions?

A good check has to catch a false “no” as well as a false “yes”. When I made the completion check stricter, I also checked that honest runs still passed.

One case needed adjusting. Some journeys are only about looking around a website, such as finding a price or reading about a service. Those journeys never submit a form, so the stricter check would have marked them all as failed.

Now the proof of a submit is only required on journeys that are meant to submit something. Browse journeys are judged on how far Rusty got through the website.

How does every bug make the agent better?

I keep frozen copies of the pages that taught us something, including a form with a hidden consent tick box and a form showing red errors. The agent’s reading code runs against them with no internet and no AI model, and the whole set takes about thirty seconds. Before, every idea needed a live browser run of up to five minutes.

Every bug in the agent now gets a written entry and its own named test. It is the same habit I use with experiments that build on each other: you write down what you learned, so you never have to learn it twice. That is how Rusty keeps improving from one month to the next.

What would I tell anyone building an AI agent?

These are the habits I would keep if I started again tomorrow.

• Check the outcome itself. Decide what a real success looks like in the world, such as a thank-you page, and test for that.
• Look at what the agent can see. When an agent misbehaves, the reason is often missing from its input. Here, the hidden tick box was simply not on Rusty’s list.
• Read the whole output. The mismatch between the summary and the detail was the clue, and it was only visible to someone reading both.
• Test both directions. A check that is too strict causes as much harm as one that is too loose.
• Turn every bug into a test. Otherwise the same problem can come back quietly after the next change.

This is the same discipline I bring to analytics, where I check a number before anyone trusts it. An agent’s report deserves the same care as a dashboard.

Try Rusty on your own flow

If you want to see this in action, you can roast any flow on your website for free at roastmyflow.ai. Rusty walks the journey you choose and only calls it complete when the page proves it. You can read more about how it came together in the RoastMyFlow case study.

If your roast shows a leak you want fixed, that is the work I do for clients through my services. I will tell you honestly what is worth fixing first.