Enterprise AI is becoming very good at consuming budgets before it becomes good at producing dependable answers.
The problem is not a shortage of intelligence. It is that we are trying to apply AI at enterprise scale with architectures that are too expensive, too centralized, and too tolerant of being almost right. In production, “almost right” is where the trouble starts. A false positive can move money, misprice risk, block a legitimate customer or send an automated process down the wrong branch before anyone notices.
The answer, in our view, is to stop treating enterprise AI as one enormous model waiting to consume every problem placed in front of it. Enterprise AI should be built as a network of specialized models, not a single model expected to do everything.
Enterprise AI Needs Specialized Models, Not One Giant LLM
That is why I do not think enterprise AI will ultimately be organized around a single omnipotent model sitting on top of a giant centralized data platform. It will look much more like a network of specialized small language models and agents, each designed for a particular domain and working together against a shared, continuously changing body of enterprise data.
A trading model should understand trading. A wealth-management model should understand portfolios, suitability and client history. A supply-chain model should understand inventory and logistics. A security model should understand telemetry and risk. They do not all need the same model, the same context or the same amount of compute.
The rational way to build this is to decompose the problem rather than try to eat the elephant in one bite. That decomposition also has important economic consequences. Not every request requires rocket-fuel token consumption: a narrow task can run on a smaller model, with a smaller context and much lower inference cost, while a more difficult task can route to something larger. Otherwise, general-purpose intelligence becomes general-purpose overhead.
Agent Swarms Turn Database Concurrency Into an AI Problem
Once you build AI this way, however, the database architecture becomes even more important because agent swarms create enormous concurrency.
One AI agent reads a customer position while another updates it. A third is waiting for that update before making its next decision, while a fourth may be calculating risk against the same position. The value of the entire system depends on those agents operating against the latest state of the business rather than a collection of slightly different historical versions of reality.
At that point, latency stops being an abstract benchmark and becomes a direct cost of completion. If an agent has to wait for a write to propagate before another agent can act on it, the delay compounds through the workflow. One slow handoff becomes five slow handoffs; five agents become fifty. The neat diagram of an agent swarm starts to resemble an old telephone exchange at rush hour, intelligence everywhere, wires crossing everywhere, and everyone waiting for somebody else to finish talking. At that scale, the database becomes part of the control plane.
The database underneath it has to sustain massive concurrency while keeping reads and writes synchronized at operational speed. That has been one of the fundamental design principles behind SingleStore: a distributed SQL database built for high-concurrency transactional and analytical workloads in the same engine. As agentic systems create more simultaneous reads, writes and decisions, that architecture becomes increasingly important.
Open Data and Apache Iceberg Preserve Enterprise Data Freedom
I’ve written before about why Iceberg needs an open catalog rather than another walled garden. The agentic AI architecture makes that argument more important, not less.
We do not believe every byte of enterprise data needs to be physically relocated into one proprietary platform before it becomes useful to AI. Enterprises already have enormous investments in data lakes and open formats such as Apache Iceberg. The architecture should meet that data where it is, while allowing high-value operational data to live in the engine where agents can act on it with very low latency.
That gives enterprises something I think will become increasingly important: data freedom. The model can change, the agent framework can change, and the specialized SLM can change while the data remains in open formats. The operational database can serve the workloads that require real-time consistency and concurrency, and each component can evolve independently.
Composable AI Will Beat the Enterprise AI Monolith
That is very different from constructing AI as one vertically integrated monolith in which the data platform, intelligence layer and execution environment are tightly coupled. Monoliths can make the first architecture diagram look simpler. They are convenient at first, expensive forever.
The advantage will come from an architecture that can coordinate thousands of specialized models and agents against fresh enterprise data, without forcing every task through the same model, the same compute profile, or the same proprietary stack. That is where speed, accuracy, cost control and data freedom start to reinforce each other.
.png?width=24&disable=upscale&auto=webp)
