*Published July 8, 2026* --- *I red-teamed my own agent stack for two days. Everything broken was between components — invisible to any single file, and to me.* Over two days I ran an adversarial review across ten components of my own agent infrastructure: the skills, hooks, and cron loops that commit to my repos and feed my decisions without me watching. Every pass found something broken and running. A safety hook silently disabled: the pre-commit guards I relied on weren't firing, because the pointer that turns them on was never set. Two repositories wedged for weeks behind a stale lock, their sync logs printing "OK" the whole time. Injection paths where fetched text reached write authority unchecked. None of it was theoretical. It was live, in production, on the day I looked. ## The four classes The findings fell into four: 1. **Untrusted content treated as instructions** — fetched text reaching a component that acts on it. 2. **Unfalsifiable success** — a step reporting "done" with no evidence behind it. 3. **Producer-consumer contract drift** — two components disagreeing about a shared contract. `DONE` meant "merged and verified" to the skill that produced it and "PR opened" to the skill that consumed it. 4. **Incomplete state machines** — states with no way out, termination guards that can't be evaluated from saved state. Was this just my messy stack? I checked whether anyone had studied it at scale. ## Checked at scale They had. [MAST](https://arxiv.org/abs/2503.13657) (Cemri et al., 2026) built a failure taxonomy from 1,600-plus traces across seven multi-agent frameworks and landed on three categories: system design, inter-agent misalignment, and task verification. The mapping to my four classes is mine, not the paper's, and their subject is coordination between agents where mine is one orchestrator's plumbing. But the shapes converge. Their misalignment category includes an agent whose stated reasoning doesn't match its action, contract drift by another name; their verification failures look like my unfalsifiable success; their system-design failures, especially mishandled termination, look like my dead state machines. Only my first class, untrusted input treated as instructions, falls outside their map; injection enters from outside the agent set, not from the coordination between agents. Other people's stacks fail in the same shapes, and most of those shapes live between components, where no one is watching. So the mess isn't mine alone; it's the shape of the thing. ## No single file is wrong That's what these defects share, and it's why the usual tools miss them. Prevention, type checkers, single-diff review all work by finding the file that's wrong. Contract drift lives in the gap between two files that are each internally fine. Each side is right about its own `DONE`. They just never agreed, and the disagreement isn't written down anywhere. No one owns the seam between components, so nothing watches it. Each skill passes its own tests, and no test exists for the pipeline they form. ## You can't review your own work The reflex fix is "review your own infrastructure." That's half wrong, and the wrong half matters. You can't reliably review your own work, for a reason that's cognitive, not moral: inattentional blindness — the gorilla-suit experiment, [Simons and Chabris, 1999](https://doi.org/10.1068/p281059) — means a mind locked on a task misses what a fresh one catches. You read what your code is meant to say, not what it says. A reader with different priors sees different things, not more. My defects surfaced not because I inspected my own plumbing but because I spawned independent reviewers with no memory of why I'd written what I had. The working ingredient is manufactured independence, not ownership. "Review your own infrastructure" gets the credit backwards. ## Both sides of the contract One move did more than the rest, and it repeats: for every contract between two components, give one reviewer both sides at once — the producer's file and the consumer's — and tell it to trust neither. The `DONE`-means-two-things bug was invisible to any reviewer that saw one skill. It took a reader holding both definitions at once to notice they didn't match. There's no single file to catch it in; a two-sided reviewer is the cheapest thing that can. The smaller move: trust the running state, not the documentation. Mine described a guard that was right in intent and disabled in fact. ## Investment or avoidance Now the part I trust least. I keep telling myself the missing piece isn't infrastructure but the customer conversations I keep putting off. I'd capped myself: no new meta-systems. Yet here's a two-day sweep of my own plumbing — meta-system work by any honest definition. So which was it? The honest answer isn't clean. I didn't build a system; I checked whether the ones I'd committed to were doing what I'd promised, and several weren't. A disabled safety hook isn't a new project. It's a promise I broke without noticing. That defense holds. But those two days could have gone to the conversations, and no bug buys that time back. I can name the cost but not erase it. The bugs are live in your stack too, in whatever plumbing you've stopped watching. If your review tooling is file-scoped, and most of it is, nothing you run will surface them: these bugs live between the files. So hand a stranger both sides of one contract and tell them to trust neither. It costs an afternoon. Then ask yourself the same question I did.