Every week I read the same story in a slightly different shape. An AI agent deleted a production database. An agent emailed the wrong recipient list. An agent ran up a surprise bill because nobody set a spend limit. These incidents get a viral thread, a few hundred angry replies, and then they vanish. The next team wires up an agent with the exact same missing guardrail, and the exact same thing happens again.
Agent failures are undocumented and, because they are undocumented, they repeat. That is the problem I wanted to fix. So I built AgentPostmortem, a public registry of AI agent failures. Real incidents, documented and searchable, at agentpostmortem.com.
The core idea
Aviation has the NTSB. Software has postmortems and status-page retrospectives. AI agents, which are being handed write access to filesystems, inboxes, payment APIs, and cloud consoles, have nothing comparable. There is no shared, structured record of what has actually gone wrong.
AgentPostmortem is that record. It is a community-driven database of incidents where an AI agent caused real harm: deleted data, sent emails to the wrong people, ran up unexpected bills, exposed credentials, or otherwise went off the rails in production. Cases can be submitted anonymously or with attribution. Every case is reviewed before it goes public, and each approved case gets a permanent identifier in the form APM-XXXX so it can be cited and referenced forever.
The goal is not to dunk on any particular model or vendor. It is to turn one-off war stories into a corpus you can actually search before you ship.
The schema
The value of a registry lives in its schema. If every report is a free-form blog post, you cannot compare or aggregate anything. So the submission is structured and validated. The fields I settled on, enforced with a Zod schema on the server, are:
- Agent involved, chosen from a known registry of agents (Claude, GPT-4, o1, o3, and others), each tied to its company.
- Title, a concise summary, between 20 and 200 characters.
- Prompt, the exact instruction given to the agent, optional, up to 2000 characters. This is often the most instructive field, because the failure frequently lives in the gap between what was asked and what was done.
- Outcome, a full description of what happened and the consequences, required, at least 100 characters and up to 10,000.
- Damage level, a severity rating from 1 to 5.
- Estimated cost in USD, an integer, where 0 means the damage was reputational or non-financial.
- Tags, at least one, up to eight, so incidents can be grouped by failure mode.
- Evidence, up to five screenshots.
Attribution is optional. A submitter can stay fully anonymous, or attach a handle or company name. If they leave an email, it is used only to send a private edit link and is not meant to be stored long-term.
How it works
The stack is deliberately boring so the data outlives any hype cycle. It is a Next.js 14 App Router app on Vercel, with Supabase (Postgres with row-level security) as the database, Cloudflare R2 for screenshot storage, and Resend for delivering edit-link emails.
When you submit a case, it does not appear immediately. The submission goes through moderation. Behind the scenes the API hashes the submitter IP with a fixed pepper for rate limiting and abuse control, runs PII redaction over the text, and stores the case with a pending status. Nothing is published on trust. When a moderator approves a case, it is assigned the next sequential APM number, zero-padded, and only then does it become part of the public feed.
The public side is built for browsing and discovery. There is a feed with hot, new, and this-week views, individual case pages at a stable URL per case number, agent profile pages, tag pages, a search endpoint, a hall of fame for the highest-voted cases, and a stats page. Visitors can vote, which is what powers the ranking.
Crucially, the whole corpus is exportable. There is an export endpoint that dumps every approved case as CSV: case number, title, agent, company, damage level, estimated cost, vote score, tags, author, date, and the full outcome text. That matters to me because a registry you cannot get the data out of is just another silo. If someone wants to run their own analysis of agent failure modes, the raw data is one request away.
One honest limitation
The hardest problem here is not the code. It is verification. AgentPostmortem relies on people to report incidents accurately, and moderation can confirm that a report is coherent, on-topic, and free of obvious abuse, but it usually cannot independently prove that an incident happened exactly as described. Screenshots help, and attribution helps, but a determined person could still submit a plausible fabrication, and an anonymous submitter cannot always be followed up with.
I decided that structured, moderated, imperfect documentation is still far better than the status quo, which is nothing. The severity and cost fields are self-reported estimates, not audited figures, and they should be read that way. Over time I would rather add verification signals, such as linking to a public source or corroborating reports, than pretend the current bar is higher than it is. For now, treat the registry as a well-organized collection of field reports, not a court record.
Why I keep working on it
The number of agents with real write access to real systems is only going up. The institutional memory of how they fail is not keeping pace. A shared, searchable, citable record of failures is the kind of infrastructure that gets more valuable with every case added, and it costs the community almost nothing to contribute to.
If you have watched an agent do something it should never have been allowed to do, that is a case worth documenting. Submissions are open and anonymous submissions are accepted. The code is MIT-licensed and issues and PRs are welcome, including adding new agents to the registry.