The Real-Time Problem Hiding Inside Your AI Data Problem

Most agentic AI pilots don’t fail because the data is wrong. They fail because it arrives too late, in the wrong place, with no safe way to act on it.

DBTA’s latest research puts a number on something most data leaders already feel. 59% of organizations are piloting or scaling generative AI. 37% already have agents in production. And 60% lose half or more of their pilots before deployment.

Most of those failures trace back to data.

The industry reads that as a quality and governance story. Fair enough — bad data produces bad answers. But there’s a second failure mode, and it only shows up once agents leave the notebook: data that is accurate, well governed, and completely unreachable at the moment a decision has to be made.

Agents, actions, and inconsistent data

Ask a model to summarize last quarter and it barely matters when the data arrived. The numbers are closed. Nobody is waiting on the answer.

Now give an agent the authority to reroute a shipment, adjust a bid, or pull a device off the network. That isn’t analysis anymore. It’s a control loop — and control loops are judged on two things: how quickly they see the world, and whether they can see what their own actions did to it.

Most enterprise data architecture was built for the first job. Warehouses. Nightly pipelines. Point-to-point APIs added one integration at a time, each of them optimizing the happy path.

The stitched stack

So teams bolt real-time on.

A queue here. A Websockets connection there. A cache, a sync service, a tunnel out to the plant floor. Each choice is defensible on its own — someone had a deadline, and the piece they added solved the problem in front of them.

Together they hand every agent an N-squared connectivity problem. Each hop brings its own auth model, its own retry semantics, its own ordering guarantees. An agent that reads state from six systems and writes to four is now the integration point for ten different sets of assumptions about what happens when something goes wrong.

The pilot works beautifully against one data source in one region. It dies on contact with the rest of the enterprise.

The symptoms are quiet. An agent decides on inventory figures that were current forty minutes ago. A second agent, reading a different cache, reaches the opposite conclusion. Nobody can say which one saw what.

That last part is the one that ends programs. Not the wrong decision — the inability to explain it afterward.

Read the cost of the stitched stack: why AI stalls before it reaches the edge →

What agents actually need underneath them

The fix is architectural, not incremental. A connectivity layer for agentic AI needs a short list of properties.

Location independence. Agents should address data by what it is, not where it lives. Subject-based addressing lets an agent request inventory.sku.4471 without knowing which service, region, or edge site answers today. Move the workload; the address doesn’t change. This sounds like a small thing until you try to migrate a service that forty agents depend on.

Streams and requests in one system. Agents both subscribe to events and ask direct questions. Running separate stacks for each doubles the operational surface and splits the governance story in two — you end up auditing your streaming platform and your API gateway with different tools and different answers.

Persistence where data is produced. Not everything should travel to a central lake to become useful. Retain and replay at the edge, the region, and the core, promoting only what needs to move. A factory that loses its uplink shouldn’t lose its ability to operate, and it shouldn’t lose the record of what happened while it was dark.

Identity per agent, not per network. Every agent gets its own credentials, scoped to specific subjects, individually revocable. Zero trust stops being a perimeter retrofit and becomes the default posture. When an agent misbehaves, you revoke one identity rather than rotating a shared secret across a fleet.

Observability by construction. When traffic traverses one fabric, lineage, audit, and replay become properties of the system instead of custom instrumentation bolted onto every pipeline.

Where governance and real-time stop being separate projects

That last point deserves more than a bullet.

Most organizations run their AI governance program and their real-time architecture program as separate initiatives with separate owners. They meet at the steering committee and nowhere else.

They shouldn’t be separate. When permissions are per-subject and per-identity, “which agent read which record, and when” is a query rather than an investigation. When streams are replayable, you can reconstruct why an agent acted — not infer it from model logs, but replay the exact sequence of messages it saw.

Explainability is much easier to defend when it starts at the data plane. The alternative is trying to reverse-engineer intent from an inference log after the fact, which is where a lot of AI governance programs quietly discover they can’t answer the questions they promised to answer.

Connective technology, not another silo

This is the problem NATS was built to solve.

As a CNCF project, NATS provides a single connectivity layer — messaging, streaming, request-reply, key-value, and object storage — spanning cloud, on-premises, edge, and device, secured by per-identity credentials and operated as one system. Synadia adds the tooling, multi-tenancy, and global infrastructure to run it at enterprise scale.

This is already how AI runs at scale. NVIDIA Cloud Functions routes GPU inference requests across regions on a Synadia-managed NATS supercluster. Rivian partners with Synadia to scale and optimize the NATS architecture connecting its vehicle fleet.

The organizations reaching production aren’t the ones with better models. They’re the ones whose data shows up on time, everywhere it’s needed, with proof of where it came from.

Suggested next steps

The Edge Autonomy Gap — research with 500 practitioners on whether edge infrastructure is ready for AI.
Living on the Edge — edge-to-core messaging patterns.

A version of this article appeared in Enterprise AI World Sourcebook 2026.