The old stack is collapsing, and unification is the reason AI, agents, and cost optimization finally work.
Nine specialized systems, collapsed into one AI Operating System.
Every enterprise data stack was built the same way: one system at a time, each solving one problem, each bolted on after the last one stopped being enough. File storage for the shared drives. Object storage for the backups and the lake. Block storage for the databases. A data warehouse for BI. A vector database because the AI team needed one. A Kafka cluster because someone needed events in real time. An orchestrator because now there are agents that need to call all of it. Nobody designed this stack. It accreted.
For twenty years that was fine, because the “thing” being built was a report, a dashboard, a nightly batch job. Slow glue between systems was an inconvenience, not a blocker. AI changes the arithmetic. An agent doesn’t run once a night. It runs continuously, reasoning, retrieving, writing, calling tools, and waiting on every hop of that glue. The stack isn’t the plumbing behind the product anymore. It is the product’s ceiling.
A protocol, a database, an event bus: none of them are the thing a business actually wants. They’re the thing that enables the thing, the layer nobody notices until it’s gone, the plumbing that decides whether the real work (training a model, running an agent, closing the books) is even possible. That’s why the old stack is collapsing. Once enough of those enabling layers get unified into one system, every piece of infrastructure that used to exist only to move data between two other systems simply stops being necessary. That’s the argument behind what VAST calls the VAST AI Operating System, and it’s worth being blunt about what “unification” actually buys you, because it isn’t a tidiness argument. It’s a latency, cost, and capability argument.
The protocol wars are over, because there’s only one namespace left
For decades, “which protocol” was a decision that shaped an entire architecture. File (NFS/SMB) for shared access. Object (S3) for scale and cheap durability. Block (NVMe/TCP, iSCSI) for databases and low-latency transactional workloads. Each came with its own storage system, its own access controls, its own failure domain and, critically, its own copy of the data. Move data between them and you were, literally, copying it: new bytes, new consistency problems, new staleness windows.
VAST’s DataStore collapses that decision by making it unnecessary. It’s a single, exabyte-scale namespace that speaks file, object, and block (native NVMe/TCP closes the one protocol gap that used to force databases and VMs onto a separate SAN), plus streaming and table access on top. The same bytes are addressed as a file by a training job, as an object by a data-lake tool, as a block device by a transactional database, and, as we’ll get to, as a topic by a streaming consumer. Nothing is converted, replicated, or synced to make that work. It’s the same data, accessed differently depending on who’s asking.
Why does this matter for AI specifically? Because AI pipelines are the worst-case scenario for a fragmented stack: raw files become training shards, training shards become checkpoints, checkpoints get served via inference, inference logs get vectorized, vectors get queried by an agent that writes its findings back as structured records. In a legacy architecture, every arrow in that sentence is a network hop between systems, an ETL job, and a reconciliation problem. In a unified namespace, it’s a permission check.
The architecture underneath the promise
Unifying protocols on paper is easy. Unifying them without collapsing performance is the hard engineering problem, and it’s the part most “unified” platforms quietly fail at. VAST solves it with DASE, Disaggregated, Shared-Everything architecture. Stateless compute nodes and NVMe/QLC flash storage nodes are fully decoupled and connected over an RDMA/NVMe fabric, so every node, whether it’s serving a file read, running a SQL query, or executing a Python function for an agent, has equal, direct access to the entire global dataset. Nothing is sharded to a node. Nothing is “local” in a way that creates a hot spot or a blast radius.
That matters because it’s what lets compute and capacity scale on completely different axes. Need more GPUs for training? Add compute nodes. Need more exabytes for retention? Add storage nodes. You’re never buying storage you don’t need to get compute you do, or the reverse, which is the opposite of how most legacy SANs and hyperconverged systems are priced and sized. DASE is the physical reason the protocol unification above doesn’t come with a performance asterisk.
It’s not just the storage protocol. It’s the database, the agent runtime, and the event bus too.
Here is where the old-stack-collapsing argument gets bigger than storage, and where most people underestimate what VAST is actually building. Protocol unification solves where your bytes live. It doesn’t, by itself, solve what happens to those bytes. That’s where four more engines come in, all running against the same DataStore, none of them requiring a copy of the data to do their job.
DataBase turns raw files into AI-ready structure without a separate ETL pipeline. Unstructured content is chunked and embedded into vectors, structured content is organized into queryable tables, and both are queried in place, by VAST’s own benchmark 20 times faster than Iceberg-based analytical stacks.
Event Broker is a Kafka-API-compatible streaming engine, but stateless and built into the platform rather than bolted alongside it. It streams event topics directly into DataBase as queryable SQL tables, and VAST has published benchmarks in the hundreds of millions of messages per second on a single cluster, an order of magnitude past a like-for-like Kafka deployment, with no separate broker cluster to operate.
DataEngine is the compute fabric that reacts to all of this: serverless Python functions and containerized engines triggered directly by data or event changes, running on the same stateless nodes that serve everything else. A file lands, a function fires, a table updates, and no orchestrator has to glue those separate systems together.
InsightEngine and AgentEngine are what make this “agentic,” not just “unified.” InsightEngine turns unstructured video, audio, and documents into embeddings and metadata automatically. AgentEngine is the layer that runs the agents themselves, checkpointing their memory and reasoning state so long-running tasks survive failures, exposing a governed toolbox over the Model Context Protocol, and logging every tool call, prompt, and decision for audit.
Five engines. One copy of data. That’s the sentence that should reframe how you think about “unification.” It was never really about storage.
Why this is the precondition, not a feature
Three forces are converging on enterprise data infrastructure right now, and each one independently breaks the fragmented stack.
AI agents don’t tolerate glue. A dashboard refreshing overnight can absorb an ETL delay. An agent mid-reasoning cannot. Every hop to a different system for context, memory, or a tool result is latency the agent burns while someone, or something, waits on it. Industry surveys on agentic AI point to exactly this: integration friction and agents’ inability to write results back into systems of record are cited as leading causes of stalled deployments, ahead of model quality itself. The bottleneck isn’t the model. It’s the distance between the model and the data.
Cost optimization stopped being about discounting and started being about elimination. You cannot discount your way out of running nine specialized systems: a file NAS, an object store, a block SAN, a vector database, a data warehouse, a Kafka cluster, an ETL layer, a feature store, and an agent orchestrator, each with its own licensing, its own operations team, its own hardware refresh cycle, and its own copy of data sitting idle in three places at once. The only way to meaningfully cut AI infrastructure cost is to stop paying for the seams. VAST’s own figures put the TCO reduction from consolidation at roughly 60 percent, and that’s before counting the engineering hours no longer spent keeping five systems in sync.
Data movement is the actual enemy, not compute cost. Every copy is a staleness risk, a security boundary to re-govern, and a delay measured in ETL-cycle time rather than milliseconds. The fastest data movement is the movement that never has to happen, because the consumer and the data were always in the same place.
None of these three forces is really about storage. They’re about whether infrastructure can keep up with a workload that reasons continuously instead of running in batches. Protocol unification, the DASE architecture, the database engine, the event broker, and the agent runtime aren’t five separate products cross-sold together. Each one is the thing that enables the THING one layer up. Put all five together and there’s only one honest way to describe what’s happening. The old stack is collapsing, into one namespace, one engine, one place to run AI.
Related on Lots of Data: From VM Sprawl to Agent Sprawl · Agent Sandboxes Storage Trends · VAST AI OS API Documentation Hub