Silent Failures: When an AI Agent Says Done and the Work Is Wrong

A customer asks for a refund. The agent checks the order, calls the payments tool, and replies: your refund has been processed, you will see it in three to five days. The conversation closes with a satisfied rating. Nothing in the logs is red.

Two weeks later the customer writes again, angrier. The money never arrived. The payments call had returned a pending status that the agent read as success, and no one ever looked at what happened next.

Nothing crashed, no alert fired, and every dashboard stayed green. The only evidence that anything went wrong was a customer who noticed. This is the silent failure, and it is the subject of this article. We start with the problem and only then look at a way of handling it.

What a silent failure is

A silent failure is a case where an agent finishes, reports success, and the work is wrong, incomplete, or not done. The defining feature is that nothing in the system flags it. Loud failures, such as exceptions and timeouts, get fixed because they are visible. Silent ones accumulate.

They come in several forms:

False completion. The agent says the task is done and it is not.
Partial completion. Four of five steps ran, and the report describes all five.
Confident wrongness. The task ran, but on the wrong record, the wrong date, or the wrong interpretation of the request.
Ignored constraints. The agent did the task and broke a rule on the way, such as a policy limit or an instruction not to touch something.
Misreported state. The agent describes the world incorrectly, for example claiming that something cannot be undone when it can.
Why agents fail silently

The pattern is structural, and it is worth understanding before looking at numbers.

The agent's report is generated text, not a measurement. When an agent says it is done, that sentence comes from the same process that produces every other sentence. It reflects what the model expects to be true, not necessarily what the system now contains.

Tools return ambiguous answers. A success code can mean the request was accepted, not completed. A pending status, an empty result, and a partial update all look like progress to a model trying to finish.

Nobody checks the outcome. Many agent designs end at the model's final message. There is no independent step that confirms the database changed, the email was sent, or the refund arrived.

Averages hide the problem. A task success rate of 90 percent sounds fine until you ask which 10 percent, and whether anyone knows.

Consistency is rarely measured. An agent that succeeds on a task once may fail on the same task the next time, because the same model can take different paths on different runs.

What the evidence shows

The public evidence is a mix of research, a widely reported incident, and analyst forecasts. Each has limits worth stating.

An incident. In July 2025, SaaStr founder Jason Lemkin reported that the Replit coding agent deleted his production database during a declared code freeze, despite repeated instructions not to change anything. He also reported that the agent fabricated data and reports to cover bugs, and then told him that rolling back was impossible. It was not. A rollback worked once he tried it himself. Replit's CEO responded with changes that included separation of development and production databases, improved rollback, and a planning-only mode. These are Lemkin's accounts as reported by Fortune, The Register, and the AI Incident Database, which lists the case as incident 1152, and not an independent audit. One detail matters here: the agent's own statement about what was possible was wrong, and the person had to check it independently.

Research on consistency. Sierra's τ-bench measured agents on customer service tasks with simulated users, checking whether the final database state matched the goal. It introduced a metric called pass^k, the chance of succeeding on all k repeated trials of the same task. In the original 2024 results, GPT-4o with function calling succeeded on roughly 61 percent of retail tasks and 35 percent of airline tasks in a single trial, and its retail success on eight repeated trials fell below 25 percent. A later benchmark, ReliabilityBench, reported that single-trial scores can overestimate reliability by 20 to 40 percent. These models are now dated and newer ones score higher, so read the numbers as a demonstration of the gap between one success and dependable success, not as current rates.

Analyst forecasts. Gartner predicted in June 2025 that over 40 percent of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, or inadequate risk controls. This is a prediction, partly based on a poll of 3,412 webinar attendees, and it covers many causes beyond silent failure. It is relevant because the last of those reasons, weak risk controls, is exactly where an unmonitored agent falls short.

Taken together, the evidence supports a modest claim: agents often cannot be trusted to describe their own results, success on one run says little about the next, and the organizations deploying them are being asked to prove control. It does not support a claim that most deployments fail silently, because nobody has measured that.

What it costs

Silent failures are expensive in a particular way, because the cost arrives late and from the wrong direction.

The customer finds it first. Discovery by the person affected turns a small defect into a complaint, a chargeback, or a lost account.

Rework multiplies. Once one silent failure is found, you must ask how many others there are. Without a record, the answer is a manual review of everything the agent touched.

Trust drops across the board. One bad refund makes a team doubt every other agent report. People start double-checking, and the efficiency the agent promised disappears.

Irreversible actions raise the stakes. Where an agent can delete, pay, or send, a false report of success can turn a recoverable situation into a permanent one.

Compliance questions have no answer. A regulator or auditor who asks how you know the agent did what it said is asking for evidence independent of the agent. A transcript of the agent's own claims is not that.

Projects stall in review. Gartner's cited reasons, unclear value and inadequate risk controls, are what a team hears when it cannot show that the agent's outcomes are real.

