Next week I fly to Las Vegas for Fiserv Forum for the first time. The general session will almost certainly crown agentOS, the agentic AI operating system Fiserv launched in May, and the room will nod.

I am not going for the nod. I am going with one question, and it is the same question I bring to every vendor keynote.

Announced is not shippable. The slide can show a clean, layered stack while the thing underneath it is a pilot you cannot join and an SDK that does not exist yet. The only part of any of this worth my flight is the part I can put my hands on: docs, a sandbox, a public API, today. So this is the read I am doing before I land, layer by layer, separating what ships from what gets pitched.

The stack is genuinely coherent, and that’s worth saying first

Start with credit where it is due, because the architecture is real and it is well ordered.

At the bottom sits Finxact, a cloud-native, API-first, event-driven core. It is a real-time system of record, not a nightly-batch ledger, and its defining trick is a temporal database: it reconstructs an as-of view of any account or event without a cutoff or an offline batch job. Accounts are composable, built from positions with their own sub-balances and behaviors. The core is asset-agnostic, so a crypto balance is just another position next to a checking balance.

On top of that sits the data layer, Data Compass, built on Snowflake with Alation carrying lineage and governance. Its job is to know what data came from where and to serve a governed customer-360 to whatever reads it.

And on top of that sits agentOS, the execution layer where AI agents act across core, payments, issuer processing, and servicing.

Each layer earns the next. You cannot run a real-time agentic workflow on a core that only knows last night’s balance. You cannot govern an agent’s decision if you cannot trace the data it read. The temporal, fully addressable core is the thing that makes the governed agent layer even plausible. That is not marketing. That is the correct dependency order.

Now the catch, and it is a big one. This is the clean-slate picture, the stack as it looks on a fresh build. Almost nobody runs it that way.

Most banks on Fiserv don’t run that stack

Here is what the slide leaves out. The clean, temporal, real-time core is Finxact, and Finxact is the newest thing Fiserv sells. Most banks running Fiserv are not on it. They are on the cores that have run the industry for decades: Premier, Signature, Precision, DNA, Cleartouch, Portico over on the issuer side. Batch-era systems of record, wired into every downstream process, and close to immovable. Ripping one out is a multi-year, bet-the-bank program, which is exactly why so few banks ever finish one.

So Fiserv does the sensible thing and does not ask them to. It sells Finxact as a sidecar. You stand the modern core up next to the legacy one, run a digital brand or a single product line on it, and stitch it back to your system of record through an integration layer. Consumption-priced, incremental, risk-contained. It is a smart migration story, because the honest alternative for most banks is no migration at all.

But look at what that does to the beautiful stack. The temporal, CRUDL, real-time story holds where Finxact is deployed. Everywhere else, the layers above are sitting on a batch-era core reached through an integration seam. Data Compass is federating from a system that still settles overnight. agentOS is acting through an adapter, not against a live ledger. The dependency order that made the whole thing elegant only holds on the greenfield.

Fiserv is building the future. Most of its customers are living in the integration-tax present. Both are true at once, and the gap between them is the part the general session will not dwell on. The sidecar is a good idea. It is also a second core to run, a second set of data to reconcile, and an integration layer to own, for the privilege of getting one product line onto the modern stack.

agentOS is a control plane, and control planes are where lock-in lives

Here is what agentOS is, in plain terms. It is a place to deploy, manage, and scale AI agents across a bank, with governance sold as the headline feature: identity-bound execution, policy enforcement, observability, and traceability. It runs on Amazon Bedrock AgentCore and stays model-flexible through Bedrock, with OpenAI supplying frontier reasoning for select first-party agents. It ships with a marketplace: run Fiserv-built agents, deploy third-party ones, or build your own in the same governed architecture. Four Fiserv agents are named at launch, covering commercial loan onboarding, daily operational reporting, deposit intelligence, and AML triage.

Read that description again and notice what it is. It is a control plane.

Control planes are the most valuable and the most sticky software in any stack. The protocol underneath commoditizes. The agents on top come and go. The governance plane in the middle, the thing that holds identity, policy, and the audit trail, is where the switching cost accumulates. That is the exact pattern I traced in The Agent Control Plane War: whoever owns the plane that governs the agents owns the customer, regardless of whose model is running.

