TL;DR:

  • Serverless is a good fit for event-triggered, short-duration agent tasks but breaks down for long-running, stateful workflows without additional infrastructure
  • Cloudflare Workers + Durable Objects, Vercel Functions + KV, and AWS Lambda + Step Functions each offer different tradeoffs for agent statefulness and execution time
  • The key pattern shift: agents on serverless need external state stores, streaming responses via SSE or webhooks, and explicit timeout handling

Serverless platforms have matured into a legitimate hosting option for AI agents — not just for simple API wrappers, but for genuine agentic workflows that call tools, maintain context, and react to events. The economics are compelling: no idle server costs, automatic scaling, and zero infrastructure management. The tradeoffs are real too, and they require deliberate design choices.

Why Serverless Suits Agent Workloads (Mostly)

AI agents are fundamentally event-driven. A user sends a message, a webhook fires, a cron job triggers — and the agent wakes up, does work, and produces an output. That pattern maps naturally to serverless execution models, where functions spin up in response to events and charge only for compute time consumed.

The typical agent invocation — an LLM call plus a few tool calls — usually completes in seconds, well within the limits of most serverless platforms. Lightweight retrieval agents, webhook processors, and notification responders all run comfortably on serverless without modification.

The friction appears when agents need to run for minutes or hours, maintain complex state across turns, or stream partial results back to a waiting client. These are solvable problems, but each one requires explicit architectural choices.

Platform Comparison: Three Options for Agent Deployment

AWS Lambda is the most flexible option for agents already in AWS environments. The 15-minute maximum execution time covers most agent use cases, and the integration with Step Functions allows you to break long workflows into coordinated Lambda invocations with managed state. For agent memory and context, Lambda agents typically rely on DynamoDB (for session state), S3 (for longer-term storage), or external vector databases. The cold start penalty — typically 200–800ms for Python/Node.js functions — is negligible for most agentic workloads where LLM calls dominate latency.

Lambda’s streaming response support (via Lambda Function URLs or API Gateway) allows agents to stream tokens back to clients rather than waiting for full completion, which is essential for chat-style agent interfaces.

Cloudflare Workers has a different profile. The 128MB memory limit and CPU time constraints (50ms by default, up to 30 seconds with Workers Unbound) make it better suited to lightweight routing, tool-call dispatch, and response streaming than heavy compute. The real value for agents is the Durable Objects primitive: long-lived, single-instance JavaScript objects that can maintain state across requests with consistent identity. A Durable Object can represent an agent session — holding conversation history, tool call state, and intermediate results — while the Workers layer handles incoming requests and streaming output.

The combination of Workers + Durable Objects + Workers KV gives you a surprisingly capable stateful agent runtime that runs at Cloudflare’s global edge, with low latency for geographically distributed users.

Vercel Functions sits between the two in terms of flexibility. The pro-tier 300-second execution limit covers most agent workflows, and Vercel’s streaming support (via ReadableStream and the AI SDK) is well-integrated for chat-style agent UIs. The Vercel AI SDK’s streamText and generateObject abstractions handle the streaming boilerplate. For state, Vercel Functions typically rely on Vercel KV (Redis-backed), external databases, or Upstash. The tight integration with Next.js makes Vercel the natural choice for teams building agent-powered web applications rather than standalone agent services.

The Statelessness Problem

Every serverless platform shares the same fundamental constraint: functions are stateless. When an agent function returns, any in-memory state disappears. This is the core design challenge for multi-turn agent workflows.

The standard solutions:

External session stores. Redis (Upstash, ElastiCache) is the most common choice — fast, simple, and low-latency. Serialize agent state (conversation history, tool results, intermediate reasoning) into a session key, load it at function start, write it back on exit. Vercel KV and Cloudflare KV work similarly with their respective platforms.

Database-backed state. For agents that need durable, queryable history, PostgreSQL or DynamoDB provide more robust storage. The tradeoff is higher read/write latency compared to Redis.

Workflow orchestration. For complex, long-running agent workflows with branching logic and parallel tool calls, Step Functions (AWS), Inngest, or Temporal handle state durably in the orchestration layer itself, with individual agent steps executing as short-lived serverless functions.

Streaming Responses on Serverless

Users expect AI agent responses to stream — seeing tokens arrive progressively is significantly better UX than waiting for a complete response. All three major platforms support streaming, but the implementation differs.

On Lambda, use Lambda streaming response mode with awslambda.streamifyResponse. On Cloudflare Workers, return a ReadableStream from your fetch handler. On Vercel, use the Vercel AI SDK’s streaming primitives or return a Response with a ReadableStream body.

For webhook-triggered agents where there’s no open HTTP connection to stream into, the pattern shifts to push notifications: the agent runs asynchronously and sends results to a webhook, WebSocket, or pushes to a queue that the client polls.

Handling Execution Limits

Lambda’s 15-minute ceiling covers the vast majority of agent tasks. For anything longer, the pattern is to checkpoint progress to an external store and re-invoke — either via Step Functions state machine transitions or by triggering a new Lambda invocation from within the current one before timeout.

On Cloudflare Workers, the execution limits are more constrained. The pattern for longer tasks is to offload heavy LLM calls to an external service (proxied through Workers) and use Durable Objects to coordinate results, keeping individual Worker invocations short.

When Not to Use Serverless for Agents

Serverless is not the right choice for agents that need persistent in-memory caches (embedding indexes, loaded model weights), dedicated GPU access, or consistently sub-100ms response times without cold-start management. For these workloads, always-on containers (ECS, Cloud Run, Fly.io) or dedicated GPU instances remain the better fit. Most agent deployments exist somewhere in the middle — a serverless layer for request handling and routing, with specialist compute for inference-heavy operations.

The practical starting point for most teams: deploy agent logic to Lambda or Vercel Functions, use a Redis-backed session store for multi-turn state, and add workflow orchestration only when agent tasks genuinely exceed 15 minutes or require complex branching that’s hard to manage in a single function.