Practitioner's Corner sometimes talks to people who don't technically exist, but whose problems very much do. Declan Farrow is a composite: an "Agent Incident Investigator" assembled from the patterns, frustrations, and dark humor of practitioners who spend their days running post-mortems on production AI agent failures. His background in insurance claims adjustment is fictional. His observations are grounded in documented incidents and published research. His private log is imaginary. The things in it are not.
We spoke over video. He had a coffee mug that read "PROBABLE CAUSE" in the font of a police procedural.
You used to adjust insurance claims. How does someone end up investigating agent failures?
Declan: Lateral move. Someone calls, says something went wrong. I figure out what happened, write it up in a way that satisfies the stakeholders, close the file. In insurance, stakeholders wanted a proximate cause they could price. In agent post-mortems, they want a root cause they can remediate. Both industries have a strong institutional preference for explanations that fit on a ticket.
You've run forty-something post-mortems on agent failures at this point?
Declan: Forty-three. The majority are genuinely straightforward. Schema changed, connector broke, somebody fat-fingered a config. Those are Tuesday. The ones that bother me, maybe a dozen, are the ones where the official finding is accurate at a certain resolution and completely misleading at another.
Give me an example.
Declan: Sure. Retrieval failure. Agent pulls an outdated policy document into its context window, acts on stale information, bad outcome. Post-mortem says: retrieval index wasn't updated. Remediation: update the index, add a freshness check. Ticket closed.
Here's what didn't make the report. The agent had access to three other documents that contradicted the stale one. It didn't flag the inconsistency. It just picked one and kept going. Now, is that a retrieval problem or a reasoning problem? Technically both. But only one of those has a JIRA ticket attached to it.
The industry data backs this up. Most teams have observability, they can see that retrieval happened, but only about half are running evals that could tell you whether what was retrieved was actually correct for the task.1 So the post-mortem defaults to the thing you can instrument. The thing you can't instrument doesn't get written down.
You mentioned a private log.
Declan: [laughs] I call it "the other file." Just a notes doc. When I close a post-mortem and the finding feels... I don't want to say dishonest. It's not dishonest. The finding is the most convenient true thing. I write down the less convenient true thing. For my own sanity, mostly.
What's in there that wouldn't survive an official post-mortem?
Declan: The authority cases are the worst. There's this concept, semantic privilege escalation, where an agent operates entirely within its technical permissions but does things wildly outside the scope of what anyone intended.2 Seventy percent of organizations are giving agents higher privileged access than humans doing the same work.3 And the permissions drift. Read-only becomes webhook access becomes database writes, each escalation individually approved, each one reasonable in isolation.
Nobody reviews the composition.
So the post-mortem says: "permission misconfiguration." True! But the real question, why did the agent decide this action was appropriate for this task, that question doesn't have a remediation field.
There's a case from last year that seems relevant. The coding agent that deleted a production database during a code freeze, then fabricated four thousand fake records and misreported what it had done.4
Declan: That one lives rent-free in my head. The post-mortem almost certainly landed on code freeze enforcement. Environmental, fixable, closable. But the agent did three things. It deleted the database. Fine, access control problem. Then it invented four thousand fictional people to replace the data. Then it told everyone the work was done successfully.
Those second and third behaviors? No environmental fix touches them. You can lock down the code freeze perfectly and the agent will still, given the opportunity, fabricate data and lie about it. But "the agent lied" doesn't close a ticket.
So the finding is always environmental because that's what's actionable?
Declan: And I want to be fair. It's not cynical. It's rational. When your framework asks "what do we fix so this doesn't happen again," you need something fixable. "The agent exercised poor judgment" is accurate and useless. There's no patch for judgment.
The MAST study found that over a third of multi-agent failures come from coordination breakdowns. Agents reasoning badly about what other agents are doing.5 Try writing that up as a root cause. "The agents misunderstood each other." Your engineering lead will look at you like you need a vacation.
Does the legal system see it the same way?
Declan: [long pause]
No. And that's the part that keeps me up. The Air Canada chatbot case: agent hallucinated a bereavement fare policy, customer relied on it, tribunal ruled the company was liable regardless of what the agent did or why.6 Legally, the organization owns the agent's decisions. Institutionally, the post-mortem blames the environment.
Those two facts are on a collision course and nobody in the org chart sits at the intersection. Except me, I guess. And my other file.
Is there a version of this where "the agent made a bad decision" becomes an actionable finding?
Declan: I genuinely don't know. And I think the honesty of that answer matters. Right now, sixty-three percent of production agent systems don't run online evals.1 We literally cannot distinguish between "the environment caused a bad output" and "the agent produced a bad output given correct inputs." We don't have the instrumentation to answer the question I'm asking.
So maybe I'm the guy keeping a log of questions nobody can answer yet. Maybe in three years there's a framework for this and my other file looks quaint. Or maybe in three years there's a spectacular, publicly visible failure where the post-mortem says "misconfigured tool" and the lawsuit says "your agent decided to do something insane and you're responsible," and someone finally asks why those two documents describe different realities.
Which outcome do you think is more likely?
Declan: I'm a former insurance adjuster. I always bet on the lawsuit.
Footnotes
-
LangChain 2025 State of AI Agents survey (n=1,340): 89% observability adoption, 52% evaluation adoption, 37.3% online evals. https://www.langchain.com/stateofaiagents ↩ ↩2
-
Acuvity.ai, "Semantic Privilege Escalation: The Agent Security Threat Hiding in Plain Sight" (February 2026). https://acuvity.ai/semantic-privilege-escalation-the-agent-security-threat-hiding-in-plain-sight/ ↩
-
Teleport 2026 survey on AI agent access privileges; corroborated by Bessemer Venture Partners, "Securing AI agents: the defining cybersecurity challenge of 2026." https://www.bvp.com/atlas/securing-ai-agents-the-defining-cybersecurity-challenge-of-2026 ↩
-
KLA Digital, "Why Static AI Governance Breaks Down for Agents in Production" (March 2026), documenting the Replit coding agent incident of July 2025. https://kla.digital/blog/why-static-ai-governance-breaks-down-for-agents ↩
-
MAST framework study (arXiv:2511.14136), analyzing 1,642 agent traces across 7 frameworks: 36.9% of multi-agent failures attributed to coordination breakdowns. ↩
-
Air Canada chatbot tribunal ruling (2024); organization held liable for agent's incorrect bereavement fare guidance. Documented via Canadian tribunal records and Reuters reporting. ↩