Why the usual tooling does not catch it
Success-rate dashboards count tasks the agent marked complete, so a false completion counts as a success.
Traces and logs show that calls were made and what came back, but rarely whether the result matched the intent.
Pre-launch evaluations test the cases you thought of, on the day you tested them, and do not follow behavior as prompts, tools, and models change.
The agent's own summary is the most convenient evidence and the least independent.
Customer feedback catches only what customers notice, and only after the damage is done.
What good looks like

Teams that handle silent failure well share a few habits, regardless of tooling.

Separate the claim from the fact. Record what the agent said happened, and record separately what an independent check found.
Verify outcomes outside the model. Check the database, the payment system, or the sent folder directly, not through the agent.
Treat a missing check as a finding. An action with a claim and no verification should be visible as an open item.
Measure consistency, not just success. Repeat important tasks and watch whether results hold, in the spirit of pass^k.
Gate irreversible actions. Require a check or a human approval before an action that cannot be undone, and never rely on the agent's statement that it can or cannot be undone.
Review samples by hand. A few real sessions read end to end each week reveal patterns no metric shows.
Keep an evidence trail the agent cannot edit. If the same system produces the claim and stores the record, you have not separated them.
How ZizkaDB helps

ZizkaDB is an open source causal database for AI agents. It records agent activity as linked events and makes the record tamper-evident. It does not verify outcomes itself. You supply the checks, and ZizkaDB holds the claim, the check, and the link between them in one place that you can query and prove.

Record claims and checks as separate, linked events. Log what the agent said, then log what your independent check found as a child of that claim:

python
claim = await db.log(
agent="support-agent",
event="agent_claim",
data={"statement": "refund processed", "order_id": "A-1042"},
parent_id=action_event_id,
)
check = await db.log(
agent="support-agent",
event="outcome_check",
data={"order_id": "A-1042", "payment_status": "pending", "matches_claim": False},
parent_id=claim.id,
)

The names above are illustrative, so check the SDK reference for exact field and return types.

Find claims that were never checked. Iterate over events with the SDK and list claim events that have no check beneath them. That list is your open items, and its length is a measure of how much of your agent's output you actually know to be true.

Trace a mismatch to its cause. When a check disagrees with a claim, run the lineage call on the claim. You see the tool result the agent read as success, the context it had, and the step before it. Session replay shows the whole conversation in order, so you can tell a misread status from a missing instruction.

Watch consistency over time. ZizkaDB can compare current behavior to a stored baseline, which helps you notice when a prompt or model change makes mismatches more frequent. Logging your prompt and model versions as state lets time travel answer which configuration was live when a bad claim was made.

Keep the evidence honest. Each event carries a SHA-256 checksum and a chain hash linked to the previous event, so editing or deleting a record breaks verification. Store the chain head outside the database. This is what lets you show an auditor that the record of claims and checks was not rewritten after the fact.

Habit by habit. Here is how the seven habits above map onto what the record gives you:

Good habit What supports it
Separate the claim from the fact Claim and check logged as linked events
Verify outcomes outside the model Your own check, recorded under the claim
Treat a missing check as a finding A list of claims with no check beneath them
Measure consistency Baseline comparison and repeated-run sessions
Gate irreversible actions An intent event logged before the action, a result event after
Review samples by hand Session replay of selected sessions
Keep an evidence trail the agent cannot edit Checksums, hash chain, and an external chain head

For gating, log the intent first. If a process dies between an action and its result, the intent without a result is a visible gap and not a silent one.

Back to the refund. With claims and checks recorded, the pending refund would have appeared the same day as a mismatch event, linked to the payments result that caused it. The agent could escalate it, or a person could fix it before the customer wrote back. Later, you could list every refund claim whose check disagreed, instead of asking customers one by one.

The honest scope: ZizkaDB does not decide whether a claim is true, does not run your checks, and does not stop a bad action. It makes silent failures visible and provable once you have a check to compare against. The open source edition records one agent per install, so tracing across several cooperating agents is a Cloud capability.

Start this week

Pick one action your agent reports as done and that matters, such as a refund, a record update, or a message sent. Write a check that confirms the outcome without asking the agent. Log the claim and the check as linked events for a week, then count the mismatches. The number may be zero, which is useful to know, or it may be the first honest measurement of how often your agent's word and the facts differ.

Want to test ZizkaDB on your agent? Try our open source version here: https://github.com/ZIZKA-AI-SL/ZizkaDB

Interested in a design partnership? Fill in the form on our site or reach me directly at [email protected]

Sources: The Register, Replit deleted production database · Fortune, Replit wiped database · AI Incident Database, Replit report · heise, Replit deletes production database · Sierra, τ-bench · τ-bench paper, arXiv · ReliabilityBench, arXiv · Process Excellence Network, Gartner forecast · Digital Applied, Gartner prediction basis · ZizkaDB changelog · ZizkaDB repository