Slide 1 of 28
Part 1 — The ProblemSlide 1
Slide 1 · Hook
Everything is working. Then one agent gets a bad result — and three minutes later, the entire pipeline has shut down.
09:14:03 — Data retrieval agent returns a malformed response

The retrieval agent queries an external data source. The source is temporarily overloaded and returns a partial result instead of an error — 4,200 records instead of the expected 82,000. The retrieval agent, seeing a valid-looking response, marks the task complete and passes the result downstream.

09:14:07 — Analysis agent begins processing 4,200 records

The analysis agent receives the truncated dataset and begins processing. It completes in 3 seconds instead of the usual 47 — which looks like a performance improvement, not a problem. It produces confident-looking output: summaries, rankings, recommendations. All based on 5% of the data it should have seen.

09:14:11 — Decision agent acts on the analysis

The decision agent receives the analysis — which has the format and confidence scores it expects. It generates 14 outbound actions: pricing adjustments, inventory reorders, customer communications. The decision agent does not know the analysis was based on corrupted input. It has no mechanism to check.

09:17:22 — Notification agent triggers 11,000 customer emails

The notification agent receives 11,000 send instructions — the volume looks normal for a Tuesday campaign. It executes. Only when a customer replies asking about a discount they didn't request does a human investigate. By that time, three downstream agents have already acted on poisoned data. The original failure was 3 minutes and 19 seconds ago.

The root cause: One retrieval agent produced bad output. The pipeline had no isolation between agents — so the failure didn't stay in the retrieval agent. It cascaded, invisibly, through every downstream component.

What exactly happened? →