The Read Path Reached the Object Store. The Write Path Did Not.

The question this practice has circled since March — where does the agentic data substrate live — splits into two the moment anyone tries to answer it, and only one half has been answered.

An agent’s data layer is asked to do two different jobs: describe what the enterprise already knows, and capture what the agent decides. The first is the read path. The second is the write path. As of June 2026 the read path has resolved, all the way down to the object store. The write path has not moved. This post draws the line between the two and points to the instrument that tells them apart — because the providers finishing the read path are beginning to call it the substrate, and a finished read path is not a finished substrate. The next post runs the newest, largest specimens through the instrument. This one builds the distinction.

The lane this note anchors

This practice named the missing layer in March. AI Adoption Architecture, Part 2 put it plainly: most modern data platforms — lakehouses, warehouses, cloud warehouses included — solve only forty to fifty percent of the adoption problem, and the missing half is structural, because those platforms were built for analytics, not for reasoning systems that act. Part 1 had already located the deeper assumption: enterprise architecture was built around systems of record that store and retrieve, and agents break that assumption by reasoning and acting rather than storing. The Infrastructure Imperative carried it forward as the shift from advising to acting, and named one of its structural gaps a data substrate built for insight rather than decision-making. The Agentic Data Cloud worked the vendor question directly — Google as a substrate-convergence story, then Databricks and Snowflake making different bets on what the agentic runtime is — and reached a verdict worth holding onto: none of the three answers the full requirement.

The lane was always the open question underneath all of it. The Displacement named the refinement layer and placed it in the provider-owned agent platform, not the data store. The Data Substrate or Scaffolding series built the fitness criteria that score a data layer for autonomous decision-making. But no named contender had yet completed the data layer and forced the question of whether completing it is the same as answering it. That changed in June. This post is the lane’s anchor, and the anchor’s job is to separate the half that resolved from the half that did not — to give the distinction a name and point to its test — before the specimens arrive.

The read path resolved, all the way down

Treat the read path as a checklist and walk it down the stack. Every layer an agent reaches to describe what the enterprise already knows is now an object-store primitive.

Retrieval went first. Amazon S3 Vectors reached general availability on December 2, 2025, storing and querying up to two billion vectors per index, returning frequent queries near one hundred milliseconds and infrequent ones under a second, with up to fifty metadata keys per vector for filtering. AWS puts the cost reduction at up to ninety percent versus a specialized vector database, for uploading, storing, and querying. The number is the architecture, not a discount. A dedicated vector database is a standing service — an always-on instance holding the index hot, billed by the hour whether or not a query arrives. S3 Vectors moves the index out of that standing compute and into storage, and summons compute only at execution: a query operation and the function that runs it, billed per call, with no idle tier behind it. That is the provisioned-to-serverless move that already reshaped the rest of cloud, applied to the last retrieval component still trapped in the always-on instance model. The saving is not promotional. It is the read path falling to the object store’s own cost floor — storage rent plus on-demand execution — and once a layer reaches that floor it stays there.

Table semantics followed. S3 Tables carry Apache Iceberg natively, and Iceberg version 3 — deletion vectors, row tracking, the VARIANT type — had by practitioner accounting reached general availability across the major platforms in the first half of 2026. Discovery came with S3 Metadata as a queryable surface, and at the AWS New York Summit the Glue Data Catalog added business context and semantic search in preview.

The relationship layer arrived last, and it is the one that forces the diagnosis. AWS Context, introduced at that same summit, maps the relationships across an enterprise’s existing data into a knowledge graph and gives agents governed, identity-aware access to those relationships, business rules, and domain knowledge at runtime. Retrieve, discover, describe relationships: the full read path now resolves at the object layer, under one identity boundary, with every hop auditable under IAM and Lake Formation. This is a genuine completion, and the corpus should say so plainly. It is the most complete read-path substrate any provider has built.

Read the completion for what it does, not just what it is. Each primitive absorbs a read-path actor that used to be a separate, provisioned service — the standalone vector database, the bolt-on retrieval tier, the external catalog — and reprices its function to the object store’s floor. The specialized middle of the retrieval stack collapses into the store beneath it. For anyone deploying agents, this is the good news, and the lane should say so without flinching: the most expensive, most fragile part of the retrieval stack just got cheaper and simpler, and the authorization that governs it inherits the cloud security posture the enterprise already runs — IAM, resource policies, the controls already audited and managed. The cost of giving an agent governed access to enterprise data drops on both axes, infrastructure and governance. Completing the read path makes the case for agentic AI stronger, not weaker. It removes the part that was holding it back.

Two jobs, not one

The completion is real, and it is also only half the job. The reason the read path could resolve at the object store — and the reason the write path could not follow it down — is that the two jobs are different in kind, not in degree.

The read path enriches representations of assets that already exist. A vector index, a table format, a metadata catalog, a relationship graph — each describes, ranks, or connects data the enterprise already holds. The work is to make what exists more discoverable and more legible to an agent that arrives without prior knowledge of it. That work is a property of the data, and a sufficiently sophisticated store can satisfy it. The object store just did.

The write path records reasoning that did not exist until the system captured it. When an agent acts, it produces something the store never held: the decision it reached, the authority that decision rested on, the precedent it set for the next one. That record is not a more precise description of existing data. It is new data, generated at the moment of action — which agent, acting under what authorization, on what state, with what justification, correlated as the action happens. The gap is not that the store lacks the columns. A store will hold any field you define; a schema is not the obstacle. The gap is vantage. The read path sits over data at rest and describes it; it has no position at the decision boundary, where the reasoning and the authority are live and the correlation is there to be captured. That boundary is in the runtime, where the agent runs. The read path describes the world the agent found. The write path records the world the agent changed — and it can only record it from where the change is made.

This matters for where the record can live versus where it can be made. Once the decision is captured live, it can be written down into the object store like any other source and promoted through the lake as data at rest — the lake is a fine destination for the record. It is not a place the record can be originated, because origination requires standing at the decision boundary, and the lake stands over data, not over decisions. The substrate can be where the write path lands. It cannot be where the write path happens.

The instrument that tells them apart

The distinction needs a test, and this practice already built one. The Substrate Fitness Criteria — five criteria that separate a data layer built for autonomous decision-making from one built for human interpretation — are that test, and they map onto the read/write line directly.

Discoverability and contextual richness are read-path criteria: can an autonomous actor find the data, and does the data carry its meaning at the point of consumption. The object store now clears both. Permission-native architecture cuts across both paths: authorization belonging to the substrate layer rather than the application layer. Action-orientation and a native decision-event model are the write path by another name: is operational state first-class and transactionally bound to data access, and does the substrate carry a native record correlating data state, agent identity, authorization basis, and action.

The second post in that series already classified which gaps yield and which do not. Discoverability and permission-native architecture are extensible — addressable through engineering investment without architectural conflict. Action-orientation and the decision-event model are architectural conflicts: to satisfy them the substrate would have to become something it was never designed to be. That classification is the load-bearing one, and it is published. The next post does not re-derive it. It applies it — to the two largest, newest specimens the market has produced, shipped in a single week, each finishing the read path and naming the result the substrate.

The line is drawn. The read path reached the object store. The write path did not move. The instrument that tells you which is which is already in hand. What remains is to hold the newest contenders against it — because they are about to tell you the substrate is finished, and the criteria are how you check.