The agent can see the order. It can’t see the customer.
Picture an AI agent deciding whether to approve a refund under $500 without a human. To get it right, it needs three things in the same second: the order’s current state, the customer’s two-year return history, and the refund policy with its permission limits. In most enterprises those sit in three systems, refreshed on three schedules. So the agent makes a sensible decision from a picture of the business that is hours, sometimes a day, out of date.
The fix has a name: data convergence. The model is fine. The data is the problem. Bismart’s 15 Data and AI Trends That Will Shape 2027–2028 lists it as trend 5. We would date it earlier, because the major platforms have already shipped it. The open question is whether your Data & AI architecture is built to use it.
What is data convergence, and why does it matter for AI agents?
Data convergence brings operational data, analytical history and business context closer together, so an AI agent can use all three in one decision with less delay and duplication.
It undoes a split enterprises made on purpose. Operational (OLTP) databases handle transactions and analytical (OLAP) systems explain what happened. Nightly ETL batches linked the two, because running both on one engine meant a heavy report could slow down checkout. That suited a person reading yesterday’s dashboard. An agent decides and increasingly acts, so lose any one of its three inputs and the refund goes wrong: stale state means wrong facts, no history means no judgement, and no context means an answer that is technically right and commercially wrong.
The cost is already showing. Gartner predicts that through 2026, organisations will abandon 60% of AI projects unsupported by AI-ready data, and expects more than 40% of agentic AI projects to be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. Agents are also becoming the main users of databases: announcing its roughly $1 billion Neon acquisition in May 2025, Databricks cited telemetry showing that 80% of Neon databases were created automatically by AI agents, rather than by humans.
The platforms stopped waiting
In the last two years, all four of the largest data platforms reached the same conclusion independently: the operational database belongs inside the analytics platform, or wired to it with no pipelines in between.
AWS went first, taking Aurora PostgreSQL zero-ETL to Redshift to GA in October 2024, after the Aurora MySQL version in November 2023. Databricks launched Lakebase in June 2025 after buying Neon. It is now GA with sync tables between Postgres and the lakehouse, and Azure Databricks Lakebase reached GA in March 2026, writing operational data directly to lakehouse storage. Microsoft made SQL database in Fabric GA in November 2025, automatically mirrored to OneLake in a queryable format. Snowflake brought Snowflake Postgres to GA in February 2026, built on its June 2025 Crunchy Data acquisition, and added catalog integration (GA) in July 2026, exposing Postgres tables as read-only Apache Iceberg tables.
The speed is real, too. AWS reports its Aurora MySQL integration handles over 1 million transactions per minute and makes them available in Redshift in under 15 seconds (p50 lag). Databricks says Lakebase adoption has grown at more than twice the rate of its data warehousing product since launch (DBTA).
Five data convergence mechanisms, and the catch with each
Convergence gets sold as one feature. It is really five mechanisms, each removing a different cost and adding a different risk.
- CDC and mirroring cut batch latency between OLTP and analytics. “Near real time” still has a lag, so measure it under peak load, check how schema changes propagate, and have the agent confirm freshness before it acts.
- Zero-ETL integrations remove hand-built pipelines but are easiest inside one vendor. Test that you can export, read and govern your data outside the primary platform before you depend on them.
- Zero-copy on open tables (Iceberg, Delta) remove duplicate copies per engine. Confirm that other engines can really read, write and govern the same tables.
- Operational databases inside the platform (Lakebase, Snowflake Postgres, SQL database in Fabric) remove the wall between app and analytics teams. Confirm that heavy analytics can never slow the transactional path. A core payments ledger may be better left isolated.
- Unified governance (one catalog, one policy model) removes duplicated policies, but only if it covers operational databases and agents, which often borrow a human’s or a service’s credentials.
One cost runs through all five: continuous replication and always-available compute are billed continuously, so tie the spend to the decisions it serves. The list follows Bismart’s framing. The checks are where projects tend to break first, and where data engineering and governance earns its place.
Design your data architecture around the decision
Architecture diagrams used to be drawn by technology category: OLTP here, warehouse there, ML platform somewhere else. Go back to the refund. Each of its three inputs has its own freshness need, and that should decide where each workload runs, rather than the vendor org chart.
The practical route is five short moves. Name the decision and its measurable outcome. Map the state, history and context it needs, and how fresh each must be: seconds, minutes or a day. Place each workload with the mechanism that meets that freshness with the least data movement. Govern once, giving the agent its own identity and the same permissions across operational and analytical data. Then measure the decision’s business result, with pipeline uptime as a secondary check.
Few inputs will truly need second-level freshness. Start with those, because that is where convergence pays for itself first.
How Eastern Enterprise approaches data convergence
The platforms have done their part. They do not decide which decisions matter, how fresh each input must be, or what an agent may do with what it sees.
That is the work our Forward Deployed Engineers do. They embed with your teams and start from the decision: mapping what each agent will decide, choosing the right convergence mechanism for each workload on the platform you have already standardised on, building the context layer of shared definitions, policies and agent permissions, and instrumenting the outcome so you can prove the agent made the right call.
If your agents are still reading yesterday’s data, talk to our FDE team.
