VAST is the most architecturally distinct vendor in this assessment series because it deliberately collapses traditionally separate infrastructure layers into a single platform. The VAST AI Operating System unifies storage (DataStore), metadata and vector database (DataBase + Catalog), global namespace (DataSpace), serverless compute (DataEngine), retrieval (InsightEngine), agent runtime (AgentEngine), governance (PolicyEngine), and model lifecycle (TuningEngine) under one authority boundary. Where Dell assembles 5–7 partner technologies to span Layers 1A through 2B, VAST provides a vertically integrated alternative with no inter-layer seams.
The Polaris control plane and PolicyEngine are the most significant Layer 2C signals from any infrastructure vendor. Polaris abstracts infrastructure location, allowing AI pipelines to operate against a single logical environment across on-prem, neocloud, and public cloud. PolicyEngine provides inline policy enforcement governing agent access to shared memory, tools, knowledge bases, and other agents. Together, they represent the clearest ‘middle-out’ approach to the control plane problem — building Layer 2C from the data layer up.
The DAPM trade-off is stark: VAST eliminates seams by collapsing authority into one vendor. The enterprise gains architectural coherence and eliminates integration risk. But the entire data plane, retrieval plane, agent runtime, AND emerging governance plane become a single Ceded dependency. If you run VAST, you run VAST for everything. There is no substitutability at any individual layer.
The $30B valuation, $4B+ in bookings, $500M+ CARR, and 1,000+ enterprise deployments validate market traction. The CoreWeave anchor ($1.17B commercial agreement) validates hyperscale credibility. The CNode-X partnership with NVIDIA (GPU-accelerated servers through Cisco and Supermicro OEMs) validates compute integration. But the product-market fit question for the 4+1 model is whether enterprises will accept total data-plane vendor dependency in exchange for architectural simplicity.
VAST is building the thing the 4+1 model says is missing. Whether the enterprise will buy it from a storage vendor is the open question.
Layer-by-layer status: Layer 0 (Software-Defined), Layer 1A (VAST Strength), Layer 1B (VAST Strength), Layer 1C (VAST Strength), Layer 2A (Partial), Layer 2B (VAST AgentEngine), Layer 2C (Emerging), Layer 3 (+1) (Focused Ecosystem).
Assessment framework: 4+1 Layer AI Infrastructure Model. Scoring model: Decision Authority Placement Model (DAPM) — Retained, Delegated, Ceded, or Absent. Published by The CTO Advisor LLC. Author: Keith Townsend. Date assessed: May 21, 2026. Version: v1.0 — Initial Assessment.
Raw compute, networking, and acceleration fabric
Disaggregated Shared-Everything: separates stateless compute (CNodes) from persistent storage (DNodes/DBoxes) over an NVMe-over-Fabrics network. Every CNode mounts every SSD in the cluster at boot time — no node ‘owns’ any particular data. Eliminates east-west chatter between nodes, shard coordination, and per-node metadata bottlenecks. ACID transactional semantics via global Element Store. Scales linearly from TB to EB. This is VAST’s core IP and the foundation for every layer above.
Process all user requests: file/object serving (NFS, S3), database queries, erasure coding, data reduction, vector search. Fully stateless — containerized VAST software. Add CNodes to scale performance independently from capacity. Can run on dedicated servers or as containers within EBoxes. ConnectX-7/8 network adapters for 200GbE+ RDMA connectivity.
NVMe-oF storage shelves connecting SCM and hyperscale flash SSDs to the NVMe fabric. DBoxes are fully redundant (no single point of failure) — redundant DNodes, NICs, fans, power. DNode containers route NVMe commands between SSDs and CNodes. Add DBoxes to scale capacity independently from performance.
Converged form factor: runs CNode + DNode containers on the same industry-standard x86 server. Introduced in VAST 5.2. Each EBox runs three containers (1 CNode, 2 redundant DNodes). Enables deployment on hyperscaler server configs, cloud VM instances, and OEM servers (Cisco, Supermicro). The CNode in an EBox does NOT own the SSDs in that EBox — all SSDs are equally accessible by all CNodes across the cluster.
New node type adding GPU acceleration directly into VAST clusters. First time GPUs are embedded in the data platform rather than consuming it externally. Supermicro config: CloudDC AS-1116CS-TN (storage) + SYS-212GB-FNR 2U (compute) with 2x NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs, AMD EPYC 9005 CPUs. Follows NVIDIA AI Data Platform reference architecture. OEM partners: Cisco, Supermicro (shipping); HPE, Lenovo (in progress). Dell notably absent.
High-bandwidth RDMA networking (200GbE+ via NVIDIA ConnectX-7/8) connecting all CNodes to all DNodes/SSDs. BlueField-3 DPUs + Spectrum-X switches for zero-copy data paths. This is the fabric that makes ‘shared everything’ possible — every compute node sees the entire storage namespace over NVMe-oF.
RTX PRO 6000 Blackwell Server Edition GPUs in CNode-X configurations. GPU acceleration for vector search, data manipulation, inference, and analytics within the VAST platform.
Network adapters in every CNode providing RDMA connectivity to the NVMe fabric. This is the physical layer that enables DASE’s shared-everything model.
Data processing units in CNode-X for storage-side compute offload. Enable zero-copy data paths between GPU memory and NVMe storage.
Ethernet switches for the NVMe fabric and GPU cluster networking. Same Spectrum silicon that Dell brands as PowerSwitch.
Integrated directly into VAST software services on CNode-X. GPU acceleration for vector search (cuVS), data manipulation (cuDF), and networking (DOCA).
VAST’s Layer 0 is architecturally the inverse of Dell’s. Dell manufactures and sells the physical servers (PowerEdge, PowerRack) but depends on NVIDIA for the software runtime. VAST designs the software architecture (DASE) but depends on OEM partners (Cisco, Supermicro, HPE, Lenovo) for the physical servers. The DASE architecture is VAST’s genuine Layer 0 differentiator. No other vendor has a shared-everything model where every compute node can directly access every SSD over NVMe-oF with ACID guarantees. Dell’s PowerScale and ObjectScale are traditional storage architectures (even if highly performant). VAST’s DASE fundamentally changes how compute and storage relate — they share the same data structures, the same namespace, and the same transactional model. The CNode-X evolution is architecturally significant: it dissolves the boundary between ‘storage infrastructure’ and ‘compute infrastructure.’ In Dell’s architecture, PowerEdge servers run NVIDIA’s inference runtime and PowerScale provides separate storage — data moves between them. In VAST’s CNode-X architecture, GPUs embedded in the data platform accelerate data services AND serve inference — no data movement because compute and storage are the same system. The EBox model is worth noting for the procurement story: ‘Gemini model’ pricing means certified hardware is supplied at cost from the manufacturer, with VAST software as a capacity-based subscription. VAST guarantees software compatibility with new and older hardware for up to 10 years. This is a fundamentally different commercial model than Dell’s (buy the server, license NVIDIA AI Enterprise separately, integrate yourself). The NVIDIA dependency at Layer 0 is real but different from Dell’s. Dell depends on NVIDIA for GPU silicon AND the entire software stack above it (Run:ai, NemoClaw, OpenShell, AI Enterprise). VAST depends on NVIDIA for GPU silicon and networking silicon but retains authority over the software architecture. If NVIDIA changes its GPU roadmap, both Dell and VAST are affected. But if NVIDIA changes its software roadmap (NemoClaw, AI Enterprise licensing), only Dell is affected — VAST’s software is its own.
Moderate but architecturally different from Dell’s. VAST borrows hardware judgment from OEM partners (Cisco/Supermicro for servers) and silicon judgment from NVIDIA (GPUs, NICs, DPUs, switches). But VAST retains software architecture judgment (DASE, containerized CNodes, NVMe fabric design) entirely. Dell borrows software judgment from NVIDIA (Run:ai, NemoClaw, OpenShell, AI Enterprise) while retaining hardware judgment (PowerEdge design, thermal engineering, rack integration). The DAPM distinction: Dell’s borrowed judgment at Layer 0 is silicon-level (structural, everyone shares it). VAST’s borrowed judgment at Layer 0 is hardware-manufacturing-level (Cisco/Supermicro build the boxes). Neither vendor is fully independent at Layer 0, but their dependencies are in different dimensions.
Dell is notably absent from VAST’s OEM partner list (Cisco, Supermicro shipping; HPE, Lenovo in progress). This is a competitive signal — Dell positions itself as VAST’s primary competitor in AI data platforms (PowerScale/ObjectScale/MetadataIQ vs. DataStore/DataBase/Catalog). Dell building CNode-X configurations would be akin to VMware selling on Hyper-V. The containerized update model is a Layer 0 operational differentiator: VAST updates CNodes by spinning up a new container version alongside the old one and switching in seconds. Traditional server updates require node reboots and downtime. This reduces the operational overhead of infrastructure management — a function that Dell handles through OpenManage Enterprise and firmware lifecycle processes. The Gemini procurement model (hardware at cost, software as subscription) means VAST’s revenue is software-driven. Dell’s revenue is hardware-driven with NVIDIA software licenses as pass-through. This affects how each vendor invests in software capabilities — VAST’s business model incentivizes software differentiation; Dell’s incentivizes hardware volume.
Durable, governed data foundation — the Governance Catalog that Layer 2C queries
High-performance file, object, and block storage on all-flash NVMe. Universal Storage heritage — no separate engines for file vs. object vs. block. NFS v3/v4.1, SMB 2.1/3.1, S3 REST API. An Element is not an NFS file or an S3 object — it’s a superset of all of them. Write a file as an object, read it as SMB, read it over NFS — same underlying data, no copies, no translation layers. Protocol-independent storage with protocol-dependent access.
Purpose-built database for AI: structured data (EDW tables), contextual metadata, vectors for similarity search, real-time streams (Kafka-compatible), catalogs, and logs. Vectors live alongside structured records in a single query path. Supports open formats like Parquet. Handles tables alongside unstructured data in the same transactional system.
Indexes metadata attributes of all data on cluster — files, objects, directories. Queryable via Web UI, VMS API, CLI, or connected third-party query engines. Automated classification based on multi-protocol access patterns. The discovery surface that downstream engines (InsightEngine, PolicyEngine) consume.
Low-level key-value store on B-tree data structure underlying all services. Organizes physical storage into a global namespace holding Elements (files/objects, tables, block volumes/LUNs). Every Element is automatically enriched with metadata, security data, and data reduction data. Provides Element-level access control, encryption, snapshots, clones, and replication. ACID transactional semantics with decentralized locks at file/object/table level. No eventual-consistency pitfalls — if an update is committed, subsequent queries see it.
Inline encryption (at rest and in transit). Immutable snapshots (critical for ransomware recovery and audit trails). MFA. Granular access control at Element level. U.S. Government STIG-aligned security configuration. HIPAA, SOC 2, GDPR-ready compliance posture. CrowdStrike integration monitors data access, admin activity, and workload behavior continuously — security embedded at the data layer, not overlaid. Security governance follows data end-to-end: access controls on source files propagate automatically through embeddings to inference outputs.
GPU-accelerated vector indexing and search. Integrated directly into VAST DataBase on CNode-X rather than as an external accelerator. Enhances performance but is not required for core storage or database operations — VAST DataStore/DataBase run without GPUs on standard CNodes/EBoxes.
This is VAST’s strongest layer and its primary 4+1 differentiator. Where Dell requires PowerScale (file) + ObjectScale (object) + Exascale (combined) + MetadataIQ (metadata) + Lightning FS (parallel) + Trust3 AI (governance partner) as separate components with integration seams and multiple authority boundaries, VAST provides a single platform where all data types, metadata, vectors, and security controls share the same Element Store with ACID guarantees. The multiprotocol Element Store is the architectural fact that changes the 4+1 mapping. In Dell’s architecture, data stored as files (PowerScale/NFS) must be accessed differently than data stored as objects (ObjectScale/S3). MetadataIQ indexes across both but the storage engines are separate systems with separate governance surfaces. In VAST, any Element can be accessed as a file, an object, or a table row — same data, same permissions, same metadata — because the Element Store is protocol-independent. For AI pipelines where data flows between ingestion (S3), preprocessing (NFS), training, and inference, this removes an entire class of integration complexity. The governance catalog question from the 4+1 model — ‘is the metadata rich enough to drive Layer 2C placement decisions?’ — has a clearer answer with VAST than with any other vendor in this assessment series. Because the Catalog, DataBase, PolicyEngine, and security controls are all part of the same platform operating on the same Element Store, the metadata that PolicyEngine queries for governance decisions is the same metadata that DataStore manages. No API boundary, no schema translation, no integration seam between ‘where the data lives’ and ‘where governance decisions are made.’ The security-follows-data model is significant: access controls on source files propagate automatically through embeddings to inference outputs. Dell’s Trust3 AI provides similar governance intent but as a partner overlay on separate storage engines — the propagation must cross system boundaries. VAST’s propagation is structural because storage, metadata, and security share the same data structures. The trade-off remains stark: if you choose VAST for Layer 1A, you’ve also chosen VAST for Layer 1B (InsightEngine) and Layer 1C (DataEngine). The layers are not independently substitutable. Dell’s modular approach lets you swap Elastic for Weaviate at Layer 1B without touching Layer 1A. VAST does not offer that optionality. This is the fundamental DAPM trade-off: architectural coherence vs. component substitutability.
Low — the lowest in either vendor assessment. VAST owns the storage engine, the database engine, the metadata catalog, the Element Store, and the security/compliance stack. NVIDIA dependency is limited to GPU acceleration (cuVS on CNode-X) which enhances but isn’t required for core storage operations. VAST’s storage platform runs without GPUs on standard CNodes/EBoxes; CNode-X adds GPU acceleration on top. Compare to Dell’s Layer 1A: Dell owns PowerScale, ObjectScale, Exascale, Lightning FS, and MetadataIQ (Retained) but depends on NVIDIA for acceleration (cuVS, SuperNICs, NeMo Retriever connector) and Trust3 AI for governance (Delegated). Dell’s authority at Layer 1A is Retained with two Delegated dependencies. VAST’s authority at Layer 1A is entirely self-contained — but Ceded to VAST as a vendor dependency. The DAPM distinction: Dell’s enterprise Retains Layer 1A authority. VAST’s enterprise Cedes Layer 1A authority to VAST. Both are ‘low borrowed judgment’ in different ways — Dell borrows less from partners because it built the storage; VAST borrows less from NVIDIA because its storage is GPU-independent. But the enterprise’s relationship to the vendor is different: Dell = you own it; VAST = VAST owns it, you subscribe.
The Element Store enrichment model is the architectural reason VAST’s governance catalog is inherently richer than Dell’s MetadataIQ: every Element is automatically enriched with metadata, security data, and data reduction data at write time — not indexed after the fact. This is structural metadata richness vs. bolt-on tagging. The practical consequence: VAST’s metadata is always current (enriched inline with writes). Dell’s MetadataIQ indexes asynchronously, which means metadata currency depends on indexing lag. The compliance story is maturing: U.S. Government STIG-aligned security configuration guide (v1.5), HIPAA compliance documentation, and the Kiteworks/Cybersecurity Insiders 2026 forecast showing 63% of organizations cannot enforce purpose limitations on AI agents. VAST’s PolicyEngine (Layer 2C) is designed to address this gap — but it depends on Layer 1A’s Element-level security model as the enforcement surface. CrowdStrike integration at the data layer (vs. Dell’s perimeter-level integration) means threat detection and automated response happen where the data is, not at the network edge. For AI workloads where data is continuously accessed by agents, data-layer monitoring is architecturally more appropriate than perimeter monitoring.
Low-latency retrieval for RAG — vector/hybrid search, context windows
Framework for building, managing, and automating real-time AI pipelines. Built on DataEngine using event-driven triggers and serverless functions. Processes data the moment it lands: automated chunking, embedding (via NVIDIA NIM), and storage in DataBase’s native vector store. Eliminates traditional batch processing delays — near-instant availability for AI retrieval and inference. Described as the first solution to securely ingest, process, and retrieve all enterprise data (files, objects, tables, streams) in real time. Model agnostic — compatible with any model using the OpenAI API spec.
Built directly into VAST DataBase on DASE architecture. No sharding, no memory-bound indexes. Scales linearly by adding stateless compute nodes — throughput grows without data reorganization. Vectors, metadata, and raw content live side-by-side in the Element Store. Single query path for vector search + SQL filters + metadata predicates + joins. A video RAG workflow can retrieve semantically relevant clips while filtering by time range, camera ID, location, or policy — in a single execution path. Scales from millions to trillions of vectors with consistent performance.
InsightEngine ties the permissions of vector database rows to the permissions of source data. RAG requests only return embeddings and chunks for data the requesting user is authorized to access. This is not a bolt-on ACL check — it’s structural because vectors inherit the security model of their source Elements. Access controls propagate from source files through embeddings to inference outputs.
Ingests data from enterprise systems (Google Drive, Jira, Confluence, S3 buckets, file systems) while preserving identity and access semantics. The answer to ‘what about my non-VAST data?’ — brings external enterprise data into the VAST namespace with governance intact. Maintains durable searchable index and triggers enrichment pipelines automatically on ingestion.
Metadata indexed across all data types. Queryable via Web UI, VMS API, CLI, or third-party engines. Provides the discovery and filtering surface that InsightEngine and retrieval pipelines consume.
InsightEngine triggers NVIDIA NIM embedding agents as data is written. Embeddings stored in DataBase within milliseconds. NIM provides the embedding intelligence; VAST provides the pipeline automation and storage. Model agnostic — NIM is the default but any OpenAI-compatible model works.
GPU-accelerated vector indexing and search integrated into DataBase via CNode-X. Enhances search speed but the retrieval logic, permission model, and pipeline orchestration are all VAST’s.
Layer 1B is where the architectural difference between VAST and Dell is sharpest — and where the 4+1 model’s layer boundaries are most challenged. Dell’s Layer 1B is a three-party dependency: Dell (PowerScale/ObjectScale storage + MetadataIQ metadata), Elastic (Elasticsearch 9.4 search intelligence), and NVIDIA (cuVS acceleration). Three authority boundaries, three integration seams, three vendors to coordinate for a single retrieval pipeline. VAST’s Layer 1B is a single-authority system: InsightEngine (pipeline), Vector Search (retrieval), DataBase (vector + structured storage), and Catalog (discovery) — all VAST IP running on the same Element Store. NVIDIA provides embedding models (NIM) and search acceleration (cuVS) but the retrieval logic, permission propagation, and pipeline orchestration are entirely VAST’s. The ‘data decay’ concept from VAST’s engineering is relevant to the 4+1 model: the gap between what the data IS and what the system BELIEVES the data to be widens over time in batch-indexed systems. InsightEngine addresses this by triggering embedding generation the moment new data is written — embeddings are always current with source data. Dell’s incremental indexing (ingesting only updated files) addresses the same problem but across system boundaries — MetadataIQ indexes PowerScale/ObjectScale, then the Data Search Engine re-indexes based on metadata changes. VAST’s approach is structurally tighter because the trigger, the embedding, and the vector storage share the same platform. The permission-aware retrieval is the most significant security finding at Layer 1B. Vector database rows inherit permissions from source data Elements. RAG queries only return authorized content. This is structural security (same Element Store, same permission model) rather than an overlay check. Dell’s retrieval through Elastic does not natively propagate PowerScale/ObjectScale permissions into search results — that’s a separate integration concern. SyncEngine’s enterprise data ingestion (Google Drive, Jira, Confluence) with preserved identity and access semantics is VAST’s answer to the heterogeneous enterprise. But it’s also an honest constraint: enterprise data that doesn’t enter the VAST namespace isn’t retrievable through InsightEngine. Dell’s Elastic-based search can potentially index data from more sources without requiring ingestion into Dell storage. The 4+1 Layer 1B question: does VAST expose retrieval quality observability (recall@k, latency percentiles, cache hit rates) that a Layer 2C could use for placement decisions? VAST’s integrated architecture makes this more feasible than Dell’s (InsightEngine and PolicyEngine share the same platform), but published materials don’t detail retrieval quality metrics as a first-class observable. The pipeline automation and real-time embedding are well documented; the retrieval quality feedback loop is not.
Low. VAST owns the retrieval logic (InsightEngine + Vector Search), the storage substrate (DataStore + Element Store), the metadata catalog (Catalog + DataBase), and the permission model (Element-level security propagated to vector rows). NVIDIA provides embedding models (NIM) and search acceleration (cuVS) but neither is required for the core retrieval function to work — InsightEngine is model agnostic and Vector Search runs on standard CNodes without GPU acceleration. Compare to Dell’s Layer 1B: Dell’s retrieval quality depends on Elastic (search intelligence), NVIDIA (acceleration), and Dell (storage + metadata). If Elastic changes Elasticsearch licensing or features, Dell’s retrieval story changes. VAST has no equivalent third-party dependency at Layer 1B. The DAPM classification is Ceded to VAST — the enterprise doesn’t own the retrieval engine. But the authority is unified in one vendor rather than split across three. For the enterprise architect, this means one vendor relationship to manage for retrieval instead of three — but total dependency on that one vendor.
The single-query-path architecture (vector search + SQL + metadata predicates + joins in one execution path) remains the most significant Layer 1B capability in this assessment series. No other vendor provides this without stitching together separate systems. The model-agnostic design is worth emphasizing: InsightEngine works with NVIDIA NIM by default but supports any model compatible with the OpenAI API spec. This means VAST’s Layer 1B retrieval pipeline is not locked to NVIDIA’s embedding models — unlike the Layer 2B runtime where NemoClaw/OpenShell creates a stronger NVIDIA dependency in Dell’s stack. The real-time embedding trigger (process data the moment it lands) vs. Dell’s incremental indexing (index only updated files) represents two approaches to the data currency problem. VAST’s is architecturally tighter but also more compute-intensive — every write triggers an embedding pipeline. Dell’s is more conservative on compute but introduces metadata lag. For agentic AI workloads where agents make decisions based on current data, VAST’s approach is architecturally more appropriate. For cost-constrained environments where batch indexing is acceptable, Dell’s approach is more efficient.
Move/transform data — serverless execution, event-driven pipelines, in-situ compute
Serverless compute layer executing containerized functions, triggers, and analytical engines directly on CNodes. Three core execution modes: (1) Event Triggers via Kafka-compatible Event Broker, (2) Serverless Functions as lightweight Python in stateless containers, (3) Containerized Engines for native VAST and partner workloads. Functions, events, and pipelines defined as Kubernetes custom resources. Completely event-driven — unlike centralized orchestrators (Airflow, Slurm) that poll resources, DataEngine reacts to events at any scale without bottlenecks. Co-located with data: reduces latency, simplifies management, improves security.
Scalable data discovery and migration service within DataEngine. Indexes and synchronizes data from external sources (S3 buckets, file systems, SaaS platforms like Google Drive, Jira, Confluence) into the DataSpace. Maintains durable searchable index. Triggers enrichment pipelines automatically as new data is onboarded. Preserves identity and access semantics from source systems.
Native Kafka-compatible streaming ingestion built into the platform (not an external dependency). Stores message topics as VAST Tables for global ordering and real-time SQL querying of live streams. Events are immediately accessible as tables in the DataBase. Detects S3 object creation, tagging, and deletion events and triggers downstream workflows. Decoupled design: functions are never hardwired to data sources — the broker ensures events flow to the right consumer.
Command-line interface (vastde) for managing functions, pipelines, triggers, compute clusters, container registries. Python SDK with DataEngine context object for function development. Multiple output formats (human-readable, JSON, YAML), dry-run mode, integrated monitoring with built-in access to logs and traces. Low-code interface also available for non-developers.
Manages and automates AI model tuning. Works with PolicyEngine to power automatic learning loops that remain aligned with organizational expectations. Creates closed operational computing loop: observe, reason, act, evaluate, improve. Future interactions improve newly deployed models. Slated for release by end of 2026.
The layers compose into end-to-end workflows: SyncEngine discovers and onboards data → DataEngine processes via event-driven functions and Event Broker → InsightEngine contextualizes with chunking and embedding models → DataBase stores vector embeddings for querying → AgentEngine executes multi-step tasks leveraging tools and data across the ecosystem. Each stage is a DataEngine pipeline stage, not a separate system.
GPU-accelerated data manipulation for pipeline processing. Integrated into DataEngine on CNode-X configurations. Accelerates the transformation and enrichment stages of data pipelines.
CNode-X integrates NVIDIA libraries directly into DataEngine services. 44% faster queries, 80% lower costs per VAST claims. GPU acceleration is additive — DataEngine runs on standard CNodes without GPUs; CNode-X adds performance.
Embedding model execution triggered by DataEngine events. NIM provides the embedding intelligence for the InsightEngine pipeline stage. Model agnostic — any OpenAI API-compatible model works.
VAST’s DataEngine is the most architecturally integrated Layer 1C in this assessment series. The gap analysis requires comparing three dimensions: orchestration model, data movement, and lifecycle completeness. Orchestration model: DataEngine is completely event-driven using Kubernetes custom resources. Dell’s Dataloop is a no-code/low-code engine acquired from a startup. Apache Airflow and Slurm (common alternatives) use centralized orchestrators that poll resources. DataEngine’s event-driven model avoids the scaling bottlenecks of centralized orchestration — it reacts to events rather than scheduling them. This is a meaningful architectural advantage for continuous AI pipelines where data flows never stop. Data movement: DataEngine executes co-located with data on CNodes. Dell’s Dataloop orchestrates across API boundaries between separate storage (PowerScale), search (Elastic), and compute (NVIDIA) systems. The practical difference: VAST’s pipelines don’t move data between systems because storage and compute share the same platform. Dell’s pipelines necessarily move data between PowerScale/ObjectScale and the GPU cluster. Dell’s KV Cache offload (NVIDIA CMX, 19x TTFT improvement) is a sophisticated answer to this data movement problem — but it’s solving a problem that VAST’s architecture doesn’t have. Lifecycle completeness: DataEngine + SyncEngine + Event Broker + InsightEngine + AgentEngine + TuningEngine spans from data ingestion through embedding through agent execution through model improvement. Dell spans from data orchestration (Dataloop) through search (Elastic) through analytics (Starburst) — but the agent runtime (NemoClaw) and model lifecycle are separate NVIDIA-owned layers. VAST’s lifecycle is more complete but less proven. Dell’s lifecycle has more mature individual components but more seams. The composability architecture is worth noting for the 4+1 model: VAST’s layers (SyncEngine → DataEngine → InsightEngine → DataBase → AgentEngine) compose as pipeline stages within a single platform. The 4+1 model defines these as separate layers (1A, 1B, 1C, 2B). VAST’s architecture challenges the layer separation by making the boundaries internal to one platform rather than external between systems. The layers still exist functionally, but the authority boundaries don’t — VAST owns all of them.
Low. DataEngine, SyncEngine, Event Broker, composability architecture, and the DataEngine CLI/SDK are all VAST IP. TuningEngine (end of 2026) will be VAST IP. NVIDIA provides GPU acceleration (cuDF, CUDA, NIM) but the orchestration logic, event processing, pipeline management, and lifecycle coordination are entirely VAST’s. Compare to Dell’s Layer 1C: Dell owns the Dataloop orchestration engine (Retained — its strongest software move) but depends on NVIDIA for acceleration (cuDF, CMX for KV cache), Starburst for analytics, and NVIDIA Blueprints/NIMs for pipeline templates. Dell’s Layer 1C has four authority boundaries: Dell (Dataloop), NVIDIA (acceleration + templates), Starburst (analytics), and the customer (pipeline configuration). VAST’s Layer 1C has one: VAST. The Kubernetes foundation is a shared dependency: both Dell and VAST depend on K8s. But VAST embeds K8s custom resources into its platform (functions, events, pipelines as CRDs), while Dell depends on external K8s distributions (Red Hat OpenShift AI, Canonical Ubuntu). VAST’s K8s dependency is internal; Dell’s is external.
The DataEngine CLI (vastde) and Python SDK represent a developer experience that Dell’s Dataloop doesn’t yet match in published documentation. The CLI manages functions, pipelines, triggers, compute clusters, and container registries with dry-run mode and integrated observability. Dell’s Dataloop is positioned as no-code/low-code — targeting data engineers. VAST’s DataEngine targets both low-code users and developers/MLOps engineers with full Python SDK access. Different audience emphasis. The built-in observability (logs, traces within the same UI, without external Grafana or tracing infrastructure) is an operational differentiator. Dell’s observability for data pipelines depends on partner tools and external monitoring stacks. The TuningEngine + PolicyEngine combination represents VAST’s ‘thinking machine’ vision: systems that observe, reason, act, evaluate, and improve automatically. This is the most ambitious lifecycle claim from any vendor in this assessment series. Dell’s equivalent would require assembling Dataloop (orchestration) + NVIDIA NeMo (model training) + NemoClaw (agent execution) + manual feedback loops — four systems from three vendors with no automated improvement loop.
Provision, schedule, and govern compute environments
Global control plane purpose-built for AI data infrastructure spanning public cloud, neocloud, and on-prem. Kubernetes-based architecture with lightweight agent on every VAST node. Intent-driven: administrators define desired state, Polaris coordinates cloud-native services to achieve and maintain it. Automates provisioning, cloud marketplace integration (subscription/entitlement), centralized upgrade orchestration, expansion, and node replacement. Multi-cluster: converts distributed infrastructure into a single operational platform. Available as VAST-managed, partner-managed, or customer-managed.
Enterprise identity integration, role-based access control, and audit logging. Cloud-style operational consistency across hybrid and multicloud environments. Supports sovereign deployments. Multi-tenant by design.
Built-in scheduler and cost-optimizer within DataEngine. Deploys serverless functions on CPU, GPU, and DPU architectures. Manages function lifecycle, container orchestration, and resource allocation. Event-driven scheduling rather than centralized job queuing.
Polaris abstracts INFRASTRUCTURE location (where clusters are deployed and maintained). DataSpace abstracts DATA location (how data is presented across locations via global namespace). Together they provide the ‘where should this run relative to this data’ coordination that is a prerequisite for Layer 2C.
GPU lifecycle management for containerized VAST services running on CNode-X. Manages driver installation, device plugins, monitoring for the GPUs embedded in the data platform.
CNode-X GPUs accelerate DATA PLATFORM services (vectorization, SQL via Sirius/cuDF, vector search via cuVS, inference within InsightEngine). They are NOT general-purpose GPU compute for external training/inference workloads. VAST does not provide Run:ai-equivalent fair-share GPU scheduling because the use case is different — GPU resources serve the platform’s own services, not multi-tenant external workloads competing for GPU time.
Layer 2A is where the architectural models diverge most sharply between Dell and VAST, and where the 4+1 model’s layer definitions need careful application. Dell’s Layer 2A problem: GPU-aware workload scheduling for multi-tenant inference and training. Multiple teams compete for scarce GPU resources. Run:ai provides fair-share scheduling, quotas, and RBAC. Dell has no proprietary capability here. VAST’s Layer 2A reality: GPU resources in CNode-X serve the data platform’s own services (vector search, SQL acceleration, embedding generation, data pipeline processing). These are not multi-tenant external workloads competing for GPU time — they are platform services running on platform-embedded GPUs. The scheduling question is different: VAST’s DataEngine scheduler allocates serverless function execution across CNodes, not GPU time-slices across competing users. Polaris provides genuine Layer 2A capability that Dell lacks entirely: intent-driven, multi-cluster, multi-cloud infrastructure provisioning and lifecycle management. Dell’s OpenManage manages a single rack. Polaris manages a fleet of VAST deployments across geographies, clouds, and on-prem sites as one system. The three management modes (VAST-managed, partner-managed, customer-managed) provide operational flexibility that has no Dell equivalent. However, if the enterprise deploys separate GPU clusters for training/inference (not embedded in VAST), those clusters still need GPU-aware scheduling. VAST doesn’t provide this — the customer would need NVIDIA Run:ai or equivalent for the GPU compute layer that sits alongside (not within) the VAST data platform. In a typical deployment, VAST handles the data plane (storage, retrieval, orchestration), and a separate GPU cluster (Dell PowerEdge, HPE ProLiant, etc. with Run:ai) handles training/inference. Polaris manages the VAST fleet; something else manages the GPU cluster. The Polaris + DataSpace coordination is the most interesting Layer 2A finding: Polaris abstracts infrastructure location while DataSpace abstracts data location. This separation of concerns — managing where infrastructure runs vs. managing where data lives — is exactly the architectural prerequisite for Layer 2C placement reasoning. No other vendor in this assessment separates these abstractions as cleanly.
Low for infrastructure orchestration (Polaris is VAST IP). Moderate for GPU-specific scheduling (depends on NVIDIA GPU Operator for CNode-X, and the customer still needs Run:ai or equivalent for separate GPU clusters). Compare to Dell: Dell’s Layer 2A has HIGH borrowed judgment because all GPU-aware orchestration is NVIDIA-controlled (GPU Operator, Run:ai, AI Enterprise, MIG/MPS). VAST’s Layer 2A has MODERATE borrowed judgment because Polaris handles infrastructure orchestration (VAST IP) while GPU scheduling is a narrower dependency limited to CNode-X management. The key distinction: Dell NEEDS Run:ai because GPU scheduling is the core Layer 2A function in Dell’s architecture. VAST’s Polaris handles the broader infrastructure orchestration function, and GPU scheduling is a specific sub-function for CNode-X hardware management, not the defining Layer 2A capability. Polaris is included in VAST AI OS at no additional charge. Dell’s customers pay separately for NVIDIA Run:ai and AI Enterprise licenses. This pricing distinction reflects the authority distinction: VAST bundles infrastructure orchestration because it owns it; Dell passes through NVIDIA licensing because it doesn’t.
The three management modes (VAST-managed, partner-managed, customer-managed) have DAPM implications: • VAST-managed: fully Ceded — VAST operates the infrastructure • Partner-managed: Delegated to the partner (CSP, MSP) • Customer-managed: the enterprise operates Polaris but the software is still VAST’s Even in customer-managed mode, the control plane software is VAST IP. The enterprise operates it but doesn’t own it. This is analogous to running VMware vCenter on your own hardware — you operate it, but the software authority belongs to the vendor. Polaris is available now as part of VAST cloud deployments, with expanded multi-cluster orchestration planned in future releases. The ‘expanded multi-cluster orchestration’ roadmap item is worth tracking — this is where Polaris evolves from infrastructure management (Layer 2A) into placement reasoning (Layer 2C). 89% of APAC enterprises deploy workloads across multiple public clouds; 72% operate hybrid cloud models (cited by VAST). This validates Polaris’s multi-cloud orchestration thesis.
Agent execution, model serving, workflow orchestration
AI agent deployment and orchestration system running natively within the DataEngine. Described as ‘the application management layer of the VAST AI OS, designed specifically for the Agentic AI Era’ and ‘the final piece of the puzzle, rounding out the core services needed to run agentic applications on AI hardware.’ Low-code runtime that simplifies programming and coordinates multi-agent workflows, model invocation, and tool usage. Brings agents to life directly within DataEngine — reasoning occurs where the data lives.
Robust runtime for long-running containerized services. Lifecycle management for agent deployment, scaling, and versioning. Persistent state via execution-scoped or persistent scratch space spanning files, objects, or tables. Secure service discovery for agents to find and communicate with other agents and tools. Support for agents with multiple personas and security credentials. Fault-tolerant backbone with Kafka-backed queuing for durability and ordering.
Model Context Protocol toolbox enabling agents to orchestrate multiple tools and services together for higher-order workflows. Composability lets teams build complex agentic applications without stitching fragile systems. Aligns with the open MCP standard (donated to Linux Foundation Dec 2025).
Each agent call is defined with the user’s identities and permissions. Tools and data are accessed responsibly under the same permission model that governs the underlying Element Store. Multi-tenant operation with strong governance controls. This is structural — agent permissions inherit from the data platform’s security model, not from a bolt-on ACL layer.
Logs and traces every agent action, tool call, and data access. End-to-end observability creates transparency for compliance, stakeholder trust, and performance refinement. Built into the same platform — no external Grafana, tracing systems, or observability infrastructure required.
Every add, move, change, or delete in storage emits an event that feeds into agent workflows via DataEngine. Ties data operations directly to agentic AI actions in real time. Agents can react to data changes as they happen — no polling, no batch triggers.
VAST can serve NVIDIA NIM inference containers on CNode-X infrastructure, providing access to NVIDIA’s model ecosystem. NIM and AgentEngine are not mutually exclusive — NIM provides optimized model serving; AgentEngine provides the orchestration and lifecycle management around it.
Model inference on CNode-X is GPU-accelerated via CUDA. VAST provides the orchestration and governance; NVIDIA provides the compute acceleration. This separation is cleaner than Dell’s stack where NVIDIA owns both orchestration (NemoClaw) and acceleration.
VAST AgentEngine is the most significant Layer 2B finding in the comparative analysis and the starkest architectural contrast with Dell’s approach. Dell’s Layer 2B: Dell does not appear to own the core agent runtime. NemoClaw provides the agent execution stack (NVIDIA). OpenShell provides the sandboxed runtime (NVIDIA). NeMo Guardrails provide safety constraints (NVIDIA). Cohere North provides agent workflow orchestration (ISV partner). DataRobot provides agent lifecycle management (ISV partner). Dell provides hardware, packaging, and professional services. Five authorities for one layer. VAST’s Layer 2B: AgentEngine provides agent deployment, orchestration, runtime, lifecycle management, persistent state, MCP toolbox, permission-aware execution, observability, and data event integration — all within a single platform. One authority for the entire layer. The architectural differentiators: 1. Agents execute where the data lives. In VAST, there is no data movement between storage and inference runtime because they are the same platform. In Dell’s architecture, data flows from PowerScale/ObjectScale through NVIDIA’s inference runtime, crossing authority and system boundaries. 2. Permission-aware by structure. Agent permissions inherit from the Element Store’s security model. Dell’s agent permissions depend on NeMo Guardrails (runtime constraint) and the ISV partner’s governance logic (Cohere North, DataRobot). 3. Real-time data event triggers. Every storage operation emits events that feed into agent workflows. Dell’s agents consume data through retrieval (Elastic search) and pipeline (Dataloop) stages, not through direct data event feeds. 4. Built-in observability. Logs and traces every agent action without external monitoring infrastructure. Dell’s observability depends on partner tools. 5. MCP Toolbox. Native MCP support for agent-to-tool orchestration. Aligns with open standards. Dell’s agentic platform uses ISV-specific tool orchestration (Cohere North, DataRobot SDKs). The maturity question is real. AgentEngine is newer and less proven than NVIDIA’s NemoClaw/OpenShell stack. NVIDIA’s open-source foundation (OpenClaw), broad model support (Nemotron, NIM), and ecosystem validation (Dell, HPE, Lenovo, CSPs) represent a larger installed base. Jensen’s ‘operating system for personal AI’ framing signals NVIDIA’s long-term commitment to the runtime layer. VAST’s AgentEngine must prove equivalent reliability, security, and model compatibility at enterprise scale. The commoditization signal from Augment Code’s 2026 multi-agent orchestration analysis: ‘The runtime layer (tool registries, state management, retry logic) is being commoditized by open standards and hyperscaler investment. Teams building custom implementations will find platform solutions commoditizing that work within 12–18 months.’ This applies to both VAST AgentEngine and NVIDIA NemoClaw — the question is whether the runtime will differentiate or whether the governance layer above it (Layer 2C) becomes the battleground.
Low for agent orchestration, lifecycle, and governance (AgentEngine, MCP Toolbox, permission model, observability are all VAST IP). Moderate for model inference (depends on NVIDIA CUDA acceleration on CNode-X). NIM containers can run on the platform but are not required — AgentEngine is model-agnostic. Compare to Dell: Dell’s Layer 2B borrowed judgment is TOTAL for the runtime (NemoClaw/OpenShell/NIM/Dynamo/AI Enterprise are all NVIDIA) and DELEGATED for orchestration (Cohere North/DataRobot/ClearML). Dell’s one Retained asset is professional services. VAST’s Layer 2B authority structure: VAST owns the runtime, the orchestration, the lifecycle management, the permission model, and the observability. NVIDIA provides inference acceleration. The enterprise Cedes to one vendor (VAST) rather than to three+ vendors (NVIDIA + Cohere + DataRobot + ClearML in Dell’s case). The DAPM summary: both Dell and VAST require the enterprise to Cede Layer 2B authority. The difference is whether you Cede to a fragmented set of authorities (Dell’s model) or to a unified authority (VAST’s model). The 4+1 model doesn’t prescribe which is better — it requires the enterprise architect to make the choice explicitly.
The positioning contrast is telling: NVIDIA says NemoClaw is ‘the operating system for personal AI.’ VAST says AgentEngine is ‘the application management layer of the AI Operating System.’ NVIDIA positions the agent runtime as an OS — the platform everything else runs on. VAST positions it as a layer within a larger OS that includes storage, retrieval, governance, and infrastructure orchestration. The difference: NVIDIA’s vision is runtime-centric (the agent runtime IS the platform). VAST’s vision is data-centric (the data platform includes the agent runtime as one of its services). For the Enterprise AI Control Plane working document: AgentEngine + PolicyEngine (Layer 2C) + the Element Store permission model (Layer 1A) form a coherent governance chain within VAST’s stack. In Dell’s stack, the equivalent governance chain would be: NeMo Guardrails (NVIDIA) + ???(no Layer 2C) + Trust3 AI (partner) + MetadataIQ (Dell) — four authorities, one missing layer.
Policy-driven placement and resource coordination — the Autonomy Layer
Inline policy enforcement point across the AI OS. Governs agent access to shared memory, external tools, knowledge bases, external data products, and other agents. Applies BOTH explicit permissions AND AI-derived context BEFORE actions execute. Mediates every type of input and output — enables redaction or transformation of sensitive data before exposure to models or agents. Tamper-proof traces and logs for replay, explainability, and regulatory compliance. Zero-trust operating posture: all AI activity remains observable, explainable, and auditable. CrowdStrike integration for security monitoring of data access, admin activity, and workload behavior.
Manages continuous model optimization. Supports LoRA fine-tuning, supervised fine-tuning, and reinforcement learning. Leverages outcomes from agentic pipelines and curated feedback. Candidate models evaluated, benchmarked, and deployed manually or automatically. Integrates with NVIDIA NeMo Data Designer for training and fine-tuning Nemotron models. Works with PolicyEngine to power automatic learning loops — the closed operational computing loop: observe, reason, act, evaluate, improve.
Abstracts infrastructure location across public cloud, neocloud, and on-prem. Intent-driven: administrators define desired state, Polaris coordinates to achieve and maintain it. Complements DataSpace (which abstracts data location). Together they provide the ‘where should this workload run relative to this data’ coordination. Can align compute placement with GPU availability and compliance requirements without altering application behavior.
Globally distributed data computing layer. Synchronizes metadata, presents data through remote caches, provides file/object/table-level consistency management across sites. Decentralized consistency: each site can assume temporary responsibility at granular namespace levels. The data-location abstraction that Polaris’s infrastructure-location abstraction complements.
Together these create what VAST calls a ‘thinking machine’: a consolidated stack that merges data, compute, policy enforcement, and model training into one infrastructure fabric. PolicyEngine governs every interaction. TuningEngine learns from every outcome. The loop: observe (data events) → reason (agent processing) → act (tool execution) → evaluate (outcome assessment) → improve (model tuning) → govern (policy enforcement on the improved model). No other vendor in this assessment has a closed governance+learning loop.
TuningEngine integrates with NeMo Data Designer for training and fine-tuning Nemotron models. This is NVIDIA’s model training framework accessed through VAST’s tuning pipeline — NVIDIA provides the training technology, VAST provides the orchestration and governance around it.
PolicyEngine, Polaris, and DataSpace are VAST IP. NVIDIA does not provide or control the governance, placement, or policy reasoning layer. The NeMo Data Designer integration is a training tool dependency, not a governance dependency. This is structurally different from Dell, where the closest Layer 2C functions (Dynamo routing, NeMo Guardrails) are NVIDIA-owned.
This is the most significant finding in the comparative assessment. Layer 2C is where the 4+1 model’s thesis is tested most directly: does any vendor provide policy-driven placement decisions across models, data, agents, and infrastructure? Applying the ‘Routing Is Not Reasoning’ test to VAST’s stack: PolicyEngine goes BEYOND constraint enforcement (what NeMo Guardrails does at Layer 2B). Guardrails say ‘the agent cannot do X.’ PolicyEngine says ‘the agent can do X only if conditions Y and Z are met, as determined by AI-derived context, and the action will be logged with tamper-proof traceability.’ This is active policy reasoning, not static constraint enforcement. The pre-execution enforcement model means governance decisions happen BEFORE actions execute, not after — a fundamentally different posture than post-hoc audit. Polaris goes BEYOND infrastructure provisioning (what Kubernetes does at Layer 2A). Polaris doesn’t just deploy clusters — it abstracts infrastructure location so that workloads can be placed based on GPU availability and compliance requirements without changing application behavior. Combined with DataSpace abstracting data location, Polaris + DataSpace provide the multi-variable placement reasoning that the 4+1 model defines as Layer 2C. TuningEngine goes BEYOND model serving (what NemoClaw does at Layer 2B). It manages the continuous improvement of models based on production outcomes, governed by PolicyEngine. This closes the loop from execution through evaluation through improvement through re-governance — no other vendor has this cycle in a single platform. The multi-variable test from the 4+1 model: can the system make placement decisions based on cost + compliance + latency + data residency + model capability simultaneously? • Cost: DataEngine’s built-in cost-optimizer can deploy on CPU/GPU/DPU based on cost • Compliance: PolicyEngine enforces permissions and audit requirements before execution • Latency: DataSpace provides remote data caches for geo-distributed access • Data residency: DataSpace’s per-site consistency management respects data locality • Model capability: TuningEngine manages model versions and fitness for purpose VAST is the only vendor in this series that addresses all five variables, even if the integration between them is not yet fully productized (PolicyEngine and TuningEngine ship end of 2026). Caveats remain critical: • PolicyEngine and TuningEngine are announced, not shipped. GA end of 2026. • Polaris is available but multi-cluster placement orchestration is in ‘expanded capabilities planned in future releases.’ • The ‘AI-derived context’ in PolicyEngine is described but the AI decision-making model is not detailed — how the AI determines permissions from context is a black box. • The closed loop (observe-reason-act-evaluate-improve) is architecturally described but not production-validated at enterprise scale. Compare to Google Cloud: Inference Gateway + DWS + Knowledge Catalog is productized and shipping. Google’s Layer 2C is narrower (inference placement and scheduling) but real. VAST’s is broader (governance + placement + learning) but pre-GA. Compare to Dell: No productized Dell-owned Layer 2C is evident. Dell has the Dell + Intel ‘control plane’ signal but no product. VAST is building what Dell hasn’t started. Compare to Kamiwaza: Policy-driven Inference Mesh + Distributed Data Engine + ReBAC is the most comparable Layer 2C approach — explicit multi-variable policy optimization for inference placement. Kamiwaza and VAST are approaching from different directions (Kamiwaza from inference, VAST from data) toward the same Layer 2C function.
Low — the lowest Layer 2C borrowed judgment score in the assessment series because VAST is the only vendor building a proprietary Layer 2C. PolicyEngine, Polaris, DataSpace, and TuningEngine are all VAST IP. The NVIDIA dependency is limited to NeMo Data Designer for model training within TuningEngine — a training tool, not a governance dependency. The DAPM classification is Ceded to VAST. The enterprise doesn’t own the control plane — VAST does. But the 4+1 model’s DAPM framework reveals an important distinction: • Dell at Layer 2C: ABSENT — no authority exists to Cede or Retain. The enterprise operates without governance. • VAST at Layer 2C: CEDED — authority exists and is Ceded to VAST. The enterprise has governance but doesn’t own it. • Google at Layer 2C: CEDED — authority exists and is Ceded to Google. Productized and shipping. Absent is worse than Ceded. Having governance you don’t own is better than having no governance at all. The enterprise architect’s decision is not ‘should we have Layer 2C?’ (the 4+1 model says yes). It’s ‘who should hold the Layer 2C authority?’ VAST’s answer: VAST holds it, as part of a vertically integrated platform where governance, execution, data, and infrastructure are one system. Dell’s non-answer: nobody holds it. Build it yourself or operate without it. Google’s answer: Google holds it, as part of a cloud platform where the enterprise Cedes everything.
Analyst and media framing validates the Layer 2C classification: • Blocks and Files: ‘VAST broadens AI platform push with control plane’ — explicitly using control plane language • Moor Insights: Polaris positions VAST as ‘the persistent operational layer for AI’ • theCUBE Research (Strechay): ‘VAST looks at it as going up the stack’ • TipRanks: PolicyEngine + TuningEngine transform the AI OS into a ‘consolidated stack merging data, compute, policy enforcement, and model training into one infrastructure fabric’ • SiliconANGLE: Polaris is ‘complementary to DataSpace — DataSpace focuses on how data is presented across locations; Polaris focuses on how clusters are deployed and maintained’ This validates the Enterprise AI Control Plane working document’s Pattern 4: Storage Vendors Reaching Up. VAST is the most aggressive example. The three-vector convergence: • Dell: bottom-up (infrastructure OEM, hasn’t started Layer 2C, Dell+Intel signal only) • Google: top-down (cloud provider, Inference Gateway + DWS + Knowledge Catalog, productized) • VAST: middle-out (data platform, PolicyEngine + Polaris + DataSpace + TuningEngine, emerging) The Microsoft Agent Governance Toolkit (April 2026) and the AgentGuardian research paper validate that agent governance is becoming a recognized engineering discipline, not just a VAST-specific product category. The 4+1 model’s Layer 2C aligns with this emerging discipline.
AI-powered business capabilities — business logic, workflow automation
Global partner ecosystem formalized at VAST Forward 2026 with distinct partner tracks: Software Partners (ISVs) build integrations and validated solutions on the AI OS. Hardware/Platform Partners (Cisco, Supermicro, HPE, Lenovo) deliver infrastructure foundations. Cloud Partners (CSPs, neoclouds, hyperscalers). Channel Partners (resellers, SIs, advisory). Developer Community with technical resources, learning pathways, hands-on labs, and contribution opportunities for integrations and blueprints.
First customer-managed deployment path for TwelveLabs’ video foundation models (Marengo for embeddings/search, Pegasus for deep video understanding). Extends video intelligence beyond public cloud into on-prem and sovereign environments. Target: media companies, financial services (surveillance-based fraud detection), government agencies (data sovereignty). TwelveLabs gains on-prem deployment; VAST gains a compelling vertical anchor use case.
Strategic partnership connecting VAST AI OS telemetry to CrowdStrike Falcon platform. Coordinated detection across data ingestion, model training, and runtime inference environments. Deeper than perimeter security — integrated into PolicyEngine with event-driven automation for threat detection and response. Unified policy management, agent governance, encryption, and regulatory reporting.
$1.17B commercial agreement. CoreWeave’s EVP of Product and Engineering presented at VAST Forward 2026 on operating at thousands-of-GPU scale. CoreWeave validates that the VAST platform handles the data coordination requirements of hyperscale AI: predictable data movement, reuse/staging without latency spikes, and consistent flow that enables schedulers to make reliable decisions. The constraint at CoreWeave scale: ‘adding more GPUs doesn’t recover performance if data flow breaks — it amplifies the inefficiency.’
VAST can serve NVIDIA NIM containers and open models on its platform via AgentEngine and CNode-X. Provides access to NVIDIA’s model ecosystem without requiring NemoClaw/OpenShell. AgentEngine is the primary runtime surface; NIM is an optional model delivery mechanism.
CNode-X and AgentEngine provide the substrate for running NVIDIA NIM containers, Nemotron models, and NVIDIA Blueprints. VAST’s model-agnostic architecture means NVIDIA models are one option among many, not the mandatory runtime path.
VAST’s Layer 3 ecosystem is structurally different from Dell’s — not just smaller. Dell’s ecosystem is broad and horizontal: OpenAI (dev productivity), Palantir (operational AI), Google (sovereign compute), ServiceNow (workflow automation), SpaceXAI (enterprise assistant), Hugging Face (model hub), Mistral, Reflection, Poolside, UneeQ, Fogsphere. 5,000+ deployment customers. Dell’s ecosystem breadth compensates for infrastructure gaps — ISV partners provide Layer 2B functions (Cohere North, DataRobot, ClearML) that Dell’s platform lacks. VAST’s ecosystem is focused and vertical: CoreWeave (hyperscale validation), TwelveLabs (video AI), CrowdStrike (AI lifecycle security), plus the Cosmos Community structure for SIs, CSPs, and ISVs. VAST’s ecosystem depth reflects platform self-sufficiency — ISV partners provide application use cases, not infrastructure functions, because the platform handles Layers 1A through 2C internally. The Dell comparison at Layer 3 reveals the DAPM trade-off between the two architectures: • Dell’s Layer 3 partners provide both application logic AND infrastructure-level functions (agent orchestration, governance, GPU scheduling). The partner ecosystem is load-bearing — remove Cohere North and Dell loses agent workflow orchestration. • VAST’s Layer 3 partners provide application logic ONLY. The partner ecosystem is additive — remove TwelveLabs and VAST loses a vertical use case but not a platform capability. This is the cleanest DAPM distinction in the comparative assessment: Dell’s ecosystem is structurally necessary. VAST’s ecosystem is strategically valuable. The ecosystem risk is real: enterprise buyers evaluate ecosystem breadth as a proxy for platform maturity. Dell’s partner roster with OpenAI, Google, Palantir, and ServiceNow signals broad market acceptance and Fortune 500 validation. VAST’s smaller roster signals focused applicability — strong in hyperscale and data-intensive verticals (media, financial services, government), less proven in general enterprise workflows. The CoreWeave validation deserves specific attention: at thousands-of-GPU scale, CoreWeave’s constraint is not compute but data coordination. ‘Adding more GPUs doesn’t recover performance if data flow breaks — it amplifies the inefficiency.’ This is a direct validation of the 4+1 model’s thesis that the data plane (Layers 1A/1B/1C) is the binding constraint for AI at scale, not the compute plane (Layer 0).
Distributed across partners at Layer 3, which is architecturally correct. VAST’s structural advantage: because the platform provides its own Layers 1A through 2C, Layer 3 partners bring only application logic and vertical use cases. They don’t need to bring infrastructure capabilities, and they don’t need to fill platform gaps. Compare to Dell: Dell’s Layer 3 borrowed judgment is distributed across partners who provide BOTH application logic AND infrastructure-level functions. The distinction is whether partners are additive (VAST) or load-bearing (Dell). The CrowdStrike integration is worth classifying separately: it operates at both Layer 3 (application-level security) and Layer 1A (data-layer monitoring). The integration connects AI OS telemetry to CrowdStrike Falcon for coordinated detection across the full AI lifecycle. This crosses layer boundaries — appropriate because security is a cross-cutting concern, not a single-layer function.
The $30B valuation, $4B+ bookings, and $500M+ CARR signal investor confidence. The CoreWeave $1.17B agreement anchors the customer base at hyperscale. But the enterprise deployment base is smaller than Dell’s 5,000+ and skews toward neoclouds and data-intensive verticals rather than traditional enterprise IT. The developer community track within Cosmos (hands-on labs, learning pathways, blueprint contributions) parallels Dell’s Enterprise Hub on Hugging Face but with a different emphasis: Dell’s Hub is about model access; VAST’s Cosmos is about building on the platform. The TwelveLabs partnership demonstrates the ‘customer-managed deployment’ model that is becoming the pattern for AI model companies moving from cloud-only to hybrid: the model runs on customer infrastructure (VAST AI OS) rather than the model company’s cloud. Dell’s equivalent is OpenAI Codex connecting to the Dell AI Data Platform and SpaceXAI Grok on-premises. The pattern is the same; the deployment substrate is different.
VAST is the most architecturally distinct vendor in this assessment series because it deliberately collapses traditionally separate infrastructure layers into a single platform. The VAST AI Operating System unifies storage (DataStore), metadata and vector database (DataBase + Catalog), global namespace (DataSpace), serverless compute (DataEngine), retrieval (InsightEngine), agent runtime (AgentEngine), governance (PolicyEngine), and model lifecycle (TuningEngine) under one authority boundary. Where Dell assembles 5–7 partner technologies to span Layers 1A through 2B, VAST provides a vertically integrated alternative with no inter-layer seams.
The Polaris control plane and PolicyEngine are the most significant Layer 2C signals from any infrastructure vendor. Polaris abstracts infrastructure location, allowing AI pipelines to operate against a single logical environment across on-prem, neocloud, and public cloud. PolicyEngine provides inline policy enforcement governing agent access to shared memory, tools, knowledge bases, and other agents. Together, they represent the clearest ‘middle-out’ approach to the control plane problem — building Layer 2C from the data layer up.
The DAPM trade-off is stark: VAST eliminates seams by collapsing authority into one vendor. The enterprise gains architectural coherence and eliminates integration risk. But the entire data plane, retrieval plane, agent runtime, AND emerging governance plane become a single Ceded dependency. If you run VAST, you run VAST for everything. There is no substitutability at any individual layer.
The $30B valuation, $4B+ in bookings, $500M+ CARR, and 1,000+ enterprise deployments validate market traction. The CoreWeave anchor ($1.17B commercial agreement) validates hyperscale credibility. The CNode-X partnership with NVIDIA (GPU-accelerated servers through Cisco and Supermicro OEMs) validates compute integration. But the product-market fit question for the 4+1 model is whether enterprises will accept total data-plane vendor dependency in exchange for architectural simplicity.
VAST is building the thing the 4+1 model says is missing. Whether the enterprise will buy it from a storage vendor is the open question.