In this article
If every agent needs a permanently running computer, retaining more agents also retains more idle resources. An agent waiting until next week does not need to reason continuously or keep an active tool environment throughout that wait.
brazosd separates persistence from continuous execution. Work records and data need continuity; compute can have its own lifecycle.
Sessions, runs, and sandboxes are different
| Layer | Responsibility | Lifecycle meaning |
|---|---|---|
| Session and persistent records | Conversation, execution history, saved state | Evidence for continuing work |
| Agent run | Current reasoning and tool coordination | Start, wait, finish, interrupt |
| Work sandbox | Programs, dependencies, working files | Create, sleep, restore as needed |
Swipe to see the whole table
Closing a browser is not the same as ending a cloud run. Ending a run is not the same as deleting all files. These distinctions let the platform manage interaction, work, and resources separately.
Stateless execution does not mean no memory
The key idea is that essential work state should not exist only in one executing process's memory.
Think of a worker handing over a job. If the materials, records, and completed steps have durable homes, another worker can continue without the same process remaining alive forever.
brazosd organizes work through persistent session, run, and event records. Realtime transport communicates progress; stored records preserve evidence. Neither role should be confused with the other.
Persistence alone cannot guarantee lossless recovery at every instruction. External effects and safe retries still depend on the task.
Sleep manages the execution environment
The current sandbox lifecycle distinguishes shallow and deep sleep. Shallow sleep pauses the existing environment. Deep sleep creates a checkpoint and releases the remote sandbox, with a later restore preparing an environment again.
This is not a guarantee that every process, memory location, login, and network connection returns unchanged. Filesystem snapshots support continuity of files; programs may need restarting and conditions must be checked.
Cloud Drive and application databases have separate lifecycles. Restoring an environment does not automatically roll an external database back to the same moment. Consistent business recovery needs a separate data design.
Recovery must handle uncertain outcomes
An external operation may succeed just before its connection fails. Missing a success message is not proof that nothing happened.
Idempotency addresses this problem: repeating the same business request should avoid producing duplicate effects. Unique business identifiers, result queries, and appropriate transactions can help, depending on the target service.
A recoverable agent system therefore needs execution state and an understanding of external side effects, beyond conversation history. Sleep manages resources; safe execution preserves business correctness.
Why this affects economics
Separating persistent data from active compute allows waiting work to remain without allocating identical live resources to every task. Retained work and active work can be managed differently.
Sleep does not eliminate all costs. Files, checkpoints, and databases consume storage; inference, networking, and activation carry costs or latency. Actual economics depend on measured resource allocation and use.
The valuable question is whether work can resume reliably with understandable waiting costs, rather than whether a program is described as always online.
A foundation for proactive agents and a cloud OS
Proactive agents need to work when events arrive. UnoZ OS needs applications and files to outlive one computer. Both benefit from separating work state from execution resources.
Continuity comes from explicit state and recovery design, not simply keeping a process running.