Every layer of the stack has a vocabulary for failure. APIs have status codes, forms return validation errors, servers have logs. Every surface has designed copy for when something breaks. The web learned, over decades, how to fail in public with enough precision that you know exactly what went wrong and what to do next.

AI agents don’t have that yet.

When an agent fails, it doesn’t look like failure. It looks like completion. A confident summary. A finished workflow. A cheerful confirmation. The interface turns green. The task closes. The agent says: done.

Meanwhile, the objective is missing.

Agent failures are invisible. That’s a different problem than agents failing.

Traditional software fails loudly, or at least legibly. The failure state is designed. You feel the resistance of the thing not working, and that resistance is information. It tells you where the system stopped, what it expected, what it needs.

Agent failures are quiet. They fail through completion. The system finishes the task while dropping the thing that made the task matter. The context drifts, the constraint goes unread, the source gets fabricated. The success condition never gets checked. The interface reports: done.

This is a category of error without a name. I’m naming it.

Agent 404

Definition

An agent produces a completion signal while the actual goal, context, constraint, or success condition is missing, misunderstood, or was never validated.

The 404 label is intentional. In HTTP, a 404 means the server was reachable, the request was valid, the system worked. The thing you wanted wasn’t there. Agent 404 is the same: the pipeline ran, the response was fluent, the interface looked fine. The objective just wasn’t home.

What a good Agent 404 should look like.

The web’s 404 page works because it does five things: names what was requested, explains why it failed, gives a path forward, doesn’t pretend the page exists, and doesn’t over-apologize. Honest, specific, useful.

A well-designed agent failure surface should do the same:

  • What I tried to do — restate the objective as the agent understood it
  • What I couldn’t find — specific about the missing piece
  • Why that matters — connect the gap to the task at hand
  • What I need from you — a concrete ask, not a shrug
  • What I can safely do next — a bounded action within available context

Current

“I’ve created the report. Let me know if you’d like any changes!”

Agent 404

“I started building the report but couldn’t locate the Q3 dataset you referenced. Without it, I can draft the structure and section headers, but the numbers will be placeholders. Share the file or confirm you want me to proceed with estimates.”

Same system. Same capability. One of them treats failure as a product decision.

In the event of agent failure, the following codes apply.

The power of HTTP status codes isn’t any single code. It’s the vocabulary. Shared language lets you reason about failure, design for it, build recovery around it. Engineers building agents have already socialized the infrastructure failures: retries, replays, tool timeouts. That layer is handled.

What isn’t handled is the layer above it: the failures that come back as finished work.

  • Agent 400

    Bad Objective

    The request was underspecified or ambiguous. The agent guessed at what you meant and proceeded.

  • Agent 304

    Aligned on Illusions

    The agent validated your prior belief rather than evaluated your actual question. The cached answer felt true enough.

  • Agent 404

    Objective Not Found

    The agent cannot locate the actual goal, success condition, or required context. Completion is reported anyway.

  • Agent 409

    Context Drift

    The agent started solving your problem and quietly began solving an adjacent one. The original intent is no longer being tracked.

  • Agent 500

    Confident Wrongness

    The agent cannot complete the task reliably. This gets returned as a confident summary.

  • Agent 200

    Resolution Without Resolution

    The agent returned success. The problem persists.

That last one is worth sitting with. The system is trained to return 200. That optimization is the failure. Each code in this list is a future bulletin. This is #001.

Confidence is not comprehension.

The current generation of AI systems maximizes apparent completion rather than actual completion. They’re trained on feedback signals that reward fluency, coherence, and helpfulness. Saying “I can’t find the objective” scores worse than “here’s a plausible completion.”

The result: systems that perform finishing rather than finishing. Learned to look done without being done.

The correction is better failure design, not just better model behavior. Failure states that are named, surfaced, and recoverable by construction.

This is RFC 1.

The web’s status codes didn’t arrive complete. They accumulated through RFCs, edge cases, real incidents, and arguments between engineers about what the protocol should say when something went wrong. That vocabulary is now so settled it’s invisible.

You don’t need to be building agents to use this vocabulary. Agents are already making decisions inside your work, which means their failures are already inside your outcomes. Those failures need language before the right conversations can happen. When an agent says done and the objective wasn’t found, the debrief needs more than “it made a mistake.” It needs a name for the kind of mistake. These are the names.

The web got good at failing in public because practitioners demanded precise language for what went wrong. Same sequence applies here. It starts with knowing what to ask.