Dependency Management

As data moves through a multi-stage pipeline (ingestion, normalization, enrichment, aggregation, and into an agent's context), each stage typically emits only its output, not a record of which input rows or upstream events produced it. When the agent later needs to explain a decision, trace an anomaly back to its source, or honor a downstream correction (a customer disputes a charge derived from a specific transaction), there is no reliable path from the final artifact back to the originating record.

An agent's downstream consumer (a database writer, an LLM enrichment call, a rate-limited third-party sync) slows down, but the upstream producer stages of the pipeline keep emitting data at the original rate because no signal travels backward to tell them to slow down. The gap between production and consumption rate is absorbed by an in-memory or disk queue that has no bound, until it either fills and starts dropping messages or exhausts host memory and crashes the whole pipeline.

An agent that reads from a multi-stage pipeline treats the data it receives as current, but each stage (ingestion, normalization, enrichment, batching, indexing) adds its own processing delay, and those delays compound. By the time the agent acts — approving a trade, flagging inventory as low, answering "what is the current status" — the data reflects the world as it was minutes or hours earlier, not as it is now, and nothing in the agent's context signals how stale the value actually is.

An intermediate stage in a data pipeline — a normalization step, a schema-mapping step, a "clean up the data" step written before the agent's needs were fully known — silently drops or truncates fields, coerces types in ways that lose precision, or collapses distinct source values into the same output value. The pipeline continues to run without errors because the transformation is syntactically valid; it is only semantically incomplete, and the agent downstream never learns that information it needed was discarded before it ever saw the data.

An agent's processing logic implicitly assumes events arrive in the order they occurred (a "created" event before an "updated" event, a payment "authorized" before a "captured"), but a pipeline change — adding parallel processing, repartitioning a queue by a different key, introducing retries, or migrating to a different message broker — reorders events in transit. The agent applies updates in the new arrival order, producing state that reflects an event sequence that never actually happened.

When a pipeline stage fails partway through, gets redeployed, or a consumer's offset is reset for recovery, the standard remedy is to replay events from a checkpoint. If the agent's downstream processing logic performs side effects (sending a notification, charging a payment, incrementing a counter, calling an external API) without checking whether that specific event was already processed, replaying the event log causes those side effects to happen again, producing duplicate charges, duplicate notifications, or double-counted metrics.

An upstream system or team changes the shape of the data it emits — renaming a field, changing a type, adding a required field, deprecating an enum value — without coordinating with every downstream consumer. Because the pipeline has no contract enforcement between producer and consumer, the change ships silently, and the agent's parsing logic either throws on the first unexpected value, silently coerces it to null/default, or misinterprets a renamed field as absent, breaking downstream behavior with no upstream-visible signal that anything happened.

An agent's toolchain depends on a third-party service, model endpoint, or package registry that is not available in every region the agent is deployed to — due to data residency law, provider infrastructure gaps, or export restrictions. The dependency works fine in development and in the primary deployment region, so the regional gap goes unnoticed until the agent is deployed or scaled into a new region and a specific tool call starts failing for every user in that geography.

A library, SDK, or API the agent's toolchain depends on ships a breaking change — a removed function, an altered response format, a changed default behavior — and the agent's own team has no process that surfaces the change before it reaches production. Automated dependency updates, transitive upgrades pulled in by an unrelated package bump, or a provider's server-side API change (which requires no client-side upgrade at all) all ship the break silently from the agent team's point of view, and it is discovered only when the agent's behavior degrades or a build fails.

Two or more services, modules, or agents depend on each other, directly or through an intermediate chain, in a cycle: Service A calls Service B during initialization or request handling, and Service B (directly, or via Service C) calls back into Service A before A has finished. Under normal, low-latency conditions the cycle can complete without anyone noticing, but under load, during startup ordering, or when one leg of the cycle is slow, the mutual wait never resolves and the system deadlocks or spins in an infinite resolution loop.

An agent's development workflow — often an agent itself, tasked with "add a library that does X" — pulls in a new dependency without checking its license against the project's own licensing terms or the terms of the dependencies already in the tree. A permissively-licensed project unknowingly incorporates a copyleft-licensed package (or one with a restrictive commercial-use clause), creating a legal obligation (source disclosure, attribution, non-commercial restriction) the project's license terms don't account for, and the conflict surfaces only during a legal review, an acquisition due-diligence process, or a customer's compliance audit.

A library the agent's system depends on — directly or transitively — has a publicly disclosed CVE, but the vulnerable version remains in production because no process reliably surfaces the disclosure, prioritizes it against other work, and ships a patch. The gap between disclosure and patching leaves an exploitable window, and for agents specifically, a vulnerable dependency in a tool-execution or code-execution path can be a direct route to prompt injection, arbitrary code execution, or data exfiltration triggered by attacker-controlled input the agent processes.

Two direct dependencies the agent's system relies on each require different, incompatible versions of the same shared transitive dependency (Package X needs library Z at version 1.x, Package Y needs library Z at version 2.x, and 1.x/2.x are not compatible). The package manager either fails to resolve the tree, silently picks one version and breaks the other package at runtime, or (in ecosystems that allow multiple versions to coexist) installs both, producing subtle bugs when an object created by one version's code is passed into code expecting the other version's shape.

A team pins a dependency to an exact version — often deliberately, to avoid an earlier breaking-change incident or to satisfy a compliance requirement for reproducible builds — and later, a different part of the system introduces a new requirement (a new package, a new feature, a security patch) that needs a minimum version higher than the pin. The pin, which was added specifically to provide stability, now actively blocks a change the system needs, and resolving the conflict requires either revisiting the original reason for the pin or accepting the very risk the pin was meant to prevent.

An agent integrates with a third-party or internal service whose documented API contract specifies a particular response shape, status code semantics, or guaranteed behavior, but the service itself violates that contract in practice — returning a documented-as-required field as null, using a success status code for a partial failure, or exceeding its documented rate limits without the promised 429 response. The agent's integration code, written to trust the documented contract, mishandles the actual response because it never anticipated the provider's own inconsistency.

Multiple, ostensibly unrelated integrations share underlying infrastructure — a connection pool, a shared API gateway, a common authentication service, a rate-limited egress proxy — and a failure or degradation in that shared layer, triggered by problems with just one integration, propagates outward and takes down the others. An agent that assumes its integrations fail independently (and builds isolated fallback logic per integration) is caught off guard when a single root cause degrades several integrations at once, exhausting fallback capacity faster than expected or triggering compounding retries that make the shared resource contention worse.

Two integrated systems each maintain their own copy of what should be shared state — a CRM's "customer status" and a billing system's "account status," or an inventory system's stock count and an order system's reserved-stock count — and updates to one side don't reliably propagate to the other, whether due to a failed sync, a race condition between concurrent writes, or a missing update hook on one integration path. The agent, reading from whichever system it happens to query, acts on a view of "the" state that the other system would flatly contradict.

Different systems an agent integrates with signal failure through incompatible conventions — one returns HTTP error status codes, another embeds an error object inside a 200 OK response body, a third throws a language-level exception that a client SDK translates inconsistently, and a fourth simply omits expected fields on failure with no explicit error marker at all. Integration code written to detect failure one way (checking status codes) silently misses failures signaled another way (a 200 with an error payload), treating a failed operation as successful and proceeding as if it worked.

Two integrated systems model the same real-world concept using fundamentally different structures or semantics — one represents an address as a single free-text field, the other as five typed sub-fields; one treats a missing value as "unknown," the other as "explicitly empty"; one uses a flat list, the other a nested tree — and every call across the integration boundary requires a lossy or ambiguous translation between the two models. Unlike a one-time schema mismatch that a migration can fix, this is a standing structural incompatibility baked into how each system fundamentally represents the domain, so every single request/response pair pays a translation tax, and some translations are not fully recoverable in either direction.

An agent's workflow calls multiple external integrations where one system's call must complete and be acknowledged before another system's call is valid — a payment must be authorized before an inventory hold is placed, a user record must be created before a permissions grant references it — but nothing in the agent's orchestration logic encodes that ordering requirement as a hard constraint. When the agent parallelizes calls for latency, retries them independently after a partial failure, or is composed by an LLM planner that doesn't know the hidden sequencing rule, calls fire out of order and the downstream system either rejects the request against a resource that doesn't exist yet or, worse, silently accepts it and creates a dangling or orphaned record.

A single logical operation an agent performs fans out into calls against several independent downstream integrations, each with its own separately-published rate limit, and the agent's throughput planning accounts for at most one of them (usually the loudest or most recently hit limit) rather than the effective ceiling set by whichever integration is most constrained. Because none of the integrated systems know about each other's limits, and the agent's own rate-limiting logic is typically tuned per-integration rather than per-workflow, a request pattern that looks safe against every individual system's published limit can still produce compounding overload: a retry triggered by one system's 429 fans back out and re-hits every other system in the same operation, multiplying load precisely on the systems that weren't the original bottleneck.

An agent calls an external integration with a timeout shorter than the operation actually needs to complete on the far side, gives up and treats the call as failed, and then acts on that failure assumption — retrying, falling back, or notifying a user that the action didn't happen — while the original call is, in fact, still running to completion on the downstream system. When the downstream operation succeeds after the agent has already moved on, the agent's decision was made on stale information: it may issue a duplicate request (double-charging a payment, double-booking a resource), or it may leave the user with an incorrect "this failed" outcome for an action that actually succeeded. This is a correctness/state-consistency failure specific to one integration point, distinct from the broader dynamic where mismatched timeouts across a call chain amplify load system-wide.

Adding a single new direct dependency — a library, an agent tool/plugin, an MCP server — pulls in that dependency's own dependencies, and each of those pulls in more, so the total size of the dependency graph grows combinatorially rather than linearly with the number of direct dependencies actually chosen. What looked like "add one package to do X" becomes dozens or hundreds of transitively-installed packages, each an independent unit of install time, version-resolution complexity, and supply-chain attack surface that no one on the team deliberately chose or reviewed. This is distinct from a version conflict between two specific packages or a single CVE in one package; the problem here is the uncontrolled growth of the graph itself.