--- url: /blog/2026/05/25/serverless-agents.md description: >- The world needs managed agents. The architecture for them is serverless. Agents in functions, not sandboxes. --- # Serverless agents — managed agents in functions, not sandboxes In the last few weeks, every major AI platform has shipped [managed agents](#managed-agents). They're responding to the same demand, for infrastructure to bring agents online, with the same kind of [sandbox-based architecture](#the-rise-of-the-sandbox). That architecture is wrong. Managed agents don't belong in sandboxes. They belong in functions, with stateless agent logic, durability in the data layer and tool execution in backend systems. That's the architecture — [serverless agents](#principles-of-serverless-agents) — to wire agents into the workforce. > \[!Warning] λ Serverless agents with Electric > Build and run serverless agents with [Electric Agents](/agents/). See the [blog post](/blog/2026/04/29/introducing-electric-agents) and [quickstart](/docs/agents/quickstart) guide. ## Managed agents In the last few weeks, what seems like every major AI platform has shipped their version of managed agents: * [Anthropic Managed Agents](https://claude.com/blog/claude-managed-agents) (April 8th) * [Cloudflare Project Think](https://blog.cloudflare.com/project-think) (April 15th) * [OpenAI Workspace Agents](https://openai.com/index/introducing-workspace-agents-in-chatgpt/) (April 15th) * [Azure Foundry Hosted Agents](https://devblogs.microsoft.com/foundry/introducing-the-new-hosted-agents-in-foundry-agent-service-secure-scalable-compute-built-for-agents/) (April 22nd) * [Amazon Managed Agents](https://aws.amazon.com/bedrock/managed-agents-openai/) (April 28th) * [LangChain Managed Deep Agents](https://www.langchain.com/blog/introducing-managed-deep-agents) (May 13th) * [Google Agent Executor](https://github.com/google/ax) (May 20th) These companies have the best visibility in the sector. They're seeing that the world needs managed agents. As Sunil and Kate from the Cloudflare Agents team [put it](https://blog.cloudflare.com/project-think): > "The first wave was chatbots. The second was coding agents. We are now entering the third wave: durable, distributed agents." This third wave is the wave of workforce transformation. Agents joining the workforce, one automation and one assistive task at a time. ### Bringing agents online For this to happen, agents need to be brought online, scaled out and integrated into the day-to-day systems and processes that companies run on. They need to be part of the team. Which means being wired into the tools that teams use to collaborate and get stuff done. They need to be tracked and managed, which means wiring them into governance processes and systems of record. So how do you do that? Well, let's go from first principles. ### The rise of the sandbox What is an agent? It's an LLM in a loop. What everyone from [Chris McCord onwards](https://youtu.be/ojL_VHc4gLk?t=3397) figured out is that the LLM is really good at using tools like `bash` and `grep`. So the harnesses running the agent loop were designed around these tool calls. Which means they need to run in an environment that supports them, aka a computer. Then, initially, when the LLM wanted to run a command, we reviewed it and manually approved (or rejected) the execution. However, as the agents got better, approving every command became boring and we designed ourselves out of the loop. Hence the rise of the sandbox: an isolated computer in the cloud where a harness can [loop away like crazy](https://twitter.com/thruflo/status/2012644770703704333), getting stuff done without bothering you. #### Sandboxes for managed agents This led to an explosion in sandbox infrastructure. With some awesome companies like Daytona becoming the [fastest growing infra in history](https://www.daytona.io/dotfiles/fastest-growing-infra-company-in-history). So, it's no surprise that the new infrastructure for managed agents has been based around sandboxes. For example, here's Satya Nadella, the Microsoft CEO, on the [Azure Foundry launch](https://x.com/satyanadella/status/2047033636923568440): > Every agent will need its own computer. And with new Hosted agents in Foundry, every agent gets its own dedicated enterprise-grade sandbox Which sounds very plausible. Until you consider the consequences of sandbox isolation for managed agents. ## Limitations of sandboxes There are three main downsides of sandbox isolation and all of them have serious consequences for managed agents: 1. [resource efficiency](#_1-resource-efficiency) — which becomes more important the more agents you run 2. [fragmentation](#_2-fragmentation) — which is directly opposed to wiring into the business 3. [coordination](#_3-coordination) — which is critical for online agents ### 1. Resource efficiency Running an agent inside its own VM or Docker container, or even a Firecracker, uses more compute resource than is needed to run the agent logic. ... memory overhead table ... Most agent operations, be they tool calls or LLM instruction, are I/O based. You send a request to the Anthropic API and wait for the response to be streamed back. There's really no need to hold a whole computer in memory just to make an API request. This tends not to matter when you're running at smaller scale. The value of the agent system and the cost of LLM inference outweigh the cost of standard compute. However, it does matter when you have lots of agents. If your business is running on agents and those agents are spawning sub-agents every time there's a customer interaction, efficiency does matter and sandboxes are a blunt instrument with a lot of wasted compute. ### 2. Fragmentation More fundamentally, sandboxes lead to fragmentation of artefacts and decision traces. A harness looping away inside a computer creates artefacts using operating system primitives like files and processes. If the whole point and power of the agent is that it can do what it likes inside that computer then it's going to create a whole load of arbitrary activity and artefacts. For example, if I run Claude Code on my local computer and ask it to spawn sub-agents to do some parallel research, it's going to: * spawn those sub-agents in operating system processes * store their session logs in `.jsonl` files inside a hidden folder in my user directory * create and edit files in arbitrary locations * make all sorts of arbitrary HTTP requests That's exactly what you *don't* want from agents you're running your business on. Because what happens when you want to manage, monitor, collaborate on or review the agent activity? What are you going to do, `ssh` into the sandbox? No, what you want is to be able to track and trace all the activity and artefacts and wire them into the [context graph](https://foundationcapital.com/ideas/context-graphs-ais-trillion-dollar-opportunity). ### 3. Coordination In traditional software you were deploying deterministic systems with known topologies. Agents are not like that. Agents can spawn other agents, in increasingly dynamic and sophisticated topologies. Agents are also much more likely to be working in parallel than traditional users. Coordination between managed agents has all the challenges of traditional distributed systems (durability, addressability, reactivity, spawning, signaling, scheduling, communication, coordination, concurrency, contention) but amplified by the scale and dynamic nature of agents. Sandboxes compound the problem by forcing you to pre-define the APIs and communication topologies between managed agents. When what agents want and need is to be able to dynamically create their own topologies. ## Breaking out of the sandbox The more sophisticated platforms are seeing these limitations and evolving their architecture. Breaking out of the harness-in-a-sandbox model to separate agent logic from tool call execution and rethink the fundamentals of isolation, integration and communication. ### Pulling apart the harness In their [Scaling Managed Agents](https://www.anthropic.com/engineering/managed-agents) post, Anthropic explains their approach: > The solution we arrived at was to decouple what we thought of as the “brain” (Claude and its harness) from both the “hands” (sandboxes and tools that perform actions) and the “session” (the log of session events). Google's [Agent Executor (AX)](https://github.com/google/ax) platform explicitly separates the agent logic from the tool execution environment: ... readme mermaid diagram ... ### Rethinking isolation This separation of concerns and spectrum of execution environments allows us to rethink isolation. When an agent is a harness, designed to run on a local computer, everything needs to run in a full sandbox. However, when you've pulled apart the harness, you can see that agent logic and tool execution require different levels of isolation. For example, Cloudflare have a spectrum of compute environments, the [execution ladder](https://blog.cloudflare.com/project-think/#the-execution-ladder), ranging from dynamic workers to full sandboxes. Agent logic can run in a lightweight V8 isolate, like a function, whilst heavier tool calls can be executed either in sandboxes, or in external backend systems. This changes the game for managed agents, allowing: * the **agent logic** to run in serverless functions * the **tool calls** to be executed in backend systems This transforms the resource efficiency of managed agents, allowing them to scale to zero like edge functions. And it solves fragmentation because the tool calls are executed in managed systems that you control and can monitor. ### Turning the agent inside out One of the most influential talks in data systems is Martin Kleppmann's from Strange Loop in 2014 about [Turning the database inside-out](https://martin.kleppmann.com/2015/03/04/turning-the-database-inside-out.html): His concept was that databases are built on logs. What if you turn them inside-out and put the log on the outside? Well, agents are logs. What happens if you turn the agent inside-out and put the session log on the outside? The answer is that it solves the dynamic coordination challenge. Allowing agents (and users and systems) to connect and monitor other agents directly by directly subscribing to and interacting with the log, rather than going through a pre-defined interface. You don't need to pre-define the APIs for agent communication. Instead, agents can just connect, monitor, subscribe, fork and interact with each other. ## Principles of serverless agents Pulling apart the harness, rethinking isolation and turning the agent inside-out leads to a new architecture for managed agents: 1. Treat agents as logical entities 2. Model agents as data, not compute 3. Separate agent logic from tool execution 4. Run the agent loop as a stateless function 5. Execute tool calls through backend systems ### 1. Agents are logical entities ### 2. Model agents as data, not compute ### 3. Separate agent logic from tool execution * The agent loop's decisions and the actual tool execution are two different things * They don't need to live in the same process, runtime, or trust boundary * Decouple them. The agent loop decides; tool execution runs as online services, inside your business systems, against your data platform. * This is the architectural answer to *"but agents need isolation"*: * The agent loop has nothing to isolate — it decides and dispatches, no arbitrary code execution * Isolation lives at the tool execution layer, where the side effects actually happen * Tool calls run with whatever isolation each tool requires — sandboxed MCP servers, managed services, your own APIs * It is also the architectural answer to *"but agents need to integrate"*: * Decisions, traces, artefacts and side effects all land in the systems where the rest of your business runs * Decision traces are captured natively because tool calls execute on systems you control * Fragmentation goes away. Integration is native. * Two pictures of the same agent, side by side: * **Fragmentation** — harness in a sandbox sprawls tool calls into bash, grep, curl, then artefacts disappear into hidden `~/.claude/` files. Tool calls and session state share the same opaque box. * **Integration** — function with decoupled tools cleanly flows through MCP, DB and API layers into systems of record (SAP, Salesforce, Snowflake). Tool calls execute where the business already operates. * Foundation Capital's *Context Graphs* thesis lands precisely here: governance can't be bolted on; the agent has to be in the execution path at commit time * This is the gift that makes online managed agents a real category, not a marketing badge for a hosted sandbox ### 4. Run the agent loop as a stateless function * With state lifted into the data layer and tool execution decoupled, the agent loop is small enough to run as a stateless function * Serverless economics for agents: scale to millions when work flows in. Scale to zero when it doesn't. * The agent is long-lived as a logical entity (the state persists). The compute is fully elastic. * No 24/7 process babysitter. No Docker fleet. No Lambda layer with a FUSE-mounted filesystem faking a desktop. * The pricing signal is already in the market * Anthropic Managed Agents at $0.08 per session-hour * Azure Foundry scale-to-zero pricing on hypervisor sandboxes * The economics of managed agents only work if the compute is elastic * The dominant sandbox-based offerings are bolting elastic pricing onto a non-elastic primitive. Same boxes, fancier billing. * ### 5. Execute tool calls through backend systems * Don't model the agent as a process. Model it as data. * The session log — messages, tool calls, results, observations, artefacts — lives in a durable, addressable stream in the data layer * Durable *state*, not durable *execution*. The process can come and go. The state survives. * The agent becomes a long-lived logical entity. It lives, even when nothing is running. * Anthropic put it cleanly: *"The harness becomes cattle. The session log is the durable record of events."* * This resolves the dark-session problem at its root * Every session is addressable by URL — nothing hidden, nothing dark * Every session is evaluable, shareable, forkable, replayable * The log *is* the observability surface — monitoring and evaluation are native, not bolted on * It also resolves the multi-agent coordination problem * Anyone — users, agents, other systems, other teams — can subscribe to a session at any time * Dynamic, distributed topologies emerge naturally because the substrate is the data, not a pre-defined interface ## Benefits for the business * scale * integration * collaboration * transformation ### Scale Workforce-scale agent deployment becomes economically and operationally feasible as a default, not as an aspiration ### Integration Decisions, traces, artefacts and side effects all land in the systems where the rest of your business runs ### Collaboration Every session is addressable by URL — nothing hidden, nothing dark * Every session is evaluable, shareable, forkable, replayable * The log *is* the observability surface — monitoring and evaluation are native, not bolted on * It also resolves the multi-agent coordination problem * Anyone — users, agents, other systems, other teams — can subscribe to a session at any time * Dynamic, distributed topologies emerge naturally because the substrate is the data, not a pre-defined interface ### Transformation workforce transformation ... overall benefit, incremental automation of knowledge work, efficiency, survival and competitiveness in the market ... ## Building with Electric * This is what we've built. [Electric Agents](/agents/) is the agent platform for the architecture described above. * Agents are defined as entity handlers. Each entity gets its own durable stream — its memory, its inbox, a complete audit trail of everything it did. * The handler is a stateless function. A lightweight V8-class runtime spins it up in milliseconds, scales to millions of concurrent agents, costs nothing when idle. * The architecture has three layers: * **Data layer** — durable streams hold session state, addressable by URL, replayable, forkable * **Function runtime** — stateless agent handlers, your code, your stack, your deployment * **Tool execution** — online services, MCP servers, managed backends, your APIs — wherever isolation and integration make sense * Agents are your code in your app, running on your compute. Managed agents, without the platform lock-in. * For the full platform pitch, see the [launch post](/blog/2026/04/29/introducing-electric-agents). For the data primitive, see the [agent loop primitive](/blog/2026/04/08/data-primitive-agent-loop) piece. This post is about the architectural pattern; those are about the platform that ships it. * Take it from concept to production via the [Quickstart](/docs/agents/quickstart) or the [Docs](/docs/agents/). ... re-use the video here ... *** ### Next steps Managed agents don't belong in sandboxes. They belong in functions, with stateless agent logic, durability in the data layer and tool execution in backend systems. You can build serverless agents today, on [Electric Agents](/agents/). Re-using your existing prompts, tool calls, AI engineering. As part of your existing web infrastructure. See the [introductory blog post](/blog/2026/04/29/introducing-electric-agents) and dive into the [Quickstart](/docs/agents/quickstart) guide now. If there's anything you'd like to discuss, you're welcome to [join the Electric Discord](https://discord.electric-sql.com), say hello and ask any questions there. Watch on YouTube: [Serverless agents -- agents in functions, not sandboxes](https://www.youtube.com/watch?v=...) Watch on YouTube: [Turning the database inside-out](https://www.youtube.com/watch?v=fU9hR3kiOK0)