Read-Path Tools Cannot Solve Write-Path Problems

This post accompanies the Context Graph Reality Check series and the Write Path Problem. It is written at a moment when the category has entered a predictable phase: vendors whose architecture sits on the read path have begun using write-path language. The definitional work the category needs is not a reaction to any single launch. It is the clarification that lets buyers distinguish what a metadata platform enriched by agents actually produces from what an organization with a functioning decision write path actually owns.

The context layer is now, by a casual count, what every enterprise vendor says they are. The foundation model company is a context layer. The semantic layer vendor is a context layer. The knowledge graph, the data warehouse, the data integration platform, the system of record. The metadata platform most of all. Analyst framing has reinforced the term. The practitioner vocabulary has spread through engineering posts and viral threads. And in the way categories work, the vocabulary is now moving faster than the distinctions underneath it. When everyone claims the same territory, the structural questions — what each architecture actually produces, where each sits in the organization, what each can and cannot guarantee — get quietly rewritten into marketing.

This is the moment category capture happens. Not through any single bad-faith act. Through vocabulary drift. A term used precisely by a small number of practitioners becomes a term used loosely by every vendor whose product is structurally adjacent, and the precise meaning dissolves into the loose one. The response, when it works, is definitional: sharpen the distinction that the terminology is being used to elide, and publish it at a level of technical specificity the loose usage cannot absorb.

This post is that work for the phrase context graph. The distinction being elided is between two graph operations that have different shapes, different positions in the organization, and different guarantees. The corpus has called them the read path and the write path. They are not synonyms for different product tiers. They are not different views of the same database. They are different operations, and the claim that a read-path tool produces a write-path artifact is the category capture move to refuse.

Two Graph Operations

A context graph, in the sense that matters for enterprise AI, is not a single architecture. It is the output of two distinct graph operations that the term quietly packages together.

The two operations share a word — graph — and very little else. A catalog enriched by agents is a read-path artifact at a larger scale. An organization that captures its decisions, with authority and precedent attached, produces a write-path artifact. These are different graph operations producing different kinds of records. The category capture move is to name the second with the vocabulary of the first.

Documentation Is Not Decision Capture

The clearest place this distinction gets elided is the cold start problem. The framing, as it circulates now, goes roughly as follows: an enterprise has hundreds of thousands of undocumented data assets, documenting them manually would take a multi-year project, and the breakthrough is that AI agents can compress that work from months to minutes by generating descriptions from SQL patterns, lineage, and usage signals. This is presented as the solution to cold start.

It is a solution to a different problem.

The cold start problem the Write Path Problem identifies — the empty graph problem — is not that data assets are undocumented. It is that the organization has no mechanism for capturing decisions as they are made, so the write-path graph starts empty and stays empty regardless of how thoroughly the read-path graph is populated. An AI agent that enriches the description of a data asset is doing read-path work at higher velocity. It is not, and cannot be, doing write-path work — because the decision about what the data means for the business was never written down anywhere for the agent to enrich.

Documentation of assets and capture of decisions are different operations. Compressing the first does not begin the second. A fully documented catalog in which every column has a glossary term, every table has an owner, and every dashboard has a usage score is still an empty graph in the sense that matters: there is no record of why the business chose what it chose, what authority constrained the choice, or what precedent it set. An agent asked a business question will have excellent access to the description of assets and no access to the reasoning of the enterprise.

This reframe matters beyond the specific claim. It reveals the structural limit of what a read-path system can do no matter how much AI is added to it. A read-path system scans, infers, and enriches over artifacts that exist. It does not produce the artifacts. The work of producing those artifacts — capturing decisions as they are made, with authority and precedent linkage — is organizational, not agentic. No agent acting on existing assets can manufacture a decision that the organization never made or never recorded.

The Write-Path Test

The definitional work is clearest as a diagnostic. When a system claims to be a context graph, five questions establish whether the claim refers to a read-path artifact at scale or a write-path system that produces new organizational state. These questions do not depend on the system’s marketing. They depend on the operation the system performs and the record the operation produces.

A system can be excellent at read-path work and still fail all five. That is not a criticism of the system. Read-path work is necessary. The three-layer ecosystem taxonomy introduced earlier in this corpus — data asset reference, decision capture, intelligence — treats read-path enrichment as the first layer on which the other two depend. The criticism applies specifically to the naming move: calling a read-path artifact a context graph and calling the question closed.

Context as IP, and What That Actually Requires

A line has entered the category that deserves closer examination. The framing is: context is IP; the knowledge your teams have built about your data belongs to your organization; own it on open standards. The framing is right at the level of the claim. Context is IP. It does belong to the organization. Ownership matters.

The question the framing does not answer is whether an enrichment pipeline, operated by agents inside a vendor’s platform, over the organization’s data assets, produces the kind of IP the framing describes. The answer depends on the same distinction. If the output is a richer description of the assets — glossary terms, business definitions, quality scores — that output is operational metadata. It is useful. It is not the organization’s reasoning. The organization’s reasoning, the record of decisions that were made and the authority that made them, is what would constitute context as IP in any meaningful sense. And that record is not produced by enrichment over existing assets. It is produced by capture at the moment of decision.

Open standards, versioning, portability — these are the right attributes for any IP the enterprise owns. They do not convert a read-path artifact into a write-path one. A portable, versioned, open-standards-based description of assets is a portable, versioned, open-standards-based description of assets. Which is worth having. And which is not the thing the framing implies the enterprise is getting.

Where This Leaves the Category

The category is now approximately where metadata management was a decade ago, with a different name. The vocabulary has moved. The architecture underneath has largely not. A read-path system augmented by agents is more useful than a read-path system without agents. It is not, on account of the agents, a different kind of system.

The write path remains open as the category’s unaddressed problem. Not because vendors are failing to address it — addressing it is harder than extending the read path, because it requires organizational change that no product can ship. The write path runs through authority structures, decision rituals, and the question of who in the enterprise is responsible for recording why a choice was made and what it binds. A product can host the record. It cannot manufacture the practice that produces the record. The enterprises that will eventually have functioning context graphs in the full sense are the ones that do the organizational work now, with whatever substrate they use.

The terminology will continue to drift. That is the nature of a category in its naming phase. What does not drift, for anyone doing the definitional work, is the structural distinction between a system that produces descriptions of existing assets and a system that produces records of organizational reasoning. A context graph that is the former is a valuable metadata artifact at enterprise scale. A context graph that is the latter is a different thing, mostly still to be built.

The difference is not ornamental. It is the difference between an enterprise AI stack that can describe the business and an enterprise AI stack that can reason inside it. Enterprises that cannot distinguish the two will spend the next three years instrumenting the first and believing they have solved the second. The distinction is available now. Applying it is the work.