Skip to main content

Silent Failure

The failure mode that kills trust in unattended agents: the agent thinks it finished, and it did not.

Hand-drawn ink-line illustration on terracotta: a cream vessel quietly tipped over with a thin ink line spilling out, a relaxed loopy hand resting nearby, a one-line profile face unaware beside it.

The problem it names​

A loud failure pages someone. A silent failure ships: the run ends green, the report goes out, and the mistake is discovered downstream by whoever it hurt. For agents doing real unattended work this is the trust problem, and the founders building those agents describe it in exactly those terms. Coasty, in YC's Summer 2026 batch, puts it in its launch material: "The problem isn't getting an agent to click. It's trusting it when a silent mistake gets someone fired." And sharper still: "An agent that thinks it finished but didn't is worse than one that fails loudly."

What it looks like in the published record​

  • Twilio's Feature Factory story contains the corpus's cleanest specimen. Mid-build, its author discovered "The MCP server... had been silently failing since the day it was configured." The cost: "thirty-five sessions of building and testing, all without the tool infrastructure the whole system was designed around." Everything appeared to work; the system had been routing around a dead dependency the entire time. (source)
  • Vambe's multi-agent sales platform lived the statistical version: "Previously, handoffs between agents failed 30% of the time. With Claude, reliability improved to over 95%, and the average number of agents per platform increased from 1.0 to 2.3." A 30 percent silent handoff loss is not an outage; it is a product quietly underperforming. (source)
  • Freedom Forever's permit agent surfaced the human baseline's own silent failures on arrival: "The agent found emails that had been sitting unprocessed for an average of three weeks." Silent failure predates agents; unattended agents just concentrate the risk. (source)

The engineering answers​

Anthropic's long-running-agents workshop material (cwc-long-running-agents) encodes the two structural defenses. First, a default-FAIL contract: a run counts as failed unless it affirmatively proves success, inverting the optimistic default that lets half-done work pass. Second, a fresh-context evaluator: completion is judged by a checker that did not do the work, because the worker's own context is contaminated by its belief that it finished. On Managed Agents, Outcomes is that second defense as a platform primitive, and one design goal of tool-error handling in agent harnesses cuts the other way: the loop retrying past errors is what keeps a run alive, and also what can paper over a dead tool, as the Twilio case shows. Instrumentation on tool success rates is the countermeasure.

Why it earns a concept page​

Because it reorders the engineering priorities. Teams default to chasing capability (can the agent do it?) when the adoption blocker is verification (do we know it did?). The corpus's most trusted unattended deployments lead with verification machinery: rubric graders, audit trails, human gates at the commit points. Trust is not a model property; it is an architecture.

Further Reading​