VAST Data

AgentEngine & MCP

Advanced

Run, govern, and observe AI agents next to the data they reason over - with a shared MCP tool registry.

Why run agents next to the data

An agent isn't one model call - it's a loop that reasons, calls a tool, observes the result, and repeats (see Agentic AI). Almost every step touches data: a query, a function, a memory lookup. When the agent runs far from that data, every tool call crosses the network, latency compounds across dozens of steps, and the audit trail fragments across systems that don't share a log.

VAST's answer is to move the agent onto the data plane. is an agentic-AI runtime that runs natively inside DataEngine - the application-management layer of the VAST AI Operating System - so multi-agent workflows execute next to the data, with a built-in tool registry and unified audit instead of glue code and governance gaps.

Run the agent loop - the distance to the data compounds

The same 10-step task, run twice. Every step makes a tool call that has to reach the data and come back. Far away, each call crosses every owner's trust boundary and leaves a partial record in each owner's log; next to the data it stays in one plane.

1/10

Far from the data

Trust-boundary crossings
8
Separate audit logs
5
Partial log entries
5

Next to the data

External crossings
0
Audit logs
1
Log entries (whole call)
1
FAR FROM THE DATA - 5 HOPS, 5 OWNERSNEXT TO THE DATA - AGENTENGINE, ONE PLANEOne trust boundary - DataEngine on the VAST AI OSNo gateway, connector or egress hopAgent host(cloud VM)agent runtime,separate from dataAPI gatewayauth, rate limitsConnector /ETL servicetranslateseach requestNetwork egresscross-regiontransfer + costStorage /data platformthe data finallylives hereAgent (AgentEngineruntime)runs inside DataEngineMCP Toolbox(local)in-platform toolcall, auditedVAST data planedata is right here

Loop step 1 of 10: reason, make one tool call, observe the result. Far path: +8 boundary crossings, +5 partial log entries. Next to the data: no external crossing, +1 entry.

Audit trail - fragmented

Each call leaves a partial record in 5 logs with 5 owners, to be stitched back together.

Agent host log
API gateway log
Connector / ETL log
Network egress log
Data platform log

Audit trail - unified

Each call is one entry holding the whole tool call, in the platform's own log.

AgentEngine log

1 entry in 1 log vs 5 pieces across 5.

Takeaway: the path cost is paid on every step, not once - after 10 steps the far agent has crossed a trust boundary 80 times; next to the data, none.

Counts are derived from the illustrative hop lists above (4 boundaries between 5 separately owned hops, crossed out and back per call), not a benchmark. AgentEngine is preview/roadmap.

AgentEngine: the four pillars

AgentEngine is organized around four pillars: a Runtime that deploys and checkpoints agents, a Studio for wiring them to tools and data, a Toolbox registry of shared MCP tools, and Observability for everything they do. Explore each below.

AgentEngine - the four pillars, around agents running next to the data

The application-management layer of the VAST AI Operating System. Follow one request through it, or tap a pillar to see what it does and why it matters.

Preview / roadmap
1/6Request in
DATAENGINE - VAST AI OSdeploytracesrequestSTUDIOdesign-timeIDEcompose agentsfunction → MCP toolinto the ToolboxPolicy: identity, access, auditchecked before each actionset before anything shipsRUNTIME - agent containers on Kubernetesagent Acontaineragent Bcontaineragent Ccontainermodels loaded in GPU memory · agent state checkpointedTOOLBOX - SHARED MCP REGISTRYversioned · monitored · reusabledata queryfunctionweb searchother agentVAST DATA PLANEtables · objects · embeddings · agent memory · vector searchOBSERVABILITYrun-time evidenceaccess logs & tool metricsprompt / response historychain-of-thought tracefeedback captureTRACE - agent Arequestpolicy checktools/calldata readanswerfeedbackillustrative spans

Request in: A request reaches agent A, running as a container in the Runtime - inside DataEngine, next to the data.

Deployment & Runtime
Run agents on the data plane

What it does

A Kubernetes-based runtime that deploys agents as containers, loads models into GPU memory, and checkpoints long-running agents so their memory and reasoning state survive failures.

Why it matters

Agents that run for hours can crash, get preempted, or hit a tool timeout. Checkpointing means a long task recovers from where it stopped instead of starting over - durability for autonomous work.

  • Container deploy on Kubernetes
  • Models loaded into GPU memory
  • Checkpoint agent state (memory + reasoning)
  • Recover long runs without losing progress

Crash & recover - a long run, step 7 of 12

With checkpoint
◆
Without checkpoint

Running... ◆ marks the last checkpoint. Step numbers are illustrative.

MCP & the shared Toolbox

The is the open standard for connecting agents to tools. VAST exposes its data, metadata, functions, web search, and even other agents as MCP-compatible tools through AgentEngine's tool server - a native MCP registry built into the data platform, not a bolt-on. Every tool in the Toolbox is versioned, monitored, and reusable across agents and teams, so a connector built once becomes a governed building block rather than per-project glue.

The MCP Toolbox - one registry, many tools, many agents

VAST exposes data, functions, web search, and other agents as MCP-compatible tools. Each is versioned, monitored, and reused across agents. Tap an agent or a tool; follow one call through the registry.

Preview / roadmap
1/7
AGENTSSHARED REGISTRYTOOLSMCP Toolboxone shared registryversioned · monitoredAudit logevery callClaims agentdata_query v1refund v1Support agentrefund v1data_query v1Research agentweb_search v1data_query v1Orchestratorsummarizer v1web_search v1Data queryVAST DataBase / S3 objectsused by 3 agentsFunctionCustom MCP toolused by 2 agentsWeb searchExternal connectorused by 2 agentsOther agentAgent-as-a-toolused by 1 agent