There is a second tell, and I named it in Open at the Bottom, Locked at the Top. Bedrock AgentCore is the open, swappable, commodity layer at the bottom. Model choice is real. But openness at the bottom of a stack has a way of financing lock-in at the top, because the layer you cannot swap is the governance plane you built all your policies and identities into. Model-flexible is a great headline. It is also the part that was never going to be the moat.

None of this makes agentOS a bad bet. A governed control plane is exactly what banks need to get past disconnected pilots. It means the interesting question is not “which model,” it is “whose plane, and can I leave it.”

And there is the floor problem again. agentOS is pitched to run across Fiserv’s platforms, which for the install base means acting over a legacy core through an integration layer, not against the temporal one. A governed agent is only as real-time as the ledger beneath it. Promise the room autonomous, real-time workflows, then wire them to a core that still closes at night, and the governance plane is the easy part. The hard part is that the agent is reasoning over yesterday.

The question I’m bringing to Forum: does governance reach a runtime I own?

I brought one question to Microsoft Build this year, and I am bringing the same one to Forum. I wrote it down in Governance or Containment: does the vendor’s governance attach to a runtime you own, or does it only travel with the vendor’s managed service?

That is the whole ballgame for a regulated shop.

If agentOS governance means the policy engine, the identity binding, and the audit trail live inside Fiserv’s managed environment, then you have rented governance. It works right up until you want to run an agent somewhere else, and then it does not follow you. If instead the governance can reach an agent executing against a runtime the bank controls, that is real. One of those is a platform. The other is a very elegant lease. This is the same instinct behind You’re Renting the Model. Own the Harness.: the durable asset is never the model, it is the runtime and the controls around it.

Identity-bound execution raises the same question one level down. Bound to whose identity? A bank already runs an identity provider and is already fighting to give non-human actors real credentials. If agentOS issues its own agent identities in its own namespace, that is one more identity island to reconcile, which is the gap I mapped in Who Issued the Agent?.

On a legacy-core bank there is a third seam to worry about: the integration layer between agentOS and the core. Its mappings, its transforms, and its audit trail are either yours to run and inspect, or one more thing you rent from the vendor and take on faith. That seam is where a lot of the real governance lives, and it is nowhere on the headline slide.

So here is the single most report-worthy unknown, and the thing I will chase in the Experience Center. 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? Six institutions are co-developing agentOS today. Two are running agents in beta. Nine third-party partners are in the marketplace. That is a strong pilot roster and a real ecosystem signal. It is not the same thing as a developer being able to sign up, read a spec, and ship an agent without a partnership agreement. Which one it is decides whether agentOS is a platform or a program.

Finxact is the layer I can actually touch today

Now the payoff of the announced-versus-shippable test, because one layer passes it cleanly and it is not the headliner.

Finxact is the most publicly documented layer in the whole stack. Sign up for a Developer Studio account and you are auto-registered for core banking APIs with a free shared test environment. There is a console app to explore the platform, the API surface is designed for consistency with Stoplight, and the core exposes what Fiserv calls full CRUDL access, create, read, update, delete, and list, across customer and transaction data.

That last detail matters more than it sounds. A CRUDL-complete, real-time API over the core is exactly the tool catalog an agent layer needs. I argued in The API Catalog Is the Tool Catalog that in the agent era your API catalog quietly becomes the set of actions your agents can take. Finxact is that catalog, addressable and documented, which is precisely why agentOS can plausibly act across the core. The temporal database is the differentiator that makes it trustworthy: an agent, or an auditor, can ask what the balance was at 2:14pm and get an answer, not a batch approximation.

So the contrast writes itself. agentOS and the stablecoin are announcements with pilots. Finxact is a sandbox key you can cut before you board the plane. If you want to evaluate this stack with your hands instead of your ears, you start at the bottom, today, and you do not need a badge for Vegas to do it.

One honest caveat, because it is the whole point of this piece. Touching Finxact in a sandbox is not the same as running it in production. The sandbox is a clean, modern core with nothing behind it. Production is the sidecar: a second core standing next to the one you cannot leave, plus the integration layer that keeps them honest. The API is shippable today. The migration is a program, and for most banks it has barely started.

FIUSD rides the ledger, and the card is where it gets real

