The Architectural Moment When Function Invocation Boundaries Become Product Bugs

Persistent AI agent infrastructure and stateless serverless functions differ in what they keep between tool calls. A multi-step agent needs its working environment preserved, its actions authorized before execution, and its code isolated from other sessions. The function invocation boundary becomes a product bug when its API handoff fails to provide those three guarantees.

Why the function call boundary is not just an API surface

A function signature and a JSON payload describe how to call a tool. They do not describe whether the call is safe, whether its inputs are sound, or whether the environment still holds the agent’s unfinished work. The usual integration model is simple enough. Serialize the arguments, send them, and deserialize the result. That model puts the complexity in the model or the tool, leaving the handoff looking like plumbing.

For an agent, the handoff is a decision point. The agent reaches it with a fresh request, open files, partially written outputs, and session context. Three kinds of failure meet there. A semantic failure occurs when the model chooses the wrong function or gives it malformed arguments, while an enforcement failure lets the system run something the user never authorized. An infrastructure failure means the execution environment cannot preserve the state the next step needs. A valid API request can still fail all three tests.

Why do multi-step AI agents fail on stateless serverless functions?

A stateless invocation assumes the callee can start clean. A multi-step agent often needs the opposite. Its next action may depend on packages already installed, files half-written, and a browser session still open from earlier work. Starting a fresh function does not bring back that environment just because the request includes the conversation history. The conversation describes the work, but it is not the working machine.

That mismatch forces context reconstruction or continued work with missing state. Both paths can produce wrong outputs. A malformed or partial JSON result adds a related failure at the handoff, because an agent that accepts it can continue with bad data. Later steps may still look plausible, making the fault harder to diagnose than a crash. Keeping the environment cannot fix malformed data, but losing it adds another way for things to go wrong at the same boundary.

Interruption makes the distinction harder to ignore. A timeout, human check-in, or infrastructure restart can stop an agent while it still has unfinished work. If the runtime treats that interruption as the end of a disposable invocation, in-flight state is lost unless it has been preserved elsewhere. Stateless function and container deployment models are built around processes that can be killed and restarted. The limitation is not the ability to invoke a tool, but the lack of a durable continuation of the task between invocations.

What the Plan-then-Execute pattern reveals about where enforcement must live

Del Rosario et al. describe Plan-then-Execute as a split between a reasoning-intensive Planner and a simpler, faster Executor. The Planner produces a structured plan artifact, and the Executor invokes tools step by step. That separation supports predictability and lower cost. It also creates a handoff where a plan becomes action. A structured plan is not, by itself, permission to perform every step it contains.

The security gap appears when the Executor trusts that artifact without checking the next action against the original user objective. An indirect prompt injection retrieved during a web-search step can introduce an attacker’s instruction into the workflow. If that instruction tampers with the plan and reaches an unchecked Executor, faithful execution becomes the problem. The tool call can be well formed. The user still has not authorized what it does, and the same gap can let a tool be misused by mistake, even with no attacker.

Uchi Uchibeke describes the Open Agent Passport as a mechanism that intercepts tool calls before execution and evaluates them against a declared policy. That checks the action before it runs, which asking the model to behave safely or reviewing results afterward does not do. For high-stakes steps, human verification provides the final check by pausing before an irreversible action and requiring confirmation.

Why shared-kernel containers are the wrong isolation primitive for tool-executing agents

Authorization decides whether an action may run, while isolation limits what its execution can reach. These are separate controls, and neither replaces the other. Standard Docker/runc containers share the host kernel. That makes the kernel part of the exposure whenever an agent executes LLM-generated or user-supplied code inside a container. A vulnerability reached from one container can put the host or other tenants at risk.

Even trusted internal code can cause trouble with isolation. An autonomous agent can dispatch arbitrary inputs to a bash terminal, a production database, or a tool holding raw API credentials. A logic error can then exhaust resources, corrupt records, or misuse privileges while looking like an ordinary tool call from outside. Giving the agent more room to act increases the consequences of a mistaken action as well as a malicious one.

The architectural distinction is between a shared-kernel container and a machine-level boundary. It is not between a carefully worded prompt and a less careful one. The session-level microVM designs discussed below place isolation around the execution environment rather than relying on the agent to stay within bounds. That stronger boundary contains execution risk, while pre-action authorization must constrain what the agent is allowed to do, including database access.

What Firecracker microVM snapshots make possible at the function boundary

A Firecracker snapshot turns an execution handoff into a resumable checkpoint. It records guest memory, CPU registers, and every emulated device’s state so that the guest can continue where it stopped. The environment no longer has to start over. Combined with machine-level isolation, this addresses both the loss of working state and the shared-kernel mismatch. It does not decide whether the resumed agent’s next action is authorized.

The snapshot has two files with different jobs. The vmstate.bin file holds CPU registers and device state and is roughly 16KB no matter how much guest memory there is. The memory.bin file holds everything in guest RAM, so a 512MB VM has a 512MB memory image. This is more than saved conversation context. It preserves the execution state that a transcript alone cannot reconstruct.

Pausing a microVM takes under 1ms to enter and around 1.5ms p50 to wake. Full hibernation to a snapshot takes roughly 880ms to enter, with a roughly 21ms p50 wake on bare metal. Those operations have different costs. Restoring a checkpoint avoids rebuilding the environment from a cold start, though restoration itself is not instantaneous. Snapshots can also live in object storage, with userfaultfd memory demand-paging allowing the guest to become ready before its full RAM image crosses the network.

AWS Lambda MicroVMs, announced 22 June 2026, apply this model to individual user or agent sessions. Each MicroVM serves one tenant, has a dedicated HTTPS endpoint, starts from a snapshot, and suspends when idle while retaining memory and disk for an extended period. This changes the economics of waiting for human approval. An agent hibernated for minutes or hours consumes snapshot storage and releases its running allocation of RAM and vCPU. The human checkpoint no longer requires the machine to remain actively allocated throughout the wait.

How snapshot-fork changes the economics of running evals and RL rollouts at the function boundary

A fork consists of multiple restores of the same frozen snapshot, giving each branch the same memory, filesystem, and interpreter state. The shared preparation is paid for once. Each branch still needs execution resources, but it does not need to repeat the work that led to the checkpoint. That distinction makes branching useful for both evals and reinforcement learning rollouts.

Consider a snapshot taken at step 37 of a trajectory. The interpreter state, open files, and in-progress project stay as they were, so parallel branches can try different next actions from that point. Without that checkpoint, each branch would have to rerun the prefix or reconstruct an approximation of it.

Restored sandboxes inherit pseudo-random generator state, hostnames, machine IDs, and TLS session keys from the same snapshot. Those values must be reseeded on resume for the sandboxes to be genuinely independent. Otherwise, apparent parallelism can conceal shared state that corrupts eval results. The useful property is a common task checkpoint with independent identities for every branch.

Where the function boundary fails in regulated industries running legacy desktop apps

A legacy GUI application with no API makes the execution requirement explicit. The tool call must operate a desktop rather than send a request to an application endpoint. That desktop needs the application installed, signed in, and in a known UI state. A fresh container for each call cannot keep that state from one call to the next. The boundary now includes the Windows or Linux machine on which the application is running.

Computer-use benchmarks show the breadth of that environment. OSWorld covers OS, Office, Daily, Professional, and Workflow tasks, while WindowsAgentArena covers Windows-specific tasks. Android-World covers tasks done on smartphones using real Android applications. The execution surface extends beyond a terminal. An agent must preserve and navigate the state of the application it is using, whether the next action is part of a desktop workflow or a phone-only task.

In healthcare, lending, insurance, and property management, keeping that state also means meeting compliance rules. HIPAA requires systems that handle protected health information to have audit controls, access controls, and automatic session logoff. The regulation is technology-neutral and does not prescribe microVMs. Per-tenant isolation, audit-logging, and sanitization at session end are ways to meet those requirements, and per-session machines provide a clearer boundary for those controls than a shared execution environment. Isolation alone is not a compliance program.

A clinician or loan officer must be able to view and take over the agent’s desktop mid-task, before a high-stakes action proceeds. Rebuilding the desktop from scratch would break that handoff. The environment must remain accessible in the state the human is being asked to inspect. Here, persistence supports smoother execution, oversight, and patient safety.

Why per-session machine isolation is the architectural conclusion, not a premium feature

Each agent session needs one isolated, persistent, resumable machine, with authorization enforced before tool execution. Each part has a distinct job. Persistence keeps unfinished work, isolation keeps execution environments apart, and enforcement checks whether an action is part of the user’s task. Scoping installed tools and access to that session narrows what the agent can invoke. It does not remove the need to validate arguments or authorize actions through tools that remain available.

Amazon Bedrock AgentCore Runtime applies machine isolation at the session level. Each agent session gets its own microVM, state persists across multiple invocations, and the VM is terminated with its memory sanitized at session end. Sleeping snapshots make this model economically practical. Idle sessions consume storage and release running CPU and RAM allocations, so compute demand depends on active concurrency within the total number of retained sessions.

Thousands of identical failing tool calls can produce no useful work while accumulating cost overnight. Per-session metering makes that activity attributable to one session within a shared runtime. Isolation does not create an alert by itself. Nor does the ability to sleep stop an agent that remains active, so the machine boundary cannot substitute for the enforcement that the loop failed to encounter.

Keeping the computer separate from the intelligence layer also lets teams bring their own model and keys. Coding agents, eval pipelines, and computer-use agents need different environments, but for all of them, choosing a model is separate from making sure execution has the guarantees it needs. The design principle is plain. A function call should cross into an authorized action on the session’s preserved machine, retaining the work in progress and using access checked for that session.