Purpose-Built Agent Runtimes vs. General-Purpose Cloud Functions
A platform that lets hundreds of autonomous agents run on a schedule, survive restarts, and pick up exactly where they left off needs more than a cloud function with a longer timeout. So it needs a runtime where persistence, identity, and long-horizon execution are default behavior, not add-ons. General-purpose serverless computing, the AWS Lambda model most teams reach for first, was built for a different job entirely, and that mismatch is the subject of this piece.
Why general-purpose cloud functions were not designed for agents
AWS Lambda and its relatives run on one guarantee: each invocation stands alone. Code runs, a result comes back, and the environment that produced it disappears. This is the entire point of serverless computing, built so a single calculation, a single query, a single transformation can run cheaply and scale without anyone managing a server.
That design fits tasks with no memory requirement. A function that resizes an image or validates a webhook payload doesn't need to remember what happened five minutes ago, because nothing happened five minutes ago that matters to it now. An autonomous agent is a different kind of workload. It plans across multiple steps, holds onto what it learned three turns back, and acts differently in step ten because of something that happened in step two. A serverless function asked to behave that way has nowhere to put the memory. The environment that held it was already thrown away.
This isn't a missing checkbox in a configuration panel somewhere. A research paper on agent infrastructure, Agentverse, describes the arrival of autonomous agents as first-class participants in digital infrastructure as a fundamental inflection point, one that existing cloud abstractions were never built to serve. Serverless wasn't designed with agents in mind because agents, as a workload category, didn't exist yet in the form they take now. The rest of this piece works through what that gap actually costs a team trying to run agents at scale.
The three properties agents require that ephemeral runtimes cannot provide
Three things separate an agent that works in production from one that falls apart after a few hours: persistent state, durable identity, and long-horizon execution. None of them are nice-to-haves. If any one is missing, the agent can't complete real work, so the other two stop mattering.
Persistent state comes first: without it, an agent has no memory across invocations. Every invocation starts blind. Picture a coding agent that clones a repository, installs dependencies, edits a handful of files, and runs a test suite. On an ephemeral runtime, every single action in that sequence forces a fresh clone and a fresh install, because the workspace from the last step is already gone. On a stateful runtime, that setup cost gets paid once and the workspace just keeps existing. Northflank's 2026 comparison of agent runtimes states the distinction directly: ephemeral infrastructure fits one-shot execution, while stateful infrastructure fits multi-step, long-horizon work. Those are two different jobs, and trying to do the second one with tools built for the first means paying the setup cost over and over.
Durable identity matters for a related but separate reason. Agents that talk to external systems, wait on human approval, or coordinate with other agents need to show up as the same recognizable entity across an entire session. A new microVM instance spun up for every call can't hold that identity, because there's no continuous "it" to hold it. The Agentverse paper lists persistent identity as one of four defining traits of what it calls the Agents as a Service layer, alongside autonomous execution, economic agency, and protocol-mediated interoperability. Agents need to be recognizable participants other systems can track, not anonymous compute that happens to produce similar-looking output each time.
Long-horizon execution is the third piece, and this is where hard limits turn into real operational pain. When agents investigate a production incident, work through a data pipeline, or coordinate a multi-agent workflow, they often run for minutes or hours, not milliseconds. E2B's Pro plan documents a 24-hour session cap. Hitting that ceiling mid-task forces awkward checkpointing, which breaks the continuity the agent needed. Northflank's comparison lists session duration limits as one of the decisive factors in evaluating an agent runtime, precisely because long-horizon work is the kind of work that breaks first against a low hard cap.
Line these three up and a chain appears. No persistent state means no memory across steps. No durable identity means no way for other systems to trust that the agent asking for something now is the same one that asked five minutes ago. If long-horizon execution isn't there, the agent gets cut off before it finishes the task that needed all that memory and identity. Each gap makes the other two worse.
Context windows versus real state management
Faced with no persistence layer, a lot of teams try the obvious workaround: just stuff everything into the prompt. Keep piling retry records, tool outputs, and progress notes into the context window and let the model carry it all forward. That approach works for a while and then stops working, usually right when the stakes go up.
A language model has no memory between calls on its own. Every invocation starts from scratch, built entirely out of whatever text sits in the prompt at that moment. Context is not persistence, no matter how large the window gets. As an agent session runs longer, the context window swells with accumulated history, retries lose track of what already happened, and approvals that were granted three steps ago quietly vanish into scrollback nobody is reading anymore.
So you need to split the agent's work into two different kinds of information. Current-turn reasoning, the thing the model is actively working out right now, can stay in the model's working memory. Everything durable, retry records, pending approvals, tool results, progress markers, needs to live somewhere built to store and query it reliably. Business records belong in a relational database like PostgreSQL. Event flow belongs in a message queue like Kafka or SQS. Multi-step progress belongs in a workflow engine like Temporal or Durable Functions. Each of these tools exists because each kind of data has different durability and query needs, and none of them get met by a longer prompt.
That architecture is absent inside a pure serverless function. An ephemeral runtime has no place to write durable state between invocations. Teams end up wiring in a database, a queue, and a workflow engine by hand, on top of the function platform, just to get back the persistence the platform didn't provide. At that point the "managed infrastructure" a team picked serverless for in the first place has mostly stopped being managed. A purpose-built agent operating system approaches this differently from the ground up. UFO treats memory and context as orchestrated subsystems within a unified platform, so a team isn't manually wiring together a database, a queue, and a workflow engine just to get an agent to remember what it did an hour ago.
Security and isolation requirements that serverless functions leave unaddressed
State is only half the problem. Agents don't just need to remember things, they need to execute code safely, and a lot of that code isn't code anyone reviewed first. It might be LLM-generated on the fly, submitted by a user, or pulled in from a third-party tool. All of it has to be walled off from the host machine and from every other tenant sharing that infrastructure.
The isolation model is where this starts. Container-level isolation shares a kernel with the host, and a kernel-level exploit can cross that boundary. For workloads where the code itself isn't trusted, the production baseline has shifted to microVMs, Firecracker and Kata Containers among them, or kernel-sandboxing layers like gVisor. Northflank's comparison lists the isolation model as the first criterion it evaluates runtimes on, because microVMs give much stronger separation between tenants than containers alone can offer when the code running inside them wasn't written by anyone on the team.
Isolation is the floor, not the ceiling. A production-grade agent runtime also needs least-privilege execution, traceable identity for every action, an audit trail across the whole session, validated deployment paths, and some mechanism for a human to interrupt the agent mid-task if something goes wrong. The 2026 Singapore Consensus on Global AI Safety Research Priorities lays out ten foundational principles for managing this kind of risk: least privilege, traceable identity, auditability, validated deployment, adversarial resilience, multi-agent stability, runtime assurance, interruptibility, legibility, and human oversight. A standard serverless function provides none of these on its own.
You can see the gap concretely inside real engineering teams, not just in safety frameworks. Slack's security team tested a coding agent CLI as the execution layer for an investigation tool and found it fine for prototyping but short of what production needed. They needed to watch investigations happen in real time, review and share past investigations, kick off new ones on demand, and connect the system to their existing detection tools, so investigations could trigger automatically. A stateless function invocation lacks a persistent interface, so it can't surface any of that.
Enterprise buyers add one more hard requirement: execution inside the team's own cloud environment, a BYOC capability most managed-only platforms simply don't offer. For a bank or a healthcare system, running agent workloads outside the company's own VPC blocks procurement approval.
The gap in major cloud platforms' 2026 agent runtimes
AWS, Microsoft, and Google have all built dedicated agent runtime layers in 2026, separate from their existing serverless products. Companies that size don't build new infrastructure categories without real demand behind them, and three of them reaching the same conclusion independently says something about how structural the gap actually is.
AWS shipped AgentCore Runtime V2 on 18 September 2026. The update restores new instances from a prepared snapshot for faster cold starts and reclaims memory elastically throughout a session, a design aimed directly at the ephemerality problem that standard Lambda functions never solved. Microsoft made Foundry hosted agents generally available in July 2026, and at Build 2026 it went further and reframed Windows itself as a controlled runtime for AI agents. The centerpiece was Microsoft Execution Containers, an OS-level security sandbox, launched with integration partners including OpenAI, NVIDIA, and GitHub Copilot CLI. Cloudflare took its Containers and Sandbox SDK to general availability in April 2026, and it built agent-specific primitives directly on top of its existing Workers infrastructure, so teams didn't have to bolt them on separately.
The pattern doesn't stop at the big three cloud providers; it reaches into vertical industries now building their own agent infrastructure for specific markets. Fiserv launched agentOS on 14 May 2026, an agentic operating system for financial institutions built natively across its core banking, payments, issuer processing, and servicing platforms, with an agent marketplace covering risk management, regulatory reporting, deposit operations, and back-office reconciliation. OpenAI and AWS are listed among its collaborators.
Agentverse frames all of this as more than a coincidence of timing. The paper proposes a new layer in cloud architecture, Agents as a Service, sitting above the familiar stack of IaaS, PaaS, SaaS, and FaaS, characterized by persistent identity, autonomous execution, economic agency, and protocol-mediated interoperability. Each of these companies arrived at a version of this same layer from a different direction, a bank-focused platform, an operating system vendor, a cloud compute provider, which is itself a form of evidence. When independent organizations with no reason to coordinate all build toward the same architecture, the simplest explanation is that the old architecture genuinely couldn't do the job.
How purpose-built agent runtime platforms address what serverless cannot
Purpose-built agent runtimes don't patch the ephemeral model; they replace the premise that execution can be stateless and disposable. Persistent environments, strong isolation, GPU access, and operator controls get built in as native primitives from the start. Evaluating a runtime against this new category means checking it against six concrete dimensions: the isolation model it uses, whether it supports both ephemeral and persistent environments, its session duration limits, GPU availability, support for bringing your own cloud, and how it prices usage. Northflank's 2026 comparison runs the leading platforms through these same six dimensions, and the picture that emerges is useful for anyone deciding where to run agents at scale.
Northflank itself is a full-stack runtime covering agents, APIs, background workers, databases, cron jobs, and isolated sandbox execution under one control plane. Isolation runs on microVMs, Kata Containers paired with Cloud Hypervisor, Firecracker, along with gVisor for kernel-level sandboxing. It supports both ephemeral and persistent environments with no forced time limit on either. GPU access spans L4, A100 40GB, A100 80GB, H100, and H200 tiers, available on demand. BYOC is self-serve across AWS, GCP, Azure, Oracle, CoreWeave, and Civo, with on-premises and bare-metal deployments supported through Bring Your Own Kubernetes. The platform has been in production since 2021, and a new environment comes up in one to two seconds end to end. As of April 2026, pricing runs per second across CPU, memory, and GPU tiers, from entry-level L4 up through H200 accelerators, though current rates are worth checking directly on Northflank's pricing page before budgeting against them.
E2B takes a narrower approach, built specifically as a sandbox tool for AI agents and LLM applications. It uses Firecracker microVM isolation and supports both ephemeral and persistent environments, but offers no GPU access. BYOC is limited to the enterprise tier on AWS and GCP and requires contacting sales directly; there is no self-serve setup. Sessions cap at 24 hours on the Pro plan. Billing runs per second for CPU and memory.
A purpose-built agent operating system like UFO takes a third approach: it treats persistent state, durable identity, and long-horizon execution as foundational design choices, not features layered onto an execution model built for something else. Where Northflank and E2B compete primarily as infrastructure layers teams build agent systems on top of, UFO is architected as the operating layer itself, reshaping how the runtime behaves around the agent's actual needs rather than asking the agent to adapt to a runtime built for stateless functions.
The six evaluation dimensions, isolation model, ephemeral versus persistent support, session limits, GPU availability, BYOC, and pricing, give any team a concrete checklist for comparing options against a vendor's claims. What the comparison keeps showing, across AWS's snapshot restores, Microsoft's OS-level sandboxing, and the dedicated runtimes built specifically for agent workloads, is that the industry has stopped treating this as an edge case. Running autonomous agents reliably at scale requires infrastructure built around what agents actually need, not infrastructure that happened to be available when agents showed up.