Call sequence - claims agent calls data_query

MCP message names; tool names illustrative

AgentToolboxToolAudit log
  1. tools/list
  2. tool list + schemas
  3. tools/call data_query
  4. run v1
  5. result
  6. result
  7. logged

Step 1: The agent asks the registry which tools it may use.

Data query - VAST DataBase / S3 objects

Read tables, objects, and metadata exposed by the platform directly as an MCP tool - no separate connector to maintain.

Shared by claims agent, support agent, research agent

Versioned - reuse without breaking

Each agent pins the tool version it was built against. Publish a new data_query version to see who moves and who doesn't.

Agents, wiring and version labels (v1, v2) are illustrative.

Governance & observability for agents

Autonomous systems are only trustworthy if you can see and constrain them. Studio sets identity, access, and audit policy up front; the Toolbox versions and monitors every tool; and Observability captures what actually happened at runtime.

One agent run, as governance sees it

A claims agent looks up a claim and issues a refund. Four lanes record the same run. Ask a question to see which lane answers it.

1/7
Identity & access
✓
✓
✓
Access logs & tool metrics
query
refund
Chain-of-thought tracing
reason
reason
answer
Feedback capture
approved
one run (illustrative) →

Run starts: the agent's identity and policy are loaded.

tool calls logged: 0

Ask the trace

Studio sets identity and access up front; the Toolbox logs and meters every tool call; Observability keeps the reasoning trace and the feedback - all tied to the same run.

The run, its steps and timing are illustrative. AgentEngine is preview/roadmap.

How it composes with DataEngine & the platform

AgentEngine doesn't stand alone. It runs inside DataEngine on the same platform that stores the structured and unstructured data, embeddings, and agent memory those agents reason over - so the runtime, the tools, and the data share one governance and storage plane.

One stack, one plane - how AgentEngine composes

Runtime, tools, and data share the same governance and storage plane. Tap a layer, or a label below.

one plane

AgentEngine on DataEngine: Agents deploy as containers and execute on the data plane, close to what they read and write.

Maturity & what to watch

AgentEngine and its MCP Toolbox were announced in May 2025 and are not yet generally available. As of VAST AI OS 5.5 (August 2026), running AgentEngine on the new Native Compute layer is listed for an upcoming release. Plan around the architecture and direction, and confirm current availability with VAST before committing to a deployment.

Status board - where AgentEngine stands

Both components are announced and not yet generally available.

Preview · upcoming release

AgentEngine runtime

Preview
  1. ✓AnnouncedMay 2025
  2. ●Previewupcoming release - where it is now
  3. Generally availablenot yet - watch for dates

MCP Toolbox registry

Preview
  1. ✓AnnouncedMay 2025
  2. ●Previewupcoming release - where it is now
  3. Generally availablenot yet - watch for dates

What to watch

GA dates

VAST AI OS 5.5 lists AgentEngine on Native Compute for an upcoming release. Watch for GA dates on the runtime, Studio, and Toolbox before treating anything as production-ready.RuntimeStudioToolbox

MCP spec

Track how closely the offering follows the evolving MCP spec, especially identity, audit, and async operations.identityauditasync

Status as of September 2026, from VAST announcements. Announced in May 2025 and not yet generally available; VAST AI OS 5.5 (Aug 2026) lists AgentEngine on Native Compute for an upcoming release. Confirm current status with VAST before deployment.

Related

AgentEngine is the platform side of the agent story. For the concepts - the agent loop, , , and orchestration - start with Agentic AI.

Agentic AI →RAG & Vector Search →VAST Data →

Key takeaways

In one line

AgentEngine runs governed AI agents inside DataEngine, next to the data, with a shared, versioned MCP tool registry - announced May 2025 and not yet generally available.

Key points

  • AgentEngine is organized around four pillars: Runtime, Studio, Toolbox, and Observability, covering deployment, tool wiring, a shared MCP registry, and audit trails.
  • The Model Context Protocol (MCP) lets VAST expose data, functions, web search, and other agents as versioned, monitored, reusable tools through a shared Toolbox registry.
  • Running the agent next to the data collapses a typical five-hop path into one local, audited data plane.
  • AgentEngine and its MCP Toolbox are not yet GA; as of VAST AI OS 5.5 (Aug 2026), AgentEngine on Native Compute is listed for an upcoming release.

Questions to explore

  1. 01How many hops does a tool call take today between your agents and the data they reason over?
  2. 02Could you trace which agent touched which data, and how often, if asked?
  3. 03How many separate connectors does your team maintain to give different agents access to the same data?

Common questions

Is AgentEngine generally available today?
No - AgentEngine and its MCP Toolbox were announced in May 2025 and are not yet GA; VAST AI OS 5.5 (Aug 2026) lists AgentEngine on Native Compute for an upcoming release. Confirm current availability with VAST before planning a deployment.
How is MCP different from a normal custom API integration?
MCP is an open standard: VAST exposes data, functions, web search, and even other agents as MCP-compatible tools through a native tool server, so each connector is versioned, monitored, and reusable instead of one-off glue code.
What does the governance story actually consist of?
Studio sets identity, access, and audit policy before an agent runs, the Toolbox versions and monitors every tool, and Observability logs every tool call, prompt/response history, and chain-of-thought traces.