Three vendors shipped agent platforms this season, and all three used the same word to describe what their agents do. They act. The word is doing more work than it can hold — and the way to see that is not to dispute any one claim, but to grant all three. Each is true. Lay the three true statements side by side and the same thing is missing from every one of them.
Series 22 argued that the write path is a distinct architectural layer, separate from the read path the cloud just finished. These announcements are the first large-scale test of that claim: if the write path were not a separate layer, the most advanced agent stacks in the market would close it as a matter of course when they shipped “act.” This dispatch runs that test.
The same verb, three times
AWS Context gives an agent governed, identity-aware access to the relationships across enterprise data, every hop auditable under IAM. That is real. An agent can read what it is permitted to read and act on it. Databricks LTAP lets an agent act directly on a transactional store, with Lakehouse//RT serving the reads — scoped, in Databricks’ own release language, to read-only workloads in beta. That is real too. The agent acts on a row. And Google’s Data Agents Guidebook defines a data agent as a system that gathers context, plans, and executes — built on “an AI reasoning engine, a data context layer, and an orchestration engine that selects optimal tools.” Real again. The agent generates the query, runs it, and produces the result.
Three vendors, three verbs that are all the same verb. “Act” means governed fetch at AWS, act-on-a-row at Databricks, generate-and-produce at Google. Concede each one fully. The read path is finished in all three, and finishing it is a genuine accomplishment — the most expensive, most fragile part of the retrieval stack got cheaper and inherited the cloud security posture the enterprise already runs. None of that is in dispute. The question is what happens at the end of the act — and one of the three answers it against its own documentation. Google left the contradiction in writing, which makes it the case to examine in full; AWS and Databricks corroborate it from the same boundary.
The cleanest case is a credit memo
Google’s guidebook supplies the clearest example, because it walks an agent all the way to a consequential action. In its multi-agent illustration, an agent produces a credit memo with “no human input beyond initial setup,” and the workflow ends with the document “saved to ERP system and sent for signature.” It is the boldest “act” in the three documents — and it is worth reading against Google’s own developer docs, because the gap between what the guidebook depicts and what the shipping product does is itself the point.
The data agent in Google’s platform — the Conversational Analytics API, the thing that turns a question into an answer over BigQuery, Looker, or a database — is read-only by design. Its documentation states plainly that it can’t perform write operations, can’t run DML queries, and can’t execute remote functions. It reads, reasons, and answers. It does not write to an ERP. So the credit-memo workflow is not the data agent acting; it is a bespoke multi-agent system assembled in the Agent Development Kit, with custom tools doing the writing. The guidebook fuses a read-only analytics agent and a hand-built write-capable agent into one frictionless scene and calls the whole thing “act.” The productized act is a read. The write is something you build.
Now follow the consequential record in that built workflow. The memo lands in the ERP — the system of engagement. It is signed and filed. Ask the examiner’s question: where is the record of why — this credit, this vendor, on what state of the account, under what authority, against what precedent, correlated with the agent’s identity at the moment it decided? That record is generated only at the decision boundary, where the reasoning and the authority are live, and nothing in the depicted stack stands there to capture it. The output is saved. The decision is not.
This is not a Google shortfall. It is the same place AWS and Databricks stop. An agent acting on a Context relationship leaves a governed access log, not a decision record. An agent acting on an LTAP row leaves a committed transaction, not the authority behind it. The act produces an output and persists it. “Act,” across all three, has quietly come to mean save the output.
What the stack records instead
Start with what the data agent does surface, because it is more than nothing and the precision matters. The agent shows its work: it returns the generated SQL, a “thinking process,” and a summary of the why behind the numbers, and recent releases stream still more of its reasoning into the response. But read what that reasoning is about. It explains an answer — why these rows, what query produced them — surfaced to the user in the moment and kept as conversation history. It is the reasoning behind a read. It is not a persisted, tamper-evident record of a consequential decision, because the product doing the reasoning does not take consequential actions. The agent explains its reads; it does not record its decisions.
What the platform persists instead is telemetry. BigQuery agent analytics streams agent activity — interaction events, conversation traces, tool usage — into an agent_events table through the Storage Write API, captured by ADK plugins or LangGraph callbacks, so teams can run root-cause analysis, rank agents, and debug quality. That is call-audit and performance observability, and it is useful. It records which tools the agent called, how much it spent, how it performed. Knowing that the agent invoked a tool is not knowing why it was authorized to reach the conclusion the tool served. Memory Bank persists the other half — synthesized long-term facts and user preferences, with Sessions holding the raw event log — which is operational memory, not a decision record either.
The same shape holds across the platform. The MCP Toolbox for Databases lets agents query enterprise data in place, governed by IAM, without moving it — governed fetch, the read path by another name. The runtime is Vertex AI Agent Engine, with managed Sessions and Memory Bank now generally available; the context is Knowledge Catalog, a Gemini-powered relationship graph. Each piece is strong, and together they make Google the most formidable read-path and coordination stack of the three — native inside BigQuery Studio, a real transactional system of record beneath it, an owned model, the most finished managed runtime in the market. None of which changes the verdict, because none of it stands at the decision boundary. The most vertically integrated column in the market owns everything up to the boundary and stops there.
Why three independent stacks landed in the same place
Three different companies, three different architectures, one identical omission. That is not coincidence, and it is not a roadmap gap any of them forgot to close. It is structural. The read path is a property of the data: an agent’s need to discover, understand, and retrieve what the enterprise already holds can be satisfied by a sufficiently capable store, and all three just demonstrated how completely. The decision is not a property of the data. The reasoning, the authority, and the precedent do not exist until the agent produces them, at the moment of action, in the runtime where it runs. A store can persist a decision record. A store cannot originate one — and saving the output is not the same as recording the decision.
So when a vendor finishes the read path and names it “act,” the write path is not closed but renamed: “act on the data” stands in for “capture the decision,” and because the first half is true, the substitution is easy to miss. Grant all three vendors their verb, and the missing half is the same every time.
It is worth stating plainly what that missing half is, because the gap is easy to wave away. A decision record is not telemetry, not a transaction, and not a trace. Telemetry says the agent ran; a transaction says the data changed; a trace says which tools were called. A decision record is the authoritative capture of the decision itself — the state observed, the authority exercised, the reasoning applied, the precedent referenced, the identity acting, and the action committed — bound together as one event at the moment of action. The fragments exist in every stack: prompts, tool calls, IAM entries, conversation history, event streams. The authoritative event exists in none. Reassembling a decision from those fragments after the fact is forensics; capturing it when it is made is a record. That difference is the whole argument.
Across AWS, Databricks, and Google, “act” has been redefined to mean persist the result. The output is saved. The decision is not — captured by none of them as a first-class record, persisted nowhere as an authoritative event, recoverable only by reassembling fragments of telemetry after the fact.
The more complete the read path becomes, the easier it is to mistake output persistence for decision capture. A stack that retrieves, reasons, governs access, and saves the artifact looks finished — and the one thing it does not do is the one thing hardest to notice missing.
