Execution Models for Autonomous Agents

Execution Models for Autonomous Agents.

The execution model as the foundational decision in agent deployment

AI agents in 2026 aren't just answering questions anymore Fiserv launches agentOS. They're planning multi-step tasks, orchestrating workflows, and taking actions across connected systems with only light human supervision Fiserv launches agentOS. That shift changes the engineering requirements for building and deploying these systems. Adoption backs this up: over 57% of enterprises now run AI agents in production, and Gartner expects 40% of enterprise applications to include task-specific agents by 2026, up from under 5% just a year earlier AI Agents in 2026: The Future of Autonomous Software Fiserv launches agentOS Anthropic, 2026c.

Here's where most teams get tripped up. Writing the agent logic, the planning loop, the tool calls, the reasoning chain, is the easy part now. Frameworks have made that almost commoditized. What breaks projects is keeping that agent stable and predictable once it's live, running against real data, real users, real consequences. Gartner predicts more than 40% of agentic projects will get abandoned, and the reasons cited are blunt: costs spiral, the business value never materializes, risk controls are inadequate, or the project gets misapplied to a task it was never suited for AI Agents in 2026: The Future of Autonomous Software. Trace most of those failures back far enough, and the root cause usually is the execution infrastructure underneath the model.

That's the actual subject of this piece. The execution model, meaning how an agent's work gets isolated, how its state is managed, how scheduling and resource limits get enforced, is the decision everything else in a deployment sits on top of. Pick wrong, and no amount of clever prompting fixes it. The rest of this piece maps out the distinct execution model archetypes on the market right now, what trade-offs each one carries, and how to think about matching a model to the agent pattern you're actually running.

Agent execution environments versus sandboxes and frameworks

Three layers get flattened into one conversation constantly. There's the model, the LLM doing the reasoning. There's the framework, the code that defines agent logic, tool calls, and orchestration, things like LangGraph, CrewAI, AutoGen. And then there's the runtime: the execution layer that actually runs agents in production, isolating their code, scaling compute, persisting state, and controlling what an autonomous process is allowed to touch Fiserv launches agentOS.

So what separates an agent execution environment from a plain old code sandbox? Continuity is the answer. A sandbox is built for one-shot, discrete executions, run the thing, get the result, tear it down. An agent execution environment has to handle sessions that unfold over time, sometimes across dozens or hundreds of steps, where each step is shaped by everything that ran before it. That continuity is exactly what makes state so dangerous here. A compromised or malformed step early in a session doesn't just fail quietly, it can warp every step that follows it Fiserv launches agentOS.

There's another wrinkle sandboxes were never designed for. In a normal sandbox, a human decides what code runs before it runs. In an agent runtime, the model writes the code and it executes immediately, as part of an automated loop, with no human in between to whitelist it. You can't pre-approve what a model hasn't generated yet.

Tool use compounds this further. Agents call external APIs constantly as part of normal operation, and that creates a real tension: the agent needs connectivity to do its job, but every open connection is a potential exfiltration path. Add multiple agents running concurrently, and now tenant isolation matters just as much as workload isolation. One agent's execution shouldn't be able to see or touch another's, full stop.

Why does this definitional groundwork matter before diving into isolation models and archetypes? Because every execution model discussed from here forward makes different trade-offs across exactly these dimensions, continuity, state, connectivity, and tenant separation. Get the vocabulary straight now, and the comparisons later actually mean something.

The isolation question: why containers are not enough for multi-tenant agent workloads

Containers are where almost every team starts, and they're also where the most common miscalculation in agent infrastructure happens. It's an understandable instinct: containers are cheap, fast, familiar. But what if the isolation boundary itself is the weak point?

Containers share the host kernel. That's the whole design. A successful container escape hands an attacker access to the host node, and potentially to every other workload sitting on that same node Fiserv launches agentOS. For an agent that's just running trusted, bounded internal tasks, that risk might be tolerable. For an agent executing LLM-generated code on behalf of external users, it's a different calculation entirely.

Three isolation models map onto agent workloads, each with a different risk profile. Hardened containers work fine for internal agents doing low-risk, bounded work, but the shared kernel boundary becomes a real liability once external users are in the loop. gVisor sits in the middle: it intercepts syscalls before they reach the host kernel, which helps, but that interception layer adds latency, creates kernel feature compatibility gaps, and introduces its own attack surface. Each session gets its own guest kernel, so a compromise inside that guest doesn't hand over the host kernel directly, though the hypervisor itself is still part of what an attacker could target.

None of this comes free. Stronger isolation means slower starts, microVM initialization takes longer than spinning up a container, and once networking and runtime setup get included, the overhead stacks up beyond just VMM boot time. Pre-warmed pools are the usual answer to that latency problem, but they trade one headache for another: someone now has to manage pool sizing, handle drain-and-refill cycles, and eat the cost of idle capacity sitting around waiting to be used.

So the isolation choice isn't just a security checkbox. It sets a ceiling on how much multi-tenancy a platform can support, how much concurrency it can handle, and ultimately what kinds of tasks it's safe to hand an agent.

The five core requirements that any production agent execution environment must satisfy

Per-session isolation comes first. Each agent session needs its own dedicated boundary, so nothing running in one session can interfere with another. For multi-tenant deployments, this isn't a nice-to-have, it's the whole game.

Stateful execution support is next, and it's arguably where the gap between generic sandbox tooling and agent-native runtimes is widest. Agents that hold context across steps need real persistent storage that survives when the container dies.

Scoped outbound networking matters just as much. Tool calls need connectivity to work at all, but that connectivity should be locked down to known endpoints, with a default-deny stance on everything else. Anything looser turns every tool call into a potential leak.

Resource limits per session round out the operational side. A runaway agent loop can chew through CPU, memory, or I/O fast enough to degrade every other tenant sharing that infrastructure if there's no hard cap in place. At scale, resource governance stops being optional.

Audit logging and clean teardown close the loop. Every execution step needs to be traceable, what ran, what it produced, what it consumed, both for debugging and, increasingly, for compliance. Once a session ends, it needs to be fully destroyed, with nothing leaking state into whatever session runs next.

Stateful execution and clean teardown pull in opposite directions: one wants to keep context around, the other wants to erase everything. Resolving that tension has to happen in the execution model's design itself, not get patched on as an afterthought.

Judging by where the industry actually stands, most teams haven't cleared these bars yet. 88% of organizations report having had an AI-related security incident, yet only about 22% treat their agents as identity-bearing entities with the access controls that implies AI Agents in 2026: The Future of Autonomous Software Fiserv launches agentOS. That gap between exposure and governance is about as wide as it gets.

The three execution model archetypes and the agent patterns each one fits

The market has sorted itself into three layers as of 2026, and each one is a genuinely different execution model with its own architecture.

Managed hyperscaler runtimes are one end: AWS Bedrock AgentCore, Google's Gemini Enterprise Agent Runtime (the platform formerly known as Vertex AI Agent Engine), and Azure AI Foundry Agent Service. These fit enterprises with strict compliance needs, existing cloud contracts, and a preference for managed scaling over building runtime infrastructure from scratch. The trade-off is control: isolation primitives are largely fixed by the vendor, switching later means rebuilding on another platform's primitives, and cost climbs at scale, even though the governance tooling that comes bundled in tends to be mature.

Framework-native platforms are in the middle, LangGraph Platform and OpenAI's Agents SDK are the named examples. These suit teams already committed to a specific orchestration framework who want the runtime and the framework talking to each other natively, sharing state and observability without translation layers. Portability suffers here. Swap the framework or the underlying model, and the runtime tends to come along for the ride or resist the change.

Sandbox and serverless runtimes make up the third tier: E2B, Modal, Daytona, Fly.io Machines, Cloudflare's Workers and Sandboxes, Vercel Sandbox. This is the layer built for code-executing agents that need strong per-session isolation and fast provisioning with fine-grained resource control. Paired with Firecracker isolation, AWS Lambda handles short-lived agent tasks at real scale Fiserv launches agentOS. The cost of all this flexibility is engineering effort. Durable state and long-running execution take real work to bolt on, and observability tooling varies a lot from one provider to the next.

Reach for microVM sandboxes when agents are executing code, reach for durable-execution platforms when agents run long and autonomously, and reach for hyperscaler runtimes when the deployment has to satisfy enterprise governance first.

Topology is a second axis that layers on top of all this. A single agent running a linear, high-control flow, customer service is the classic example, behaves very differently from a distributed swarm of agents working a parallel, complex problem like supply chain coordination Fiserv launches agentOS. The execution model has to match the topology and the isolation requirement. Temporal is a durable-execution option, though its learning curve tends to get underestimated by teams picking it up for the first time.

A fourth tier is emerging alongside these three, sitting between framework-native platforms and raw sandbox tooling. These are developer-first, often curl-installable, agent infrastructure platforms built specifically to deploy, manage, and operate autonomous agents as a runtime substrate rather than a general-purpose compute layer. Engineering teams building at the edge of what's currently possible should watch this tier most. The best fit is for code-executing agents that need strong per-session isolation, fast provisioning, and workload-level resource control, and it is also appropriate for edge-latency requirements (Cloudflare Workers as a V8-isolate serverless runtime) and for snapshotted microVM environments for collaborative agent code execution (CodeSandbox SDK).

The agent operating system concept beyond a runtime

Agentic systems break traditional OS abstractions in a specific way: they're long-lived, goal-directed, they reason probabilistically instead of following fixed logic, and they invoke tools dynamically while adapting behavior based on feedback loops Fiserv launches agentOS. A runtime alone doesn't fully account for that. It handles execution, but an agent operating system tries to handle something bigger.

The distinction that actually matters here is workflow automation versus an agentic OS Fiserv launches agentOS. Workflow automation runs a deterministic, predefined path, step two always follows step one, no exceptions. An agentic OS does something different: it routes around exceptions as they come up, makes context-aware decisions on the fly, and holds state across runs, handling whatever path the agent's own reasoning produces at runtime. That's a meaningfully different job.

Consider what a modern agentic application actually has to juggle: a planner, several specialized agents, model endpoints, retrieval systems, durable memory, tool adapters, business workflows, human approval checkpoints, identity services, policy engines, and compute spread across regions Fiserv launches agentOS. No single runtime layer was ever built to coordinate all of that at once.

The two-plane design that's emerged to handle this complexity splits the problem cleanly. A Control and Governance Plane decides what should happen, under whose authority, and subject to which constraints, capturing intent, discovering eligible capabilities, checking policy and trust and consent, and logging audit obligations. A Runtime and Coordination Plane handles how that approved work actually gets carried out: agent lifecycle, workflow progress, routing between models and tools, memory coordination, scheduling, traffic management, and runtime assurance.

Microsoft put real weight behind this framing at Build 2026 in San Francisco, reframing the personal computer itself as an agentic operating system, a machine where software agents plan, remember, and act on a user's behalf instead of waiting around for a click Fiserv launches agentOS. Alongside that, Microsoft open-sourced the Microsoft Agent Framework under an MIT license, with SDKs in Python,.NET, and Go Agentic Operating System Fiserv launches agentOS. The four components Microsoft pointed to as the building blocks of an AOS: a runtime that keeps agents alive and coordinates several working on one task, a memory layer that persists context across sessions, a model-routing layer that picks the right model per step, and a governance layer covering evaluations, access rules, and audit logs Fiserv launches agentOS.

None of this is abstract theorizing dressed up as architecture. It's the frame that actually explains why the runtime market keeps drifting toward more integrated platforms instead of staying satisfied with bare execution layers.

AOS concepts in production: desktop automation and domain-specific deployments

Theory is one thing. Two concrete deployments show what this looks like once it ships.

UFO2 is Microsoft Research's multiagent AgentOS for Windows desktops. The problem it's solving is a real one: most computer-using agents up to this point have stayed conceptual prototypes, held back by shallow OS integration, brittle screenshot-based interaction, and execution that disrupts whatever the user is doing.

The hybrid control detection is the clever part. It fuses Windows UI Automation with vision-based parsing, so the same session can handle an app with a proper API and an app with none at all. Speculative multi-action planning cuts down per-step LLM overhead, a gain that comes purely from the execution model's design, not from the underlying model getting smarter. Safety is built into the state machine itself: when an AppAgent detects an action matching predefined risk criteria, it flips into a PENDING state, pauses, and waits for explicit user confirmation before proceeding, aborting the action otherwise. Every session gets logged in fine detail too, prompts, LLM outputs, control metadata, UI state snapshots, error events, all compiled into a structured Markdown log that supports prompt editing and selective replay.

The payoff appears in the numbers. Paired even with a general-purpose model like GPT-4o, UFO2 beats dedicated computer-using agents by more than 10%, and that gain gets attributed to system-level integration rather than any advantage in the model itself UFO2: The Desktop AgentOS (2025). Under the hood, it's over 30,000 lines of Python and C#, with Sentence Transformers doing embedding-based retrieval for documents and past experience. In the broader stack, it occupies a specific niche: desktop-native, OS-integrated, sitting below cloud hyperscaler runtimes but above raw RPA tooling, relevant anywhere agents need to drive Windows GUI applications without requiring purpose-built APIs.

Fiserv's agentOS shows the same AOS thinking applied to a completely different domain: banking. It's built to deploy, manage, and scale AI agents across financial workflows, and it launched with six financial institutions co-developing it alongside Fiserv, two of which already had agents running in beta Fiserv launches agentOS. Wide availability is expected by August 2026 Fiserv launches agentOS. The design goal is to run natively across Fiserv's existing platforms, core banking, payments, issuer processing, servicing, so institutions can move past isolated pilots into enterprise-grade deployment with policy controls, auditability, and human oversight built in from the start.

Two very different domains, desktop automation and regulated banking infrastructure, converging on the same underlying architecture: a control layer deciding what's allowed, and a coordination layer figuring out how to actually get it done. That convergence is probably the strongest signal yet that the AOS framing is a durable architectural pattern Fiserv launches agentOS. It's describing something the infrastructure was already being pushed toward. The architecture consists of a centralized HostAgent (control plane) for task decomposition, coordination, error handling, and lifecycle management, alongside application-specialized AppAgents with native APIs, domain-specific knowledge, and a unified GUI–API action layer. SOURCE PAGES (what the pages behind the outline's links say).