The stablecoin is the cleanest proof that the layering was deliberate. FIUSD, the “Financial Institution U.S. Dollar,” is a dollar-pegged, bank-friendly stablecoin that Fiserv built for banks to offer tokenized-dollar balances without pushing deposits out of their own ecosystem. It went live this summer.

Because the Finxact core is asset-agnostic, FIUSD is not a bolt-on. It rides the same ledger as just another position. That is the asset-agnostic design paying its bill. The infrastructure comes from Paxos and Circle, the web3 layer is Solana, and delivery is an SDK that drops into existing Fiserv customer-facing platforms rather than a rip-and-replace. A Mastercard tie-up puts it in reach of a very large merchant network, and Fiserv is also exploring deposit tokens as a more capital-friendly cousin.

The regulatory ground shifted underneath all of this. The GENIUS Act, signed into law in July 2025, gave payment stablecoins a federal framework for the first time. A year ago a bank stablecoin was a compliance dare. Now it is a product with rules.

The part I find most interesting is where FIUSD meets agents. A programmable, bank-issued dollar plus an agent authorized to move it is agentic commerce with real money, and that is a harder problem than a demo. I worked through the accountability side of it in When the Agent Reaches for the Card: the interesting question is never whether the agent can pay, it is who authorized the payment and how you prove it later.

This ships into a market that wants proof, not slideware

Now the part the keynote will not dwell on, and the reason the announced-versus-shippable test matters more this year than last.

Fiserv is pitching this stack from a position of visible pressure. When agentOS launched in May, the stock was trading near a 52-week low, around the low fifties, reportedly down roughly seventy percent over the prior year and sitting well below its 200-day average near ninety. Leadership added two chief revenue officers and a business-development executive to lift sales, around the same window the agentic bets went public. Management reaffirmed its 2026 guidance, and the long-term story points at roughly twenty-two billion in revenue by the end of the decade.

This is market context for framing, not investment advice.

Here is why it belongs in a developer’s read. agentOS reaching general availability at Forum is not only a product milestone. It is the “the AI bets are real and shipping” proof point to a market that has stopped taking modernization on faith. That pressure is a good thing for anyone in the audience holding a skeptic’s checklist. When a company needs to show proof, the gap between a demo and a sandbox key is exactly where the truth lives. The harder the pitch, the more the shippable-today question earns its keep.

What I’ll do on the ground

So here is the plan, and it is not the keynote.

Keynotes are built for executives. My value is fifty feet away, in the Experience Center, where you can corner a solutions engineer and ask the questions a slide never answers. What is the API surface. What is the auth model. What are the rate limits. Is this public or partner-gated. The pre-Forum user groups on Monday are where the unfiltered roadmap talk happens, so that is where I start.

And I will run every shiny thing through the same filter. For agentOS, for FIUSD, for the core-modernization pitch, one question: is there documentation, a sandbox, and a public API today, or is it a client-only pilot dressed as a product?

I might be wrong about the gated part, and I would be happy to be. Maybe the agentOS SDK and an agent spec ship right at Forum and the openness question answers itself in my favor. That is the outcome I am rooting for, because a genuinely open banking agent platform would be a bigger deal than any single agent on it. I will report back either way.

The bottom line before I board

The stack is real. The dependency order is right. The temporal core, the governed data layer, the agent control plane, the stablecoin riding the ledger, that is a coherent bet, and coherence is rarer than it should be.

The question is how much of it you can build on without a signed pilot agreement, and on a core you can reach in real time. Announced is a promise. Shippable is a sandbox key. And even the shippable core is a sidecar most banks have not stood up yet, bolted next to a batch-era system they cannot leave. The future is real. The reality, for most of the room, is an integration layer over an overnight core.

That gap is not a knock on Fiserv. It is the honest shape of modernizing a bank, and it is the thing worth watching more than any demo. I will know a lot more by Wednesday.

---

The companion read is Governance or Containment, the same question one conference earlier: whether a vendor’s governance can reach a runtime you actually control. This is that question wearing a Fiserv badge.

If you’re going to be at Forum, or you’re running this exact evaluation on your own stack, I want to compare notes before the verdict gets written. Find me on X @orestesgarcia or LinkedIn /in/setsero.