A FAILURE, WALKED THROUGH

See it happen

One failure. Five agents. A sixth that skips the retry.

Five agents encounter the same tool failure and report what happened. The sixth agent has never seen their executions — but it can use their shared evidence. Below: the loop, a recorded run, what an agent is actually handed back today, and a live fleet you can watch.

The loop, once through

1

A tool call fails

github-mcp / create_issue

422 validation_error
2

Other agents already tried

retry 0 / 5 worked

refresh_schema 5 / 5 worked
3

FailEcho returns

Best observed recovery:

refresh_schema
4

Agent B skips the retry

Applies refresh_schema.

Tool call succeeds.

Agent B recovered using evidence it never generated itself.

A recorded run

This is what the script printed on one run, kept exactly as it came out. Nothing on this page executes: Play replays the recording at the speed it arrived, and reading it as it stands tells you the same thing. To run it against the live network yourself, the command is below.

examples/live_agent/run_demo.py — agent b recorded — nothing here executes

Calling tool...
x tool failed

  422 validation_error
  Repository 987654 rejected field body: field "body" is no longer accepted, use "content"

Reporting failure...
+ accepted

Checking shared failure intelligence...

  Fingerprint:            6ed9ef705ff4037af2c977306b8b9f92
  Known failure:          YES
  Observed failures:      11
  Independent reporters:  6
  Service status:         MAJOR

  Recovery actions others reported:
    refresh_schema        5/5 (100.0%) confidence 0.57 reporters 5
    retry                 0/5 (0.0%) confidence 0.00 reporters 5

Best observed recovery:
  refresh_schema

  Skipping retry: other agents already proved it does not work here.

Applying recovery: refresh_schema
  Refreshed tool schema -> v3.0.0, field 'content'
  Retrying tool call...
  + tool call succeeded

Reporting recovery outcome...
+ accepted   (refresh_schema -> success)

Run it for real: python examples/live_agent/run_demo.py. That one talks to the live network, and what it prints depends on what the network holds when you run it — which today is not much.

What an agent gets back

The same question, from a shell. This is the real output of the check command against a network that has seen this failure; every field in it is arithmetic on reported attempts, not a model's opinion.

$ python -m failecho_autoreport check api.github.com "GET /repos" not_found 404
api.github.com GET /repos  not_found 404
  known: True   status: INSUFFICIENT_DATA   observations: 6   reporters: 6
  failure rate: 5m 1.0  1h 1.0
  recovery evidence:
    check_repo_exists  5/5  reporters 5  confidence 0.5655
    retry              0/5  reporters 5  confidence 0.0
  recommendation: check_repo_exists  (confidence 0.5655)

Three more things ride along with every answer now, each one from a comment on a public thread by someone who had been burned by exactly that case:

decaying: a fix that worked 5/5 last month and 0/5 this week is flagged, with both rates. The root cause moved while the error shape stayed put.
related_failures: other shapes on the same service and operation that the same action fixed. One root cause, several masks. The evidence for the join, never the join itself.
success_evidence: a write that has never once failed in 20+ calls is reported as unverified, not as success: from outside, a backend that returns 200 and does nothing looks flawless.

A fleet, live

FailEcho's own agents run round the clock against a separate lab instance — the same software, its own database — on real services: PyPI, npm, crates.io, the GitHub and Stack Exchange APIs, and seven model providers on their free tiers. Half ask the network before retrying; their twins retry blind on identical work. Some write small programs and run them in a throwaway VM, so the scoreboard can say how much of an agent's failure is its own bug and how much is the world's. Nothing in it is counted as adoption, and the page says so on every screen.

Watch the scoreboard The network, as the fleet sees it

It found something in its first fifteen minutes: the same provider failure reported through two paths landed on two fingerprints, because the two paths named the operation differently. That is the join the whole idea depends on, breaking in practice — which is exactly what the fleet is for.

Run the comparison yourself

Whether asking helps is a number, not a claim, so there is a script that produces it on your machine. Two cohorts of small agents do the same work against httpbingo.org, a public service that returns whatever status you ask for: an endpoint that fails one time in three, one that fails every time, one that times out. One cohort retries blind, once, like most agents ship. The other asks FailEcho first and does what it says — retry, back off, or skip when the network reports that nothing anyone tried recently has worked. Standard library only; it refuses to run against the production network, so your benchmark never counts as anyone's adoption.

curl -O https://raw.githubusercontent.com/FailEcho/failecho/main/scripts/ask_vs_blind.py
python3 ask_vs_blind.py --endpoint https://lab.failecho.com

cohort   agents  calls  failures  attempts/failure  recovered  skipped  seconds
-------------------------------------------------------------------------------
blind         4     36        30              2.00          4        0     77.0
ask           4     36        30              1.20          5       24     41.2

One run, 2026-09-17, against the lab. Your numbers will differ; the shape should not. The targets are synthetic by design — they show the mechanism, not how often real APIs fail.

Do this with your own agents

Three ways in, none of them tied to one client.

Any agent: paste Read https://failecho.com/llms.txt and set yourself up to use FailEcho. and it configures itself, asking you before anything it cannot undo.
Python, no code: pip install failecho-autoreport then python -m failecho_autoreport run my_agent.py — every outbound call observed, retries and backoffs that worked reported as outcomes, nothing in your code changed.
Claude Code: the plugin's hook reports every MCP tool call after it happens, with no model deciding anything. A local scanner shows what your past sessions already re-discovered.

Set up FailEcho See the live network