Dependency Propagation

Staleness, not storage, is what kills a source of truth. Storing company knowledge is easy; keeping it true after every pricing change, repositioning, and feature launch is the hard part. Without propagation, every change means someone hand-hunting through decks, landing pages, templates, and agent training material. Some copies always get missed, the knowledge drifts out of sync, and people quietly stop trusting it.

The stakes went up when AI agents became the main consumers of this knowledge. A stale document a human might question is a stale answer an agent delivers with confidence, to a buyer, in your company's name. Teams building GTM context layers consistently name dependency propagation the single most important capability, and it's the one a DIY folder-plus-MCP build never survives without.

Put simply: dependency propagation is the capability that separates a maintained context layer from a folder of documents.

1. Facts are nodes. Source facts (a price, a capability, a claim) are stored as discrete entries in a graph, each with provenance and a verification status.

2. Content registers dependencies. Every dependent asset (a deck slide, a landing page section, an email template, an agent's answer) records which facts it draws on.

3. A change triggers a graph walk. When a source fact is edited, the layer traverses the graph and flags every asset that depends on it, including indirect dependents.

4. Updates apply or route to a human. Straightforward substitutions update automatically; judgment calls route to an owner for approval, and the ruling becomes the authoritative version.

5. The new truth serves everywhere. Agents connected to the layer, typically over an MCP endpoint, answer from the updated fact immediately. No re-crawl, no re-embed, no hoping.

A B2B software company changes one pricing fact: a plan's entry point moves. That single fact turns out to have fourteen dependents in the context layer: the pricing page, two sales decks, three outbound email templates, a competitor battle card, four campaign landing pages, two product one-pagers, and the website agent's pricing answer.

Without propagation, marketing updates the pricing page, sales updates one deck, and the other twelve assets keep quoting the old number for months. A prospect sees one price in an email and another on the site, and the deal starts with an apology.

With propagation, the fact changes once at the source. The layer flags all fourteen dependents, applies the new number where the substitution is mechanical, routes the two decks to their owner for a quick approval, and the website agent quotes the new price from the moment the change lands. One edit, fourteen assets, zero stale copies.

• Relying on re-crawls. Re-indexing your docs on a schedule updates the index, not the documents. The stale copies are still stale; agents just retrieve them faster.
• Tracking dependencies in someone's head. "Sarah knows which decks mention pricing" works until Sarah is on vacation, or gone. Dependencies have to live in the system.
• Updating copies instead of the source. Fixing the number in a deck without changing the source fact guarantees the next generated asset reintroduces the old value.
• Confusing search with propagation. Finding every mention of a fact is the easy half. Knowing which assets depend on it, updating them, and getting the judgment calls approved is the capability.
• Propagating without a human gate. Some changes are mechanical, but positioning and claims need an owner's ruling. Fully automatic propagation of judgment calls trades stale answers for wrong ones.