Serverless Agents: No Single Machine Owns the Loop | Omnara

Start a coding agent on your laptop. Give it an hour-long task. Close the lid five minutes in.

The agent dies.

We spent two decades moving compute into the cloud, then built intelligence that can work around the clock, only to chain it to devices that sleep.

Today this is normal. The agent loop and the developer's device share one lifecycle. It's why the quarter-open laptop meme exists: lids propped open overnight so an "asynchronous" agent doesn't die.

It won't stay normal. Laptops will still matter, but as interfaces to agents, not where their loops run. In fact, no single machine should own the loop.

How Agents Inherited the Laptop

When Claude Code launched in early 2025, local-first was the obvious choice. The model ran in the cloud, but the harness stayed beside the code: holding the conversation, deciding what happened next, invoking tools, waiting for results. The agent and its execution environment became one unit.

Everything that followed copied the shape. Codex, Gemini, Cline, Grok, OpenCode — every coding agent shipped a local-first CLI. Agentic IDEs like Cursor and Zed told the same story. Frameworks made it easy to build your own local-first loops, and when people wanted those agents accessible to others, they did the natural thing: rented a machine in the cloud and ran the same loop there. The architecture didn't change. The laptop just moved.

None of this was a mistake. The agent lived on the machine because that was where the developer already was, and there was no compelling reason yet to separate the two. A natural starting point hardened into the default.

But that default carried an assumption.

Agents Break the Synchronous Assumption

For most of programming history, the only thing that could write code was us. An assumption settled in so deeply that nobody thought to name it: when the programmer stops, the programming stops. Every tool we built respected it. Even cloud development environments — always-on compute, sitting in a datacenter — mostly just gave the programmer another place to type. The session still ended when the human left.

Agents broke that assumption.

An agent can investigate a failure, wait on CI, react to an external event, ask for approval, and keep going long after the interaction that started it has ended. Its useful lifetime is no longer bounded by a terminal session or a person at a keyboard.

That's the step function: useful programming continuing after the programmer leaves. This renders the local loop a constraint rather than a convenience. There is no reason for the agent to inherit the lifecycle of the human’s device.

Separating Continuity From Execution

If the agent shouldn't inherit the device's lifecycle, its continuity has to live somewhere else.

The Log Is the Agent argued that an agent's continuity lives in its durable event history, not in any particular machine or process. Every message, tool call, and decision is appended to a log, and a fresh executor can reconstruct the agent from that log alone.

That property demotes the machine. If reconstruction is always possible, no laptop — no continuously running process anywhere — needs to own the loop.

Which suggests a cleaner boundary.

Where the control plane runs is a deployment choice. It can be managed, self-hosted in a VPC, or operated on private infrastructure. What matters is that it persists independently of whichever device the user happens to be holding.

The execution plane can span everything from your laptop to cloud sandboxes, containers, VMs, and GPUs. The key inversion is that machines are now exposed to the agent as tools. And it's up to the agent to decide where to run what, be it in the control plane itself when no dedicated machine is needed, or in whichever execution environment it finds best fits the work. (More on the execution plane in its own post.)

Separate the lifecycles this way, and the loop itself can go serverless.

What a Serverless Agent Actually Is

A message arrives. An ephemeral worker claims the agent, reconstructs its state from the log, asks the model for the next action, records it, and disappears. When a tool result, timer, or human reply lands later, a different worker picks up where the last one left off.

Simplified example:

# Runs on any worker, whenever an event lands
def advance(agent_id, event):
    with temporary_lease(agent_id):
        append_to_log(agent_id, event)
        state = reconstruct_from_log(agent_id)
        action = model.next(state)
        append_to_log(agent_id, action)
        dispatch(action)          # fire-and-forget
    # worker exits - the agent persists in the log

"Serverless" doesn't mean no computer runs the loop. It means no particular computer owns it. Workers are temporary executors over durable state. An agent can therefore remain alive while zero workers are running. It may simply be waiting on CI, an approval, a scheduled time, or another external event.

Local-first architecture also obscured how little agent work requires a dedicated machine. A chat turn is the clearest example: a message arrives, the model responds, and the agent waits. The same is true when an agent calls an API, browses the web, invokes an integration, or asks a human a question. None of those actions requires a Linux box assigned to the conversation.

A machine enters only when the agent needs something the control plane can't provide: an operating system, a working tree, a private network, specialized hardware, or local data. Binding every agent to a machine mistakes an occasional execution requirement for a permanent dependency.

The New Role of the Device

The most compelling part of this shift is that the user experience can remain exactly as it is today. Nobody has to abandon the terminal, replace their IDE, or move every repository into a cloud sandbox. The interface that made local agents useful stays.

You open a terminal inside a repository, type a request, watch commands run against local files, and approve changes in the same place. The agent uses the same working tree, tools, and credentials because the laptop remains part of the execution plane.

