The Read Path Is Done. The Write Path Left the Building.

In one week in June 2026, two of the three hyperscaler-class data players shipped the same move.

On June 16, at its Data + AI Summit, Databricks announced LTAP — Lake Transactional/Analytical Processing, one open copy of data serving both the transactional and analytical engines — alongside Lakehouse//RT, a real-time query engine delivering millisecond reads directly on governed lake tables. On June 17, AWS announced Context — a knowledge-graph service that maps the relationships across data an enterprise already holds and self-curates those paths from agent usage. Different layers of the stack, different vocabularies. All of it was announced as the moment the data substrate became ready for agents to act.

Post 1 drew the line: an agent’s data layer does two jobs — describe what the enterprise already knows, and capture what the agent decides — and only the first, the read path, has resolved. It also named the instrument: the Substrate Fitness Criteria, five criteria that separate a data layer built for autonomous decision-making from one built for human interpretation. This post applies them to the two June announcements. The finding is not that the substrate stops short. It is where the part it stops short of goes — because both announcements move it to the same place, and that place is the subject of everything this practice takes up from here.

The criteria split along the line Post 1 drew. Discoverability and contextual richness are read-path criteria. A native decision-event model is the write path by another name. Action-orientation sits on the boundary, and permission-native architecture cuts across both. Walk the specimens down the five.

Discoverability

AWS Context is, more than anything, a discoverability instrument. It makes the relationships across existing enterprise data traversable by an agent that arrives without schema knowledge, and it propagates the join paths agents actually use back into the graph. LTAP advances discoverability differently — by collapsing two stores into one queryable surface, it removes the seam an agent would otherwise have to cross. Both clear it. The Data Substrate or Scaffolding series classified discoverability as the extensible criterion — the gap that yields to engineering. These are exactly what closing it looks like.

Contextual Richness

Context’s stated purpose is meaning at the point of consumption — the relationships, not just the values. Mai-Lan Tomsen Bukovec, who led S3 for roughly thirteen years before becoming AWS’s vice president for data and analytics, described it as a “data lake of nuance.” That is contextual-richness language, and it is earned: the graph carries the connective tissue an agent would otherwise assemble downstream. LTAP delivers it by unification — transactional state and analytical context retrievable in one queryable surface. Both clear it.

Permission-Native

Both move, neither completes. Context inherits IAM and Lake Formation, so every hop an agent traverses is governed and auditable at the graph layer. LTAP inherits Unity Catalog, which the Data Substrate or Scaffolding series already credited as the most real movement toward permission-native architecture in the market. Authorization is closer to the substrate than the application layer — but it is still catalog-enforced, not intrinsic to the data event itself. This is the second extensible criterion, and both vendors are extending it. Consistent with the published read. Hold onto where this authorization lives, though — it governs the substrate, and the substrate is about to stop being where the consequential thing happens.

Action-Orientation and the Decision-Event Model

Here the announcements and the criteria part company. The Data Substrate or Scaffolding series already classified these two as architectural conflicts — not missing features that orchestration above the data layer can supply, but commitments that conflict with what the analytical and transactional stores were built to do. Nothing in either June announcement resolves that conflict. Context surfaces what is related; it does not bind what is permitted and consequential into the same retrieval, transactionally. LTAP lets an agent act on a transactional store — but an agent acting on a row is not the substrate capturing the decision. The transactional record is captured data: an operation that happened. The decision trace is generated data: the reasoning, the authority, the precedent, correlated with the agent’s identity at the moment of action — and that correlation is produced where the agent runs, not where the data rests. The decision-event criterion specifies that correlated record as native to the substrate. Neither vendor shipped it there.

The tell is in where each put the memory. Databricks pairs LTAP with Agent Bricks and “managed agent memory backed by Lakebase.” AWS pairs Context with managed agents that retain operational state. Both describe a store that holds what the agent did and where it is — session and operational state. Neither describes the decision-event model the criterion defines. Operational memory is not a decision trace. A store that remembers the agent’s last action is not a substrate that records why the agent was authorized to take it. The distance between those two is the whole write path — and notice the memory sits with the agent platform in both cases, not the data substrate the announcement was about. That placement is not incidental. It is the whole finding.

The Same Word, Opposite Directions

The scoreline is identical for both specimens, but the two vendors did not arrive at it from the same place, and the difference is the part worth holding onto. AWS owns the substrate; Databricks rents it. On the read-path primitives specifically — vector storage, retrieval, the commodity fetch layer — a tenant cannot reach the floor a landlord stands on, which is why AWS prices the read path lower and Databricks pays its lease into the bill. That is not a knock on the platform Databricks sells, which buys real things. It is a statement about which layer each company occupies — and the layer each occupies is the key to why each one stopped where it did.

