Lately a lot of people have been talking about “long-running agents”. The obvious idea is that if an agent needs to be long-running, then we should just host it as a long-lived process and keep it alive. At first glance that sounds perfectly reasonable: the context stays in memory, the working directory stays in place, and when the user comes back the process can simply continue. The problem is that this approach quietly turns waiting time into paid compute time, and that is where things start going wrong.
A lot of agent sessions may last eight hours, a full day, or even longer, but only a small fraction of that time is actual computation. The user steps away, an approval is pending, an outside event has not arrived yet, or a scheduled task will not fire until much later. In other words, the session is long in wall-clock time, not in active CPU time. If you do not separate those two ideas early, the architecture tends to optimize for the wrong thing.
0x00 > The problem
If agents are modeled as permanent hosted processes, the first thing you lose is not architectural elegance but cost efficiency. As long as the process stays alive, compute has to stay reserved for it, whether or not it is doing anything useful right now. During quiet periods, machines sit there holding idle agents; during peak periods, capacity becomes tight because too much of it is already occupied by agents that are technically online but mostly just waiting.
That is the opposite of what the cloud is good at. The real value of cloud infrastructure is not that it can host more always-on processes, but that it can give you resources when work actually appears and scale to zero when nothing is happening. If an agent has to remain hot all the time, you are giving up one of the most valuable properties the cloud offers: elasticity. A system that wastes resources in quiet periods and still struggles to expand under load will have a hard time delivering both great experience and great cost efficiency.
0x01 > What users actually want
But the more important point is that users do not really care whether one specific process stayed alive. What they care about is whether they can come back and continue the work from where they left it. Is the repository still there? Is the browser still on the same page? Are the downloaded files, half-finished notes, and in-progress environment still where they were before?
What users want, in other words, is not an always-on process but a workspace that does not disappear. Those two goals sound similar, but they lead to very different systems. One is about keeping an execution unit alive forever; the other is about preserving the part of the environment that actually matters to the user. Once the goal shifts from “keep the process alive” to “keep the workspace intact”, the design becomes much clearer.
0x02 > Runtime, agent, and sandbox
That is why Brazosd treats the runtime, the agent, and the sandbox as separate layers. The agent is the long-lived identity: it carries configuration, instructions, tools, skills, permissions, credentials, and its relationship to users, teams, and sessions. The session is the durable record: it stores what the user said, what the agent did, and where the overall process stands. The runtime is the execution layer: when work arrives, it picks it up, executes it, and writes the results back. When there is no work, it does not need to keep occupying compute.
The sandbox is the workspace, and it is not just an abstract layer but an isolated environment running inside a virtual machine. It holds the filesystem, working directory, browser state, downloaded artifacts, and the local context that builds up while a task is in progress. This is not only about preserving the workspace; it is also about safety. When an agent browses the web, downloads files, runs scripts, or handles untrusted input, the riskiest part of the system is naturally the execution environment. If all of that happened directly inside a long-lived hosted process, the boundary would be much blurrier. Once it happens inside a sandboxed VM, the line between the execution environment and the platform control layer becomes much clearer.
Splitting the system this way means the parts that should last can last, the parts that should scale elastically do not have to remain online forever, and the parts that need to interact with the outside world can stay inside a stronger isolation boundary. The agent stops being “a process”, the session stops being tied to a particular machine, and the system finally has room to preserve continuity, improve safety, and keep cloud elasticity.
0x03 > Sandbox sleep
The key step after that is making the sandbox sleepable. Once the workspace can sleep, you no longer have to choose bluntly between user experience and cost. When a session goes idle, the sandbox does not need to keep burning active compute, but the workspace inside it does not need to be destroyed either. The directory can stay. The files can stay. The browser state and intermediate artifacts can stay too.
Then, when the next user message arrives, a scheduled task fires, or an outside event finally shows up, the sandbox wakes back up and the work continues from the same place. This feels much closer to closing the lid of a laptop than tearing down an office and rebuilding it later. From the user’s point of view, the experience remains continuous. From the platform’s point of view, idle time no longer keeps consuming compute. That is exactly what a long-running agent really needs: not permanent heat, but the ability to come back.
0x04 > Why this matters
In practice, this design buys us two things. The first is experience. Users do not need to understand what happened underneath or whether resources were reallocated in the middle; they only notice that the agent still feels like the same workspace when they come back. The second is cost. Compute is spent when work is actually happening, idle sessions can sleep, empty periods can scale to zero, and busy periods can scale out.
So when Brazosd says the runtime is stateless, it is not because we are chasing some abstract idea of elegant architecture. The motivation is much simpler than that: give users the most continuous experience possible while pushing the cost of waiting time down as far as possible. The best thing about the cloud is that resources can be used on demand, and the best agent experience should not depend on keeping a hot process alive forever. The thing worth preserving is not the process itself, but the workspace the user actually cares about.