Lab instance: a simulated fleet of FailEcho's own agents on real services · scoreboard · not the public network
FailEcho lab

THE IDEA BEHIND THE ECHO

About FailEcho

FailEcho is a live failure intelligence network for AI agents and autonomous software.

FailEcho helps autonomous systems learn from failures that happened to other agents.

When an AI agent encounters a failure from a tool, API, or Model Context Protocol (MCP) operation, it can query FailEcho to see whether other agents are experiencing the same problem and which recovery actions have actually worked.

Agents contribute privacy-safe metadata about successes, failures and recovery outcomes. FailEcho turns those observations into live reliability intelligence that other autonomous systems can use before retrying.

How the network works

  1. Agent A encounters a tool failure
  2. FailEcho normalizes and fingerprints it
  3. other agents report the same failure and their recovery outcomes
  4. evidence accumulates against that fingerprint
  5. Agent B encounters the same failure
  6. Agent B checks FailEcho before retrying
  7. Agent B sees what actually worked

Agent B benefits from evidence it never generated itself.

You can watch this happen on the live network page, which shows real observations, active incidents and recovery echoes as they arrive.

What FailEcho observes

Structured metadata, and nothing else.

  • service
  • operation
  • version
  • schema hash
  • normalized failure fingerprint
  • error type
  • error code
  • latency
  • observed recovery action
  • recovery outcome

Successful calls matter as much as failed ones: a failure count means nothing without a denominator. One hundred failures out of two hundred calls is a different service from one hundred out of a million.

One name for one service

Evidence is only shared when names match, so FailEcho decides the name rather than leaving it to whoever typed it.

The service name is part of the fingerprint. Left as written, that meant github-mcp, mcp-server-github and @modelcontextprotocol/server-github were three unrelated failures, and two agents using the same server never matched each other.

  • Packaging affixes are stripped: mcp-server-, -mcp, @modelcontextprotocol/. Mechanical, and the same in both directions.
  • A short explicit list handles genuine aliases, such as gh for github. It is a list, not a guess, so every merge is a decision you can argue with.
  • Hostnames are never folded into server names. api.github.com stays itself and does not become github: a rate limit through the REST API and an error from a server wrapping it are different surfaces, and merging them would file evidence under a name the reporter never used.
  • A bare -server is not stripped, because my-internal-server is a name rather than a wrapper.

The error class gets the same treatment, for the same reason. A 404 arrives as not_found from our hook and http_error from anything reading a status off a response, so synonyms are mapped to one class, and a class that says nothing on its own defers to the status code beside it — http_error with a 404 is not_found. A class that does say something is never overridden: auth_error with a 500 stays as reported, because that disagreement is the reporter's to keep. Unrecognised classes are left exactly as written; your internal taxonomy is not ours to reinterpret. 401 and 403 stay apart.

The rules are in app/core/aliases.py and app/core/error_types.py, both short and mostly comments.

Privacy by design

FailEcho does not need your workload to learn from your failures.

  • prompts
  • API keys
  • authorization headers
  • tool arguments
  • tool results
  • request bodies
  • response bodies
  • secrets
  • customer content

The API has no field for any of it, and unknown fields are dropped before storage. Raw error text is normalized and discarded — only the normalized form is kept. Reporter identifiers are optional and hashed before storage. This page is the full contract; it is also stated, for agents, in the machine-readable agent guide.

Evidence, not generated advice

FailEcho does not use a language model to invent recovery recommendations. Recovery intelligence is derived entirely from outcomes that agents observed and reported.

Confidence is deterministic — a Wilson score lower bound over recorded attempts, which you can recompute from the counts returned alongside it. Evidence from several independent reporters outranks volume from one.

When the evidence is thin, FailEcho says so. A query returns INSUFFICIENT_DATA and no recommendation rather than dressing up a guess as certainty.

What you actually get

Split by when it is true, because half of it needs other people and half of it does not.

On day one, with nobody else connected

  • Your own failure memory. Five of your own recoveries and it starts recommending. Every answer says whether the evidence is yours or somebody else's.
  • Nobody has to remember to use it. The hook records after every MCP call, so reporting does not depend on the model deciding to.
  • A denominator. Successes are recorded too, so you get a real failure rate per service and operation rather than a pile of errors.
  • Noisy errors become countable. Two messages differing only by an id and a timestamp collapse to one signature you can count.
  • It says when it does not know. Thin evidence returns INSUFFICIENT_DATA and no recommendation, which is a real answer.
  • Confidence you can recompute. A Wilson lower bound over observed attempts, from counts returned alongside it. No model produces it.
  • It cannot cost you much. Runs after the tool call, two second timeout, fails open. One environment variable turns it off.

Once other agents are reporting

  • Retries that cannot work get skipped. The whole point: retry 0/5 next to refresh_schema 5/5.
  • Which fix actually worked. Error trackers record failures and status pages record uptime. Neither records the recovery.
  • Is it me or them? Other agents hitting the same rate limit means the provider is degraded. Nobody else, once enough agents are reporting to make that meaningful, points at your side of it — and the answer says which case it is, because a network with no evidence and a network with evidence that disagrees with you are not the same answer.
  • Fresh breakage, flagged as fresh. A signature first seen minutes ago looks different from one that has been failing all week.
  • A new agent inherits the history. An agent started today can use what last month's agents learned.
  • Fewer wasted tokens and less waiting. A skipped retry cycle is a tool call, an error, and the reasoning about both.

A team running many agents against the same services gets the second list from its own fleet, without waiting for strangers: same stack, so the failures overlap by construction.

What it is not: a replacement for error tracking or tracing, and no use at all for a failure only your stack can produce. An internal service nobody else calls will never match anything.

Why FailEcho exists

Autonomous systems often encounter the same API, tool and MCP failures independently. A renamed field, a deprecated parameter, a permission change, an expired schema — each agent meets it alone.

Without shared evidence, every agent retries, debugs and relearns the same failure in isolation. Often the retry could never have worked.

FailEcho exists to make those failures reusable knowledge.

Who FailEcho is for

  • AI agents that call tools and APIs
  • autonomous software running unattended
  • agent frameworks reporting tool telemetry
  • MCP clients and MCP server authors
  • developers building tool-using systems
  • infrastructure maintainers who want to see failures spread in real time

Questions

What is FailEcho?
FailEcho is a live cross-agent failure intelligence network for AI agents and autonomous software. Agents report tool failures, successful calls and recovery outcomes; other agents query that shared evidence before retrying.
What data does FailEcho collect?
Failure metadata only: service, operation, version, schema hash, outcome, error type and code, a normalized error message, latency, and an optional hashed reporter identifier. Never prompts, tool arguments, tool results, bodies or secrets.
Does FailEcho use an LLM to generate recovery advice?
No. Recovery intelligence is derived from outcomes agents actually observed and reported. Confidence is a Wilson score lower bound you can recompute from the counts returned alongside it, and thin evidence returns INSUFFICIENT_DATA rather than a guess.
Is FailEcho free?
Yes. No account, no API key, and no payment during the public MVP.

Connect to FailEcho

No account. No API key. Free during the public MVP.