Why AI Agents Need a Runtime, Not Just a Gateway (2026)
A gateway decides which agent can reach which tool, logs that it did, and applies a policy. That's a routing decision, made once per call. It says nothing about what happens to the actual work behind that decision once the call goes through. Most agent infrastructure treats that work as one shared, always-on process, which means idle capacity nobody's using most of the time, and a blast radius that spans everything sharing that process. Metorial's own gateway routes every MCP connection through a single governed path, but the work itself runs in enclaves, isolated sandboxes allocated per user, per connection, and per tool call, orchestrated by a purpose-built engine the team describes as its own Kubernetes for MCP. The gateway is the front door. What's behind it is what determines the bill and how far a bad day can spread.
A gateway's job is narrow: decide whether an agent can reach a given tool, log that it did, and apply a policy. That decision gets made once per call, at the door. It says nothing about where the actual work happens once the door opens: the API request, the script, the tool execution a server carries out on the agent's behalf. Two systems can look identical from the outside, one URL, a token-free sign-in, a policy check on every call, and answer that second question in completely different ways underneath.
What happens to a persistent, always-on process when nobody's calling it?
Widely cited McKinsey and Uptime Institute research on enterprise data centers found that typical servers rarely exceed 6 percent utilization over a year, and that as much as 30 percent of servers run while doing no useful work at all, sized for a peak load they hit rarely, idling the rest of the time. Agent tool traffic follows the same shape: a support agent might make ten tool calls during one customer conversation, then nothing for an hour. Infrastructure built to run as one long-lived process per integration or per customer has to be sized for that occasional burst, which means it sits idle, and billed, most of the time it exists.
What happens when one integration misbehaves inside a process shared by others?
The other cost of a shared, long-lived process is what happens when something inside it goes wrong. A bug or a compromised integration running in the same process as everything else that customer or company depends on is a neighbor to all of it, not a contained incident. The question worth asking about any agent infrastructure isn't "is this sandboxed." It's "how many other things are in the same sandbox," because a single sandbox shared across a whole tenant or a whole company still means one bad actor can reach everything else in it.
What does isolating every call, not just every tenant, look like?
The Metorial Gateway is the single governed path every MCP connection in a company goes through, whether it's a Magic MCP link, a custom server, or a remote one. Underneath that gateway, the Metorial Engine, described by the team building it as their own Kubernetes built specifically for MCP, is the scaling and orchestration layer for what Metorial calls serverless MCP. Every integration runs inside an enclave, a fast, sandboxed environment, and enclaves aren't allocated one per customer. They're allocated per user, per connection, and per tool call, so the blast radius of any single interaction going wrong stays at that one interaction instead of spreading to everything else that customer or company runs.
Does isolating down to the tool call cost speed?
Isolation this granular sounds like it should be slow, and historically, heavier sandboxing usually did add latency. Metorial's own enclaves are built to stay lightweight enough that the isolation doesn't cost the speed agents need, and Metorial isn't the only place this instinct is showing up. GitHub's own Copilot agent sandbox, released as a public preview this year, runs agent-generated code in isolated, stateful cloud environments with support for snapshot and resume, rather than one shared, long-lived process. The direction of travel across the industry is the same: isolate agent work by default, and make the isolation cheap enough that nobody has a reason to skip it.
What should you ask a vendor about the layer behind their gateway?
A gateway is the part every vendor in this category can point to and demo in five minutes: paste a URL, sign in, see a tool call go through. What runs behind that demo is harder to see and matters more once real traffic hits it. Three questions surface the answer: what happens to the compute when nobody's calling it, does it keep running and billing regardless, or scale down close to zero. What's the blast radius of one integration misbehaving: one process for the whole company, one process per customer, or one sandbox per call. And is that isolation the default, or something reserved for an enterprise tier.
FAQ
Isn't a gateway enough to keep agent traffic secure?
A gateway secures the decision of who can reach what. It doesn't determine what happens to the compute carrying out that decision, which is a separate architectural question with its own cost and blast-radius consequences.
What is an enclave?
A fast, isolated sandbox that runs a single integration's code. Metorial allocates one per user, connection, and tool call, rather than one shared sandbox per customer or company.
Does per-call isolation slow agents down?
Not on Metorial's own infrastructure: enclaves are built to be lightweight as well as isolated. Heavier, traditional sandboxing has historically added latency, which is why some vendors avoid fine-grained isolation altogether.
Is this only relevant at enterprise scale?
No. Idle, always-on compute and shared blast radius both show up at any scale where more than one integration or customer runs on the same infrastructure, which is most agent deployments past a first pilot.
How is this different from typical container-based isolation?
Many container setups isolate per customer or per deployment, not per individual call. Metorial's enclaves scope isolation down to each user, connection, and tool call, which narrows the blast radius further than a per-tenant container would.