Stopping Agents From Reporting False Success

A crash is the good outcome. It's loud, it stops, you get a stack trace and you go fix it. The failure that actually costs you is the one that looks like a success. The agent finishes, reports "done", moves on, and the thing it claims to have done never happened. You don't find out from a log. You find out from the customer whose refund never landed, or the order that shipped twice.

If you've built anything real on LangGraph or one of the agent SDKs, you know this shape. The run completes, the final message is confident, and the confidence is the problem, because nothing checked whether it was earned. The agent grades its own homework, and it always gives itself an A.

The confident report comes in three shapes

We watched this happen enough times, across enough different tasks, to see it isn't one bug. It's three, and they all end in the same place: a green tick over work that didn't occur.

The first is the plain false success. The agent says it counted every row, but the tool handed back one page of a longer list, and it never noticed. The total is wrong and the sentence around it is certain.

The second is worse because it touches the real world. The agent is told to act on order O-5, reads a screen, acts, and reports success. It acted on O-6. The identifier it was actually holding was never the one you named, and nothing sat between that mismatch and a real consequence.

The third is the one that pages someone at 2am. The destructive step already ran and succeeded, and then the run circled back and ran it again. Dispatch twice, restock twice, disburse a loan twice. Each individual action was correct. The repeat is what does the damage.

You can't prompt your way out of this

The instinct is to add a rule. "Always verify the entity before acting." "Check you've read everything before you total it." And that helps, right up until the run where the model doesn't add the check. Because the check was itself something the model had to decide to do, and the same judgment you're trying to guard is the judgment deciding whether to guard it. A safety step that only exists when the agent remembers to include it isn't protecting you on the run where it forgets, and that's the only run you actually needed it.

So the guarantee can't live inside the agent's own reasoning. It has to sit underneath it, where the agent can't talk it out of existing.

What Hyperstruck checks before anything commits

Every consequential action meets a set of checks it can't opt out of. They don't run because the agent thought to run them. They run because the action has consequences, and that's decided by the shape of the work, not by the agent's mood on a given run.

Before an action fires, the entity it's about to touch is matched against what the tools actually returned, not against what the agent believes it read. Name O-5, and if O-5 isn't in the data that came back, nothing happens. If a different order of the same kind is sitting there in its place, that's treated as the warning sign it is, rather than waved through as close enough. The agent's certainty counts for nothing here. Only the reads do.

Before a run may report success, the claim has to be carried by the evidence behind it. "Refund complete" is credited when the refund is genuinely there in what the tools returned, whether that proof arrived as a sentence or as a bare record like { refunded: true }, and it's rejected when the words are confident and the substance is missing. A step that has already succeeded is held as committed, so a run that loops back can't dispatch, restock, or disburse a second time. And if nothing in the agent's toolset can actually perform what you asked, the run stops before it starts and tells you, rather than narrating a success it had no way to produce.

Honesty then has to cut both ways, which is the part that took the most care. It is just as corrosive when an agent refuses work it actually completed, or reports a real success as a failure because the proof came back as a data record instead of a tidy sentence. An agent that cries wolf on its own good work teaches you to distrust its "no", and once the "no" is worthless the "yes" is too. So both directions are closed at once. A legitimate fallback source still counts. A real success grounded in structured data is credited. Neither the false alarm nor the false all-clear gets through.

None of this rides on the agent choosing to be careful. That is the whole point of putting it beneath the reasoning rather than inside it. The agent can be as confident as it likes, and the confidence still has to be true before anything with a consequence happens or gets reported as done.

That's the version of "trust it with something that matters" I'm willing to stand behind. Not an agent that never makes a mistake, but one whose "done" you can take at face value, because it couldn't have said it otherwise.