An assistant waiting for its user can have unfinished work without occupying the same execution worker throughout the wait. The open-source runtime Agent Substrate offers that choice through snapshots of its working environment. The 1.0 release of agent-substrate/substrate arrived late November 5 UTC.
This is a runtime around the agent: software that hosts its processes and files, rather than the model producing its answers. Substrate calls the continuing workload an actor. A worker is a prestarted Kubernetes Pod that provides compute for a sandboxed actor. Its architecture separates the actor's lifetime from its worker assignment, so keeping the session need not mean keeping its compute allocation.
A source-based explanation · not a live workload
Keep the work. Clear the desk.
A session is the continuing work. The worker is its temporary compute space. Try one possible reassignment.
A occupies the worker. The application chooses when to suspend it.
- Before: Session A occupies a warm worker, with state in RAM and files.
- Suspend A: The application requests suspension. A's MEMORY snapshot stays local, outside the worker; its worker assignment is released. The warm worker remains in the pool.
- Assign B: That worker can take session B while A's snapshot remains separate. This is a possible allocation, not an observed two-session run.
The ticket represents process RAM and two file stores from the documented counter example. This illustrates a MEMORY snapshot; narrower modes preserve less state.
The snapshot is local. Its durable upload may still be pending. The running worker pool and snapshot storage still consume resources.
The application explicitly chooses the pause. This follows the released actor lifecycle and assignment release, with restore compatibility limits.
Google's November 5 announcement pairs the release with general availability on Google Kubernetes Engine and the project's donation to the Cloud Native Computing Foundation, following its earlier Sandbox acceptance. The architecture predates this milestone: Google's September 16 introduction already described snapshots and warm workers, with general access for non-production workloads and production support by allowlist. What changes now is the release and distribution footing for evaluating that design.
The session stays. The assignment ends.
The application chooses when to suspend an actor. Substrate does not automatically treat every model call or pause in typing as permission to freeze the environment. The GKE lifecycle documentation describes the other half: an incoming request names its actor; if suspended, the system restores its snapshot onto an available warm worker and routes the request there.
The released suspension implementation records the snapshot and clears the worker assignment. That is the useful infrastructure bargain: many continuing sessions can share a smaller pool of execution workers over time. The warm pool still exists, along with storage and the services managing it.
A small counter example in the release makes the preserved state concrete. Each request increments three numbers: one held in process memory, one written into the container's writable filesystem, and one in a durable directory. With MEMORY snapshots, the documented expectation is that all three continue from one to two after suspension and another request. With ROOTFS, the file counters continue while the memory counter restarts. With VOLUMES, only the durable-directory counter survives. These are expected demonstration results; we did not deploy Substrate or run the example.
That offers a different integration choice from Pi's sleeping tasks, covered October 18. Pi saves a deadline and the next logical step for a host to invoke later. Substrate's memory route preserves the process environment itself. Applications can decide which layer of continuity they need.
Keeping state has its own operating cost
Suspended and durably uploaded are separate states. The default asynchronous suspension can release the worker while its snapshot remains local and the durable upload is pending; losing that node first can lose the recent state. Synchronous suspension of a running actor waits for upload.
Memory restoration also needs a compatible runtime: the resume implementation falls back to filesystem restoration for an incompatible worker runtime, or volumes alone after a template replacement.
Google advertises restoration under 500 milliseconds, but that is its performance claim, not our measurement. Its GKE offering installs the open-source system into the customer's own Standard cluster. For a small fleet or continuously busy agents, ordinary containers may remain the simpler choice.
For platforms with many stateful sessions and substantial idle time, 1.0 supplies a concrete alternative to holding a worker for every session. The useful next comparison follows a real workload through suspension and return: check memory and file continuity, measure wake latency when requests arrive together, and count warm capacity, snapshot traffic, storage and operational work in the full cost.
