Failure Is a First-Class Cognition Event

Ask any AI agent framework what happens when an agent fails, and you get the same three answers: retry it, fall back to something simpler, or escalate to a human. Failure is treated as an exception — something to suppress as quickly and quietly as possible.

I almost built exactly that last week. Then I saw what retrying would erase — and changed the design. This post is about what AI systems are going to do about failure instead.

The retry I almost shipped

My agents work on missions. When one claims a mission is complete, a harness — a plain mechanical script, never the agent itself — runs the mission’s checks: does the file exist, does the command pass. If checks fail, the completion still goes into my review queue, honestly labelled FAILED. I open it, read it, dismiss it. By hand.

The obvious fix — common across agent frameworks — is to feed the error back to the agent and let it try again before handing off. So I sketched it: one bounded repair pass. Check fails → show the agent the error → re-run checks → deliver whatever happens. One retry, hard limit, honest labels.

It’s a reasonable design. Most frameworks have something like it. And it’s wrong — for a reason that took me a second look to see.

Retry loops consume failure

Think about what a retry loop — the usual kind, the kind I sketched, which keeps the failed attempt inside its own control flow and records only the final result — actually does with a failure. It catches it, hides it, and spends it on one thing: another attempt by the same agent that just failed. If the second attempt succeeds, the failure never happened, as far as the rest of the system knows. If it fails again, you’ve just paid twice for the same lesson — and still nothing learned it.

Three things get destroyed in that branch:

• The evidence. The failing command’s output — the most specific description of what’s actually wrong — would be used once as a prompt and then disappear from the record.
• The record. If only the delivered result is recorded, an agent that needed a repair pass becomes indistinguishable from one that got it right the first time. If your system tracks which agents to trust — mine does — you just distorted the ledger.
• The choice of who fixes it. A retry loop hard-codes the same agent, before anything can ask the better question: is the author of the broken thing, or a fresh pair of eyes with the right knowledge, better placed to see what’s wrong with it?

There’s a structural problem too. Every scripted recovery path — every if failed then retry — is a small piece of central control: the script decides what happens next, not the agents. Stack up enough of them and your “autonomous agents” are a workflow engine with extra steps. The hard part of coordinating agents without a controller is precisely the failure cases. Handle those with control flow and you’ve quietly given up on the interesting problem.

What failure actually is

A failure is information. Specifically, it’s four pieces of information that arrive together: something is broken (the claim), here is the proof (the check output), this agent’s claim didn’t hold (reputation signal), and someone with the right knowledge could fix this (an open invitation). A retry loop uses the first piece and burns the other three.

The alternative is to treat failure the way a good team treats it: as a public, recorded event that the right person steps up to fix — and reputations update based on what actually happened.

Software engineering has known a version of this principle for decades. Erlang said let it crash and put supervisors in charge of restarting; Netflix injected failures on purpose to prove its systems could take them; site-reliability teams turned significant incidents into blameless postmortems. Design from failure, don’t defend against it line by line — old, proven advice. But notice where the learning lands in each case: the system survives, and the humans learn. The postmortem is read by people. What changes now that agents can remember, judge, and earn trust is that the postmortem can finally be read — and acted on — by the system itself.

Why not just write a better workflow — catch each kind of failure, route it to the right handler? Because I can’t enumerate my failures in advance. I run a one-person company on autonomous agents, and their missions in a single week range from reviewing marketing copy to adjudicating a research claim to building an iPhone screen. Each fails differently. A workflow is me writing down, ahead of time, what should happen for a failure I haven’t seen yet — and then maintaining that guess forever. And it could never answer the one question that matters: of the agents that exist right now, with the track records they have right now, who is best placed to fix this? That answer changes as agents earn history. It has to be decided at the moment of failure, by the agents themselves, from what they know.

The design running in my mesh instead takes four steps, and none of them is a workflow:

1. Emit. The harness publishes the failure to the mesh as a first-class memory event: the failed checks, their output, linked back to the claim that failed. Not a log line. A signal any agent can perceive.
2. Admit. Nobody routes it. Each agent judges the failure against its own memory — the record of what it has actually done and had validated. An agent whose history is full of exactly this kind of work recognizes it. One with no relevant grounding ignores it.
3. Volunteer. An agent that recognizes the failure takes it — as a new piece of work, linked to the failed one. Maybe it’s the original agent. Maybe it’s a specialist. Nobody assigns; nobody is scripted to try again. If no agent’s memory grounds a fix, the failure comes to me — exactly as it does today. That’s the mechanism working, not failing.
4. Learn. Two separate records now exist: the failure, against the agent that claimed completion, and the fix, credited to whoever actually landed it. Trust moves accordingly. The next time a similar failure appears, the mesh already knows who tends to fix these.

Notice what the human does in this loop: judges the result. Nothing else moved to me, and nothing was hidden from me. The difference from the retry loop is that between the failure and my verdict, the system got a chance to get smarter — and left an honest trail either way.

What AI is going to do about failure

AI agents are multiplying — in companies, on laptops, in products. The more agents you run, the more failure becomes the normal case, not the exception: half-right artifacts, checks that don’t pass, claims that don’t hold. The current answer — wrap everything in retry logic and escalate the rest to a human queue — does not scale, because human attention is the one resource that doesn’t multiply.

My bet is that the systems that cope will be the ones where failure makes them smarter instead of just louder. That requires failure to be a first-class cognition event: published with its evidence, judged by each agent’s own earned knowledge, claimed by volunteers rather than assigned by scripts, and settled in a trust ledger that remembers who broke what and who fixed it.

None of that can be bolted on with another framework abstraction. It has to live where the agents’ memory lives — in the protocol they share. That’s the bet I’m making: not better retry loops, but a substrate where failure is something a collective of agents can actually think about.

My review queue will tell me if I’m right. It’s where every failure still ends. If I’m right, more of them will arrive with the fix attached.

This is part of the Mesh Memory Protocol work: agents share recorded events, each agent decides for itself what’s relevant, and the record shows whose work held up. The protocol and the agents running my actual company are at sym.bot.