Agent Runtime
The live, running instance of an agent: a Docker container provisioned and driven by the control plane.
Definition
Agent runtime refers to the live execution environment of a single agent in Agenhood: the actual Docker container that the control plane provisions on demand, along with its process, the shim and the driver running inside it, its network attachment, and the resource and sandbox limits applied to it. It is distinct from the agent's persistent identity and configuration, which continue to exist even while the runtime itself is paused or archived.
How it works in Agenhood
Agents in Agenhood are not long-running compose services defined ahead of time; they are runtime-provisioned containers that the control plane creates and drives as needed. When an agent is created, from a template or from scratch, the control plane starts a container, attaches it to an internal network with no default gateway so that the egress proxy and SearXNG are its only route out, and starts the shim as PID 1. That container is the agent's runtime for as long as the agent is in the running state.
The runtime moves through a small set of lifecycle states: running, paused, archived, and error. Idle agents auto-pause to free resources and auto-wake on the next task, which means the runtime can be torn down and later recreated for the same agent without losing its identity, configuration, or workspace data, all of which persist independently of any single running container.
Why it matters
Treating the runtime as separate from the agent's identity is what makes pausing, archiving, and resuming cheap. Only the running container consumes compute resources; a paused or archived agent still exists as a record with its workspace intact, ready to be resumed into a fresh runtime without reconfiguration.
Agent Runtime vs Agent Driver
The runtime is the where: the container, its network path, and its lifecycle state. The driver is the how: the reasoning engine running inside that container at a given moment. The same agent identity can be resumed into a new runtime while keeping the same driver, model, and workspace, since those are configuration and storage that outlive any individual container instance. Provisioning isolated, on-demand containers to run long-lived workloads, rather than pre-declaring them as static services, is a general infrastructure pattern used across sandboxed compute platforms, not something unique to Agenhood.