That layer was a choice, and Databricks made it years ago. It was always the control plane for the cognitive substrate; it handed the data plane to the cloud providers as the lakehouse pitch, and then, over the past two years, formalized the handoff — deprecating its own file system, then its own metastore, retreating to pure account-level governance sitting on someone else’s object store. LTAP is what reaching back looks like: a control-plane company announcing unified transactional-analytical storage to re-acquire the data-plane gravity it gave away, because the read path commoditized into the plane it walked out of. And Lakehouse//RT, the real-time engine announced beside it, is the tell beneath the tell. Its headline is millisecond reads at twelve thousand queries per second — and Databricks’ own release scopes it, in its own words, to read-only workloads in beta. The fastest thing at the summit is, by the vendor’s own label, the read path. Processing speed defends the seat Databricks already holds — the fastest processor of a commoditizing read path is still on the read path. It is motion to stay where it is, not motion toward the write path.

And none of it could have held the write path, because none of it stands where the write path is made. Every layer Databricks rebuilt operates on the data: where it lives, who may reach it, how fast it returns. The decision trace operates on the act: what the agent decided, under what authority, at the moment it decided. Those are two different planes, and Databricks spent the cycle perfecting the first. The write path was never on the table — not because the company lacked the engineering, but because nothing it modernized stands at the boundary where a decision is made.

AWS is the cleaner test, because AWS has no tenant’s excuse. It owns the substrate beneath the agent and the runtime above it — S3 and Context below, Bedrock and its managed agents above. It owns both ends of the write path. And the gap is still there: Context surfaces relationships, the managed agents hold operational state, and nothing between them records the decision. The most vertically integrated player in the market, holding both floors, did not close the write path either. That is the finding worth sitting with, because it rules out the easy explanation. The write path is not missing because a vendor failed to own enough of the stack. AWS owns the whole column and the decision still goes uncaptured, because capturing it is not a matter of owning the layers — it is a matter of standing at the moment of decision and recording what no layer was built to see. Ownership was never the missing piece. The boundary was.

So the symmetry the announcements present — two vendors, one week, agents can act — has an asymmetry underneath it, and even the asymmetry resolves to the same finding. AWS substitutes a verb: act, for what is governed fetch. Databricks substitutes a metric: milliseconds, for what is the capture question. Both narrate the read path in write-path vocabulary, because the read path is the layer each has finished and the write path is the layer neither has. The fluency is the camouflage. When the only language a vendor has for “ready for agents to act” is access verbs and access speed, the access layer is complete and is being described as the decision layer.

The Scoreline

The scoreline reads the same for both specimens: discoverability and contextual richness complete, permission-native architecture advancing, action-orientation and the decision-event model unresolved — the read-path criteria met, the write-path criterion left where the Data Substrate or Scaffolding series found it. Two different companies, occupying two different layers, arrived at the identical result: the read path finished, the write path untouched, and the gap renamed as readiness. What both did with the gap is the part worth reading carefully.

Return to the permission layer, because it is the seam. Post 1 counted the read path inheriting existing cloud security posture as a win, and it is one: an agent’s data access governed by the same IAM that governs the rest of the estate, audited the same way, with no new authorization plane to stand up. That is real, and it is what makes read-path deployment cheap. But IAM governs fetch. It decides which data the agent may read; it says nothing about which decision the agent reached or under what authority. “The agent was permitted to access this” is read-path authorization. “The agent decided this, on this state, under this authority” is the write-path record, and the permission layer never reaches it, because IAM sits at the access boundary, not the decision boundary. The same posture that makes the read path cheap and governed is the posture that makes “act” look closed when it is not. Governed access is not captured decision. The cloud security model the read path inherits has no opinion about the write path at all.

This is why the read path commoditized and the write path did not. The read path is architectural: an agent’s need to discover, understand, and traverse existing data is a property of the data, and a sufficiently sophisticated store can satisfy it. AWS and Databricks just demonstrated, in the same week, how completely. The write path is organizational: the decision, the authority, the precedent are not properties of the data — they are produced at the moment of action. Capturing them requires recording why the agent was authorized to act, on what state, under what precedent, correlated with its identity — and that record is not generated in the store. It is generated where the agent runs. So when a vendor completes the read path and names it act, the write path does not get closed. It gets relocated — up out of the substrate the announcement was about, into the managed agent platform one layer above it. A “data lake of nuance” is still a data lake. It enriches what is already there. The decision gets recorded somewhere else, by someone else — and that somewhere else is where the problem gets solved, not where it gets buried.

That somewhere else is the architecturally consequential part, and it is the part neither announcement puts on the table. The read path is now a hyperscaler commodity — AWS and Databricks settled that this June. The write path moved to the layer that holds the agent’s runtime: provider-owned, outside the substrate the enterprise governs, and structurally invisible to the permission controls the substrate does carry. An enterprise placing a bet on either announcement is buying a finished read path and inheriting an open question it did not get to set the terms of — where the decision trace is captured, who owns that layer, and whether an examiner can reach it. The criteria told you which floors of the substrate are finished. They also told you the decision moved into a building the vendor owns. That is the question the substrate frame can no longer answer.