What changes is the role of the device. It is no longer the container for the agent; it is a client connected to a durable harness running elsewhere. When that harness needs to read a file or run a local command, it routes the action to the laptop and records the result back into the agent's history. From your perspective, the command ran locally. From the system's perspective, the local machine was just one execution environment utilized by the agent.

The difference appears when the device disappears. Close the laptop and work that depends on its local files may pause, but the agent remains in the control plane. If the required state is available elsewhere, it can continue there or reproduce the environment on a new machine. And when the laptop returns, the same agent can resume using it again. The machine, it turns out, was never special: the agent can provision machines as the task demands, spread work across several at once, release them when it's done, and carry on as machines come and go.

And because the agent is no longer contained by one interface, it can be reached through many. Start a task from a laptop, approve a question from a phone, follow its progress in Slack, and review the result from another machine. Several people can also steer the same durable session without sharing access to one developer’s terminal.

In this setup, the laptop’s role resolves cleanly: an interface for the user and an execution environment for the agent. No longer the place the agent lives.

Properties That Fall Out

Once continuity no longer depends on a particular device or process, several properties follow.

Availability. Agents spend most of their lives waiting — on tests, approvals, timers, APIs, people. In a local architecture, every wait is an uptime requirement for some machine. In a persistent control plane, waiting is just durable state. When new work arrives, a worker reconstructs the agent and continues. The agent doesn't need to run continuously to be continuously available.

Resilience. Because no worker owns the agent, workers are allowed to fail. Another reconstructs the same state from the log and picks up. A laptop can disconnect without erasing the agent's objective, history, or pending work. This doesn't magically migrate an uncommitted working tree or a running OS process, but one executor's failure no longer becomes the agent's failure. The process died; the agent didn't.

Scalability. The platform no longer needs one continuously running process per agent. A shared worker pool advances whichever agents currently have work, and the two kinds of capacity scale on separate curves:

worker capacity   scales with concurrent agent advancement
machine capacity  scales with active operating-system work

Efficiency. A persistent agent no longer implies a permanently allocated sandbox. Imagine 1,000 durable agents where only 5 percent need a shell at any given moment: the control plane holds 1,000 histories, but the execution plane only needs capacity for ~50 active workloads plus headroom. That’s the outcome of separating persistent identity from active execution. An idle agent consumes durable storage rather than idle machines. And specialized hardware can attach for one stage of a task instead of for the agent’s entire lifetime.

Now some environments should remain warm. A large repository, a loaded model, an expensive-to-rebuild cache, or simply an actively used workspace can all justify keeping a machine alive. The difference is that persistence becomes an explicit choice rather than a side effect of the agent existing.

And these are only a few examples. Treat agents as durable systems rather than device-bound processes, and they gain the properties we expect from serverless infrastructure.

Who Owns the Loop

The industry is already moving in this direction. Anthropic’s Managed Agents separates the harness advancing the agent from the sandbox where code executes. Inference can begin before a container is provisioned. Ramp, Stripe, Sentry, Coinbase, and others have built internal background agents around related separations.

But notice what none of them offer: ownership. The internal agents are internal. The managed offerings run one provider's models on that provider's infrastructure: not model-agnostic, not open-source, not self-hostable.

We think that has to change, because an agent is the most intimate software you'll ever run. To be useful, it needs your personal data, your company's data, your workflows, your decisions. The Log Is the Agent made the argument for the record itself: if a provider holds the only durable copy of your agent's history, the provider owns your agent. The same argument now climbs a level. The control plane is where the log lives and the harness runs, so you should be able to own that too.

How We Handle This in Practice at Omnara

At Omnara, the control plane owns each agent’s durable log and lifecycle. Temporary workers advance the loop when messages, tool results, or other events arrive.

Machines join the execution plane through a small daemon that connects outbound to the control plane. The control plane records a command, the daemon claims and executes it, and the result is written back to the agent’s log. The worker that requested the action and the machine that performs it do not need to be alive at the same time.

This makes machines tools. An agent can discover, acquire, target, and release them as needed. If a machine goes offline or fails to complete an action, the outcome is written back as a structured result, and the agent can decide what to do next. A machine provides compute, files, network access, and hardware. It never provides the agent’s identity.

Conclusion

The point of this piece was twofold: to pull apart the agent from its execution environment, and make the resulting architecture serverless. Agents broke the status quo. An agent that can outlive your presence shouldn't inherit the lifecycle of your device.

Put the loop in a persistent control plane. Make it serverless. Expose machines as tools. The rest falls into place: availability, resilience, scaling, efficiency.

That's the system we're building at Omnara. We’re preparing to open-source our control plane for agents soon. You can join the waitlist here.

Update: Omnara has launched. You can use Omnara Cloud or self-host.