The keynote is loud. The verdict comes from the floor.

I spent this week at Fiserv Forum not watching the general session but working the Experience Center and the user-group rooms, asking the questions a slide never answers. I came in with a stack of them. Two earlier posts framed the priors: Announced or Shippable? read the architecture layer by layer and asked which parts you can actually touch, and agentOS Has to Eat Fiserv’s Own APIs argued that an agent inherits the reliability of everything beneath it. Both of those hold. This post is what the floor added, and it is bigger than either.

The short version: the agent story is real and the direction is right, but announced is not turnkey. And underneath every agent demo sits the problem banks have been failing to solve for years, the one nobody wants to put on a slide because it does not demo well. The data.

Grading the Questions I Brought

Start with the scorecard, because the honest ones are never all green.

Is there a public SDK, an agent specification, and a marketplace submission flow, or is “build your own agent” gated to the co-development partners? This was the single most report-worthy unknown from the first post, the line between a platform and a program. Floor answer: still forming. agentOS is real and the marketplace is real, but the self-serve path where a developer signs up, reads a spec, and ships an agent without a partnership is not something you can point to today. Status: leaning program, not yet platform.

Do the APIs carry contract-level guarantees an autonomous system needs? The second post left five things to check: error semantics, idempotency, end-of-day behavior, beta-to-general-availability breadth, and marketplace depth. Every one of them is unanswerable from the public record. That is not a dodge, it is the finding. When the reliability contract an agent depends on is not documented anywhere you can read without a badge, the honest grade is incomplete.

So: one question leaning the wrong way, five that need a signed engagement before anyone can answer them, and, as it turns out, one much larger question the whole event kept circling without naming. That is an honest scorecard for three days on a conference floor.

Announced Is Not Turnkey

Here is the thing about a vendor keynote in banking. The verb tense is doing enormous work.

agentOS is genuinely public. Fiserv launched it in May, built with OpenAI on Amazon Bedrock, and the release says it is “expected to be widely available by August 2026.” Read that phrase the way an architect reads a statement of work. Widely available is not deployed. It is the start of an implementation program, not the end of one.

Sort what I saw into two honest buckets.

Shipping today, hands-on: Developer Studio with a real sandbox, the OpenAPI surface over the core, the AppMarket, and the Finxact core APIs. You can cut a key and touch these before you board a plane.

Announced, previewed, or on the roadmap: agentOS at real cross-core depth, agent reliability against a legacy core through an integration seam, and agent-to-agent interoperability, which is not on any public Fiserv roadmap I can find. That last absence matters, because agent-to-agent is exactly the interop story the rest of the industry is racing toward.

None of this is a knock. It is the honest shape of a roughly forty-year-old company whose cores trace back to the 1970s, retrofitting an agent layer onto systems of record that were never designed for it. But it does mean the pattern holds, and anyone who has run a core project already knows it: enabling an announced capability in a regulated bank is a project, not a switch. A sidecar core to stand up, an integration seam to own, data governance to satisfy, agent identity to issue, and the batch-window hardening the second post was about. Fiserv continues being Fiserv, and I do not mean that unkindly. An announcement opens a statement of work. It does not close one.

The Same Data Problem, Two Stacks

Now the part the floor made unavoidable, and the reason this is the last post and not the second.

Every agent conversation, at Fiserv or anywhere else, backs into the same wall within about ten minutes: the agent is only as good as the data it can reach, and reaching a bank’s data in a unified, governed form is the thing banks have never finished doing. Watch two very different companies hit that wall and you learn more than either one alone will tell you.

Fiserv owns the core. For its core-banking clients the system of record lives in-house, which sounds like the whole game won. It is not. Owning the ledger is not the same as making it legible to an agent. To do that Fiserv still has to build an aggregation and governance layer, which is Data Compass on Snowflake with Alation carrying catalog and lineage, and an API layer, which is Communicator Open exposing the core over OpenAPI. Owning the data is step zero. The governed, addressable, agent-ready version of it is still a build.

Salesforce is the mirror image, and this is where it gets interesting. Salesforce does not own the bank’s core, so its data platform, Data 360 (renamed from Data Cloud in October 2025), reaches the transactional data by borrowing it. Its Zero Copy model, which shipped in 2024 and carried into Data 360, federates data in place from Snowflake, Databricks, and BigQuery rather than copying it. I wrote about that federation bet in The Zero-Copy Promise, and about the headless decomposition that feeds it in Salesforce Headless 360: The Day One Read. The twist is that for a bank already living in Salesforce, the customer half of the “360” is often already there, built up over years of moving CRM and relationship data into that ecosystem. Salesforce mostly needs to borrow the transactional core. Fiserv already has the core and needs to build everything above it.

I want to be careful here, because it is not a clean comparison and I am not scoring it. Fiserv owns the core only for banks running a Fiserv core. Salesforce is the leading CRM but sits around a fifth of the market, not a majority, so “your customer data already lives there” is only true for the banks it is true for. Both companies are unwinding legacy of their own. And Fiserv’s temporal Finxact core is a real asset Salesforce has no equivalent to. Different customers, different regulatory weight, genuinely different stacks. The point is not who wins. The point is that the two of them, coming from opposite directions, are converging on the exact same problem.

So Whose Data Platform Do You Feed?

Which lands you, the architect, on a decision the keynote will never frame for you.

If your agents need unified, governed, grounded data to be useful, and they do, then someone has to assemble that data. Your realistic options are three. Feed Fiserv’s Data Compass. Feed Salesforce’s Data 360. Or build your own, a lake or lakehouse you control, and make the platforms come to it.

None of these is free, and each one relocates the lock-in rather than removing it. Pick a vendor’s data platform and you have made that platform the thing your agents are grounded in, which is the most expensive software to leave in any stack. That is the control-plane dynamic I traced in The Agent Control Plane War: whoever governs the data your agents reason over owns the relationship, regardless of whose model is running.

Build your own and the question flips into an integration one. How would Data Compass and Data 360 even reach it? On the Salesforce side the answer already exists and it is Zero Copy federation, querying your lakehouse in place. On the Fiserv side it is the same shape you would build for agentOS anyway, Communicator Open over the core and Snowflake underneath the governance layer. Building your own is the most work and the most control, and it is the only option where the grounded context you spent years assembling stays yours when you change your mind about a vendor.

There is no right answer on a slide. There is only the answer that matches how much of your own data destiny you are willing to rent.

The Data Lake Has to Become the Context Layer

Step back far enough and the whole event resolves into one sentence. The bank data problem never went away. AI just made it load-bearing.

For twenty years the unglamorous work of unifying, cleaning, and governing bank data was a cost center you could defer. An agent removes the option to defer. A model with no grounded, governed view of your customer and your ledger does not fail loudly. It fails plausibly, confidently, and wrong, which in a regulated institution is the worst failure mode there is. The data platform vendors have converged on the same language for the fix: the lakehouse has to evolve into a context layer, the grounded substrate an agent reasons over. Read that framing as coming from companies who sell the substrate, and it is still correct. I have argued the same thing from the other side in Context Engineering Is Infrastructure and in Same Person, Five Systems: the context an agent needs is an infrastructure project, and identity resolution across your systems is the part everyone underestimates.

This is where Fiserv and Salesforce actually converge, past the different stacks and the different starting points. Both are really competing to become your context layer. Data Compass and Data 360 are the same move wearing different clothes, a bid to be the governed place your agents get their grounding. Whoever wins that owns the grounding, and the agent surface on top is almost a formality after that.

The Verdict, and Where the Fight Actually Is

So here is the floor verdict, and it is not a victory lap.

Fiserv said the right things. APIs as the foundation, agents as the orchestrators, a real developer on-ramp, the core kept first-party. The architecture is coherent and the direction is right, and coherence is rarer than it should be. But announced is not turnkey, most of the agent depth is a roadmap you would be signing up to implement, and the interop piece the rest of the industry is standardizing on is not even on the board yet.

None of that is the real story though. The real story is that the agent era did not create a new banking problem. It exposed the oldest one. The unresolved wound is not the agent layer, it is everything under it: the governed data, and the identity that has to travel with it when an agent, not a person, is the one asking. The keynote sells the surface. The multi-year fight is the context layer beneath it, and that fight is the same whether the logo on the badge says Fiserv or Salesforce. Solve the data and the agents get easy. Skip it and no demo will save you.

The data was always the problem. It just finally got a deadline.

---

This is the third and final dispatch in the Fiserv Forum 2026 series. The first, Announced or Shippable?, read the stack layer by layer before the doors opened. The second, agentOS Has to Eat Fiserv’s Own APIs, argued that reliability flows up from the boring bottom of the stack. This one closes the loop, and points at the layer under all of it. For what comes next, the companion read is The Agent Control Plane War, because the context layer is where the next round of lock-in is being decided.

If you were on the floor and read it differently, especially on whether the data platform is a bid for the context layer or I am seeing a pattern that isn’t there, I want to hear it. Find me on X @orestesgarcia or LinkedIn /in/setsero.