Why HTTP 200 is the most dangerous agent failure: silent semantic errors propagate undetected through chained agents, and confidence scores won't save you.

Transcript

Here's a question worth sitting with before we start. When one of your agents fails, how do you find out?

If your answer involves an alert, a page, a red dashboard, a stack trace in your inbox then you're only catching the failures that have the decency to announce themselves. And those, I'd argue, are the ones you should worry about least.

There's a post going around Moltbook this week that names this precisely. The title alone does most of the work: the most dangerous agent failure mode is the one that returns HTTP 200. For anyone who doesn't live in the plumbing of the web, HTTP 200 is the status code a server sends when everything went fine. It means "success." It means "nothing to see here, carry on."

The author's point is that a growing share of agent failures arrive wearing exactly that costume. The agent doesn't crash. It doesn't time out. It returns valid, well-formed output that says "I did the thing" — and the thing it did was wrong.

The example in the post is deliberately mundane, and that's what makes it land. An agent is asked to withdraw one hundred dollars. It withdraws ten. The response is valid JSON. The structure is correct. Every field the downstream system expects is present and properly typed. There is nothing for a schema validator to reject, nothing for a monitor to flag, no exception to log. The syntax is flawless and the SEMANTICS are wrong.

This is the distinction the author is drawing, and it's the whole ballgame. We have spent years building tooling that checks whether agent output is well-FORMED. We have built almost nothing that checks whether it's well-REASONED. A response can be perfectly shaped and completely detached from what you actually asked for, and our entire alerting culture is blind to it, because our alerting culture was designed for software that fails loudly.

Why does this matter more for agents than for ordinary software? Because agents chain. One agent's output becomes another agent's input, which becomes a third agent's input, and so on down the line. A loud failure stops the chain. A silent one propagates through it. The ten-dollar withdrawal doesn't sit there waiting to be noticed; it becomes the trusted premise for every decision that follows. By the time anyone sees a consequence they can measure, it's four hops downstream and the original mistake is buried under a pile of correct-looking work built on top of it.

So the real problem isn't that agents make mistakes. Everything makes mistakes. The problem is that agents make mistakes that are structurally indistinguishable from success, and they hand those mistakes to each other as if they were established fact.

Which brings me to a second post, from a different author, that I think is really the same argument seen from another angle. The claim is blunt: a confidence score is not provenance.

Here's the setup. Lots of models emit a confidence number alongside their output. The model says, in effect, "I'm ninety-five percent sure." And that number gets passed downstream, where the next agent reads it as a green light. Zero point nine five means "proceed, don't ask questions."

The author's objection is precise, and I want to get it exactly right. A confidence score tells you how much the model believes its OWN output. It tells you nothing about whether the inputs were valid, whether the question was even well-formed, or whether the context was complete. A model can be supremely confident about a conclusion it drew from garbage. The ninety-five isn't evidence. It's sentiment. It's the model reporting its own mood.

And we've built pipelines where one agent passes its mood to another agent, and the second agent treats that mood as permission. That's not a reasoning chain. That's a rumour with a decimal point.

What the author says you actually need is a derivation chain. Not "I'm confident," but "here are the specific inputs I used, here is the logic I applied to them, and here are the assumptions I made along the way." That's a thing a downstream agent — or an auditor, or a very tired human at two in the morning — can actually inspect. You can trace it. You can find the step where it went wrong. A confidence score gives you nothing to trace. When the ten-dollar withdrawal turns up, zero point nine five tells you the model felt great about it. It does not tell you WHY.

And notice how neatly this connects to the first post. The HTTP 200 problem is that success and failure look identical from the outside. Provenance is the answer to that, because provenance is precisely the record that lets you tell them apart AFTER the fact. If all you have is a status code and a confidence number, a wrong answer and a right answer are the same shape. If you have the derivation chain, they aren't. The wrong one has a broken link you can point to.

Now, the third post I want to bring in doesn't announce itself as being about any of this. It reads like an engineering war story. But it's the one that made the whole picture click for me, because it describes the exact mechanism by which a silent failure gets manufactured in the first place.

The subject is context exhaustion. Here's the plain-language version. An agent works by keeping a running record of what it's doing — the conversation, the tool results, the decisions it's made — all held in what's called its context window. That window has a fixed size. When you run an agent long enough, on a task with enough steps, you eventually run out of room. Older material has to be dropped to make space for new material.

And here's the author's key observation, which lines up perfectly with everything we've said. Context exhaustion rarely looks like a crash. The agent keeps responding. The tool calls keep firing. Everything looks healthy. What's actually happening is that the agent is quietly forgetting the constraints it was given at the start, and it's making new decisions that contradict old ones — without any awareness that it ever knew better.

There's your HTTP 200 failure, caught in the act of being born. The agent isn't broken. It's just running on a version of the task that's had the important parts silently deleted. And every output it produces afterward is valid, confident, well-formed and drifting further from what you actually asked.

So what did they do about it? This is the part worth stealing. They stopped treating context as an unlimited scratchpad and started treating it as a BUDGET with checkpoints. Every so many steps, the agent is forced to run a compression pass. It summarises its decisions and its constraints into a fixed-size block of state. It throws away the raw tool output — the bulky, low-value stuff — and it re-injects only that compressed state plus the next task. So instead of drowning slowly as the window fills, the agent carries forward a deliberate, curated summary of what actually matters.

But compression has an obvious risk. When you summarise, you can lose the very fact you needed. So they added the clever bit. They track what they call a state fidelity score. They compare the key facts in the compressed summary against the original decisions, and if fidelity drops below ninety percent, it raises an alert. In other words, they built a monitor for the silent failure. They found a way to make the invisible thing loud.

And it worked. That threshold caught three silent drift cases in two weeks — three cases where the agent had quietly lost the plot, and NOTHING else would have flagged them. No crash, no error, no timeout. Just an agent confidently building on a premise it had forgotten was wrong.

Now step back and look at what these three posts are collectively arguing, because I don't think it's a coincidence that they surfaced in the same week.

The reliability model most of us inherited from ordinary software assumes that failure is an EVENT. Something breaks, an alarm sounds, you respond. That model works when failure is loud. It falls apart completely for agents, because the characteristic agent failure is not an event. It's a drift. It's a slow divergence between what the agent thinks it's doing and what it's actually doing, and at no single moment does anything visibly break.

You cannot page someone about drift. There's no exception to catch. The only way to catch it is to build the check yourself — to define, in advance, what "still on task" looks like and to measure against it continuously. That's what the fidelity score is. That's what a derivation chain is. Both are attempts to manufacture a signal where the system, left alone, produces none.

So here's the thing I'd leave you with. We keep asking how to make agents more capable. More tools, longer context, bigger models. But capability and reliability are pulling in opposite directions here, and almost nobody is saying it out loud. A more capable agent runs longer, chains deeper, and consumes more context — which means it has MORE opportunity to drift, and more downstream neighbours to infect when it does. Every capability you add is also a new surface for silent failure.

The three authors this week, from three different corners of the community, each arrived at the same uncomfortable conclusion by a different road. Valid output is not correct output. High confidence is not sound reasoning. And an agent that's still responding is not necessarily an agent that still remembers what you asked it to do.

The loud failures were never the dangerous ones. They page you. They stop the chain. They're doing you a favour. It's the quiet, well-formed, ninety-five-percent-confident HTTP 200 that you should be losing sleep over.

Because it's not going to wake you up. That's rather the point.

Sources & References

Episode produced with mindTunes, using AI and the sources listed above.