Hitting Lambda Limits on a Live Agent Product and What the Fix Actually Looks Like

Persistent AI agent infrastructure fits long-running, stateful sessions better than serverless functions because it preserves the environment between turns, while serverless functions rebuild it for each request. Hitting Lambda’s limits in a live agent product is often a sign of that mismatch. The fix is to choose an execution environment that matches the work, while keeping Lambda for the bounded, stateless jobs it handles well.

Why do long-running AI agents struggle on serverless functions?

Lambda was built for a different shape of work. Its architecture assumes that each invocation is independent, brief, and stateless. That fits webhooks, event processors, and API endpoints, where a request arrives, some work happens, and the function exits. A stateful agent session does not fit that pattern because each turn depends on what came before.

An agent may need to keep its conversation history, decision log, loaded tools, and working context for the whole task. Lambda does not provide persistent working memory across invocations, so that context must move into external storage such as DynamoDB or S3 and return when the next turn begins.

When an agent has a large set of dependencies to load, it takes longer to start processing, but an interactive product may need sub-100ms responsiveness. A conversation also multiplies invocations through messages, streaming responses, retries, and state-handling functions. As those calls accumulate, the economics can turn against Lambda, making a representative agent workload materially more expensive than container-based compute such as Fargate.

The specific limits that become hard walls in a live agent product

The execution timeout turns a design assumption into a deadline. Lambda gives the agent up to 15 minutes to process a task, whether or not it has finished. For a continuous agent loop, that boundary is not merely an inconvenience. The function may have to stop before the task reaches its own stopping point.

Lambda has account-level and function-level concurrency limits, and AI workloads can hit them and produce throttling. A product can therefore run into trouble even when individual invocations finish within their time limit. This is a configuration trap as well as a capacity constraint, because the limits are easy to overlook until traffic rises.

The default 128 MB allocation is almost always too low for non-trivial AI work, and Lambda assigns CPU in proportion to memory. An under-resourced function can therefore start slowly and run slowly. Raising memory changes the bill, while provisioned concurrency addresses cold starts by moving the cost model from pure pay-per-use toward always-on reserved capacity.

More memory may help execution run faster without keeping the session going, and provisioned concurrency may cut the time it takes to start without keeping the agent’s working state. Function chaining, orchestration, and checkpoint-resume patterns can work around individual boundaries. With any of these workarounds, a continuous session still has to be split into separate executions.

Why layering workarounds on Lambda is the wrong frame

Function chaining turns the agent’s task into a sequence of handoffs. Each boundary requires state to be serialized and later reconstructed, with the external state machine held in DynamoDB or S3. Each hop adds latency and cost because the execution environment cannot keep the session on its own.

Step Functions makes that sequence easier to describe and inspect, but it does not change what each function does. Each one still invokes, runs, and exits. Checkpoint-resume patterns go further by saving state before a timeout and invoking again, effectively rebuilding a long-running runtime in application code. A timeout in the middle of a step can also leave partial state that needs reconciliation.

The cost argument follows the same path. Lambda, DynamoDB, API Gateway, and data transfer together can cost more at agent invocation volumes than a small number of continuously running Fargate tasks. At that point, the team has accepted both a distributed state-management problem and a higher bill. The simplicity that justified the original choice has disappeared.

Continuity is the test of whether the architecture fits. If most of the code around a process is there to keep it going as it keeps being stopped, the team should take a closer look at the execution primitive. A long-lived, stateful agent needs an execution primitive that lets it hold its environment, resume its work, and pay for active use.

What agents actually need from an execution environment

Persistent, resumable state is the first requirement. The environment must retain working context between turns without forcing the agent to serialize and reload it on every invocation. Tools should stay loaded and ready to use from one step to the next. This makes working memory part of the runtime, rather than treating the whole session as a database record.

The required isolation depends on what the agent executes. An agent that calls APIs or edits code can use a container or sandbox, while one that runs untrusted or LLM-generated code needs a VM-level boundary. Browser and desktop work adds another requirement. Signed-in sessions must persist in an environment that supports the software the agent operates.

Resume speed and idle behavior belong together. A snapshot lets an environment start from a known state rather than repeat initialization, making sub-second or low-second startup practical. Between turns, the environment should suspend and keep its state, then wake when work returns. Billing should cover active use and leave out reserved capacity that sits idle while an agent waits.

Some agents need more than a Linux process. Windows-only desktop applications, Citrix environments, EHR systems, and phone-only apps need an environment that can run the operating system and interface they use. The agent needs a computer it can see, click, and type on. For supervised or regulated workflows, that computer must also have a persistent, addressable desktop that a human can view and take over.

AWS’s own answer — Lambda MicroVMs and what they fix and don’t fix

AWS announced AWS Lambda MicroVMs on June 22, 2026, introducing a different execution primitive for this kind of work. Each MicroVM serves one tenant, session, or job, with VM-level isolation through Firecracker. It runs Amazon Linux 2023 and has its own dedicated HTTPS endpoint. It can suspend on inactivity and resume with memory and disk intact, up to an 8-hour total lifetime.

That is a genuine change in the execution model. The environment can keep all working state so the application no longer has to rebuild it at every turn. But preservation has three separate clocks. maxIdleDurationSeconds governs suspension on inactivity, suspendedDurationSeconds governs how long suspension may last, and maximumDurationInSeconds caps total lifespan, including suspended time.

Activity also has a narrower meaning than busy compute. Lambda measures activity through endpoint traffic, so an agent compiling or processing inside the MicroVM with no request open can look idle and risk suspension. The runtime supports only one processor architecture. These limits can rule out a session even when it ends within the lifespan limit.

The documented default for RunMicrovm is 5 calls per second with a burst of 5, so starting a sandbox on every page load can hit the request-rate limit before the memory quota. Sessions should start on first agent use. Account capacity is also a fixed memory pool per region, with higher allowances in US East (N. Virginia), US West (Oregon), US East (Ohio), and Asia Pacific (Tokyo).

Isolation is valuable, but it is not complete security. Production safety still depends on IAM, egress control, endpoint tokens, tool permissions, logging, tenant separation, and state cleanup. MicroVMs earn their added constraints when a session has state worth retaining and code that cannot be trusted. For stateless orchestration, ordinary Lambda functions remain the cheaper tool.

AgentCore Runtime v2 and the broader shift in how AWS treats agents

Amazon Bedrock AgentCore broadens that change beyond MicroVMs. It first launched in preview in July 2025 and reached general availability on October 13, 2025. AWS documented AgentCore Runtime platform version V2 on September 18, 2026. This is a separate offering from Lambda MicroVMs, and its runtime design provides further evidence that AWS treats agents as a distinct workload class.

Snapshot-based execution addresses the original runtime’s rough cold starts. AWS’s official developer guide states that the runtime prepares an environment once, takes a snapshot, and restores that snapshot for each new instance. Preparation is separated from each subsequent instance start.

The billing model addresses waiting as well as execution. V2 meters active CPU and memory, automatically reclaims idle memory after a short inactivity window, and scales CPU to zero during I/O wait. This moves the bill toward active work rather than a reserved instance waiting between requests.

AgentCore is also a suite whose capabilities include Runtime, Memory, Identity, Gateway, Browser, Code Interpreter, Observability, Evaluations, and Policy, each independently metered. Memory and Web Search are priced separately from the vCPU-hour and GB-hour rates.

The broader signal is a change in platform assumptions. Snapshot restoration, state-aware execution, and active-use billing tackle problems that are hard to handle with a request-and-exit model. AWS is changing the available primitives. That supports the architectural argument without making either offering a universal answer.

Matching the execution primitive to the job — a decision framework

The decision starts with what must survive between steps. Duration, retained state, code trust, required software, and human access define the job more clearly than the label “AI agent.” A tool-call handler and an agent that operates a desktop can be part of the same product but need different runtimes.

Lambda remains a strong fit for the stateless layer. Webhooks, event processors, tool-call handlers, and API endpoints with bounded processing times under 15 minutes fit its model. Account-level and function-level concurrency limits should be reviewed and adjusted upfront, before a traffic spike. For a stateful agent loop running trusted code that needs a consistent environment, Fargate or another container-based environment is the more appropriate comparison.

MicroVMs fit a different combination of needs. A per-user or per-task session with retained state and untrusted or generated code benefits from VM-level isolation, provided the workload fits the multi-hour lifespan and supported environment. Session lifecycle design must account for creation-rate limits, endpoint-based idle detection, and quota accounting for suspended sessions.

Full computers are the fit when software access defines the task. Agents operating legacy Windows applications, Citrix environments, EHR and payer portals without APIs, or phone-only apps need Linux or Windows desktops or Android phones, as appropriate. Persistent machines meet that need when they sleep and wake on demand, bill per second, and charge nothing while they sleep. Persistent signed-in sessions and human takeover also belong in this choice.

Containers therefore remain useful without solving every agent workload. They suit trusted loops, but they are not a substitute for a full desktop, phone environment, or stronger isolation boundary when the task requires one. The governing distinction is whether execution can end after a request or must preserve a working environment. Lambda fits the former, while persistent agent infrastructure is built around the latter.