For six weeks, a fintech’s refund-dispute agent ran on serverless functions without a problem. A dispute came in, a webhook fired, the agent classified it in two seconds, and the function shut down.
Then the product team asked for more: investigate each dispute, pull six months of transactions, draft a resolution, and wait for a manager to approve refunds over $500. The first large case ran past AWS Lambda’s 15-minute limit mid-investigation and failed with nothing saved.
Every team building agents reaches this point. The short answer:
Choose serverless for short, event-driven, bursty agent tasks. Choose long-running or durable runtimes for multi-step loops, long tool calls, streaming, and workflows that pause for human approval. Most production teams end up running both.
Key takeaways
- Serverless runtimes are cheap and simple, but cap execution time and forget everything between invocations.
- Long-running runtimes hold state for hours, but you pay while agents wait, and a broken agent can keep running.
- Durable execution checkpoints each step and suspends waits at little or no compute cost, giving long-running behavior on serverless economics.
- Choose per agent, not per platform. Most teams mix all three.
- Once agents run across several runtimes, the harder problem is governance: seeing every agent and stopping misbehavior wherever it runs.
Why AI agents break the classic serverless model
Serverless was built for web requests that finish in milliseconds. An agent is a loop: reason, call a tool, read the result, and reason again, often dozens of times.
Agents also spend most of their time waiting on models, APIs and people. Cloudflare’s long-running agents guide puts it plainly: an agent that’s idle 99% of the time still costs a full server on a VM or container.
Three properties decide the right runtime: how long a task runs, how much state it carries, and what it waits on. The refund agent’s classification step had none of these problems. Its investigation step had all three.
What is a serverless agent runtime?
A serverless runtime runs agent code on demand in short-lived, stateless containers, isolates or micro-VMs. An event triggers it, it runs, and it shuts down. You pay only for execution.
Options include AWS Lambda, Vercel Functions, Cloudflare Workers and the Azure Functions serverless agents runtime, launched in public preview at Build 2026, which defines agents in Markdown files with their tools, MCP servers and triggers.
| Platform | Execution limit (October 2026) |
| AWS Lambda (standard functions) | 15 minutes |
| Vercel Functions | 300s default; up to 800s on Pro and Enterprise; 1,800s with extended duration (beta) |
| Azure Functions serverless agents runtime | 900-second default timeout (preview) |
Where it fits: classification, routing, webhook handlers, scheduled checks and MCP tool endpoints. With zero idle cost, bursty agents cost almost nothing, and scaling is automatic.
Where it strains: state resets on every invocation, so context must be saved to an external store and reloaded at every step. A function that must finish in minutes can’t wait days for an approver.
That’s where the refund agent struggled. To fit the time limit, the team split the investigation into chained functions that saved state after each step. A simple function was becoming a fragile distributed system.
What is a long-running agent runtime?
A long-running runtime keeps a process, container or micro-VM alive for the whole session, so the loop, memory and connections stay in place.
Options include containers on Kubernetes or ECS, and agent-specific runtimes like Amazon Bedrock AgentCore Runtime. By default, an AgentCore session ends after 15 minutes of inactivity or 8 hours in total, and both limits are adjustable.
What you gain: state that persists through the task, room for deep research, browser automation and sandboxed code execution, native streaming, and simple pauses.
What you pay for: reserved compute while the agent waits, more to operate, and a longer blast radius. In a public GitHub issue, a developer described an AgentCore agent stuck retrying a code-interpreter session. With no stop API available at the time, it risked looping for up to 8 hours, and the team killed it by revoking IAM permissions. AgentCore now lists a StopRuntimeSession API, but a stop button only helps once someone notices the loop.
The refund agent followed the same path. Investigations finished, but sessions sat idle for hours waiting on managers. One night, a flaky transactions API sent the investigator into a retry loop that nobody saw until morning.
Serverless vs long-running agent runtimes: side-by-side comparison
| Dimension | Serverless | Long-running |
| Max duration | Capped (roughly 5–30 minutes) | Hours to indefinite |
| State | Ephemeral; stored externally | Kept in process or checkpointed |
| Waiting on humans | Awkward: queues, polling or timeouts | Native pause and resume |
| Cold starts | Possible | None once warm |
| Streaming | Limited | Native |
| Cost model | Pay per execution; zero idle cost | Pay for allocation, including idle time |
| Typical failure | Timeouts and lost state | Runaway loops and idle spend |
| Best for | Triggers, routing, tool endpoints | Research, coding and approval workflows |
The key row is typical failure. Serverless fails by stopping too early. Long-running fails by not stopping. That difference matters again at the end of this guide.
The middle path: durable execution for AI agents
Durable execution checkpoints each step, suspends while the agent waits, and resumes from the last checkpoint after a pause or failure.
- AWS Lambda durable functions, announced in December 2025, can suspend an execution for up to a year. On-demand functions incur no compute charges while suspended. AWS has published a healthcare prior-authorization example with four agents and a physician review gate in one durable function.
- Cloudflare Durable Objects give each agent its own SQLite-backed state. Agents hibernate at zero compute and wake on a request, WebSocket message, alarm or email.
- Workflow engines such as Temporal apply the same checkpoint-and-resume model across languages and clouds.
The trade-off: code between checkpoints must behave deterministically, in-memory variables don’t survive hibernation, and your team learns a new programming model.
For the refund agent, the approval step moved into a durable workflow. It now waits days for a manager at almost no cost, then resumes where it stopped.
How to choose the right agent runtime
Ask five questions about each agent:
- How long does one task take? Minutes or less suggests serverless. Hours of active work suggests long-running.
- Does it wait on people or slow systems? For long waits, use durable execution instead of an idle container.
- How much state does it carry? Large context, open connections or sandbox files point to long-running.
- What’s the traffic pattern? Bursty favors serverless. Steady, high concurrency often favors long-running.
- What does it touch? Untrusted code, browsers and sensitive systems need strong session isolation.
| If your agent… | Choose |
| Responds to a trigger and finishes in seconds | Serverless |
| Runs a 10–60+ minute reasoning loop | Long-running |
| Waits hours or days for approvals | Durable execution |
| Streams to users or executes code | Long-running with isolation |
Most mature teams land on a hybrid: serverless at the edges, long-running or durable runtimes for the reasoning core. The refund agent ended up there too, with a serverless classifier, a long-running investigator and a durable approval workflow. One agent, three runtimes.
The decision after the runtime decision
Now multiply the refund agent by fifty. Payments runs agents on Lambda, growth deploys on Vercel, platform engineering runs coding agents in Kubernetes, and SaaS tools ship their own agents. Each runtime has its own console, logs and limits, and none of them governs what agents actually do.
- On serverless, timeouts hide unfinished work, and retries quietly multiply LLM spend.
- On long-running runtimes, a session limit caps compute, not behavior.
- On durable workflows, executions can sit for days with credentials attached.
No single runtime can say which agents exist, which version is approved, what each may spend, or what stops one that misbehaves. Choosing a runtime is a per-agent decision. Governing every agent is an organization-wide one. And a dashboard can show you a loop, but stopping it takes control in the path of the agent’s calls.
Your agents now run everywhere. Who governs them? Read this whitepaper on why the enterprise agent estate is the next infrastructure decision, and what a governance layer above every model and runtime needs to do:
Governing serverless and long-running agents with Opencontroller
Opencontroller is Lyzr’s open control plane for AI agents. It doesn’t replace your runtimes. Agents keep running where they are, and Opencontroller adds a control layer around them.
| The problem | How Opencontroller helps |
| Agents spread across functions, containers and vendor clouds | Find: discovers agents, models, tools, data and workflows, including agents outside your primary cluster |
| A long-running agent loops for hours | In-path enforcement: agent and LLM gateways check identity, authorization, budgets and guardrails, and can refuse, mask or redirect a call before it completes |
| Unapproved versions reach production | Ship: evaluations, approvals and release controls at the handoff to production |
| A separate console for every runtime | Run: real-time monitoring of agents, apps, APIs and infrastructure |
| Cost and performance signals go unused | Improve: turns usage, performance, cost and security signals into insights |
Its architecture suits a mixed estate:
- Runtime-agnostic: it deploys into Bedrock, Vertex and Foundry runtimes and enforces policy on agents in other vendors’ clouds.
- No rewrites: it governs existing containerized agents, hand-written or built in Lyzr Studio.
- Open standards: OpenAI-compatible APIs, MCP, A2A and OpenTelemetry, with no proprietary SDK.
- Your boundary: it runs in your cloud, private infrastructure or air-gapped sites, and provider secrets aren’t handed to individual agents.
- Fast setup: Lyzr says setup takes less than a week.
Back to the refund agent. Its classifier, investigator and approval workflow now sit in one inventory with an owner, an approved version and a budget. When the transactions API flakes and the investigator starts retrying, its model calls hit the budget at the gateway and are refused. Nobody revokes IAM permissions at 2 a.m.
Choose the right runtime for each agent, then govern them all from one place. Explore Opencontroller, try the live demo or book a demo.
Conclusion
The serverless vs long-running agent runtimes decision depends on how each agent behaves: serverless for short, bursty tasks, long-running for long stateful loops, and durable execution for long waits. Most estates need all three. Serverless stops agents too early, and long-running runtimes may not stop them at all. The right runtime fixes the first problem. Seeing and controlling every agent fixes the second.
FAQ
Serverless runs agents in short, stateless invocations with time limits and no idle cost. Long-running runtimes keep a process or micro-VM alive for the session, holding state and connections for hours.
Yes, for tasks under 15 minutes. For longer or approval-gated workflows, Lambda durable functions add checkpointing and can suspend an execution for up to a year.
By default, sessions end after 15 minutes of inactivity or 8 hours in total. Both values are adjustable through lifecycle settings.
Use durable execution, such as a callback that suspends the agent until the approval arrives, or save state externally and start a new invocation when a human responds.
Set iteration limits in code, but also enforce budgets and policies at a gateway in the path of the agent’s model and tool calls, so misbehavior stops whatever runtime the agent uses.
Book A Demo: Click Here
Join our Slack: Click Here
Link to our GitHub: Click Here
