Containers And Workspaces

The runtime itself is a long-running service. Individual tasks execute inside separate containerized environments with fresh workspace state.

This distinction is one of the main reasons the runtime exists as a separate system. It gives Agirunner a real execution boundary instead of letting control-plane logic run directly against the host machine.

Workspace Materialization

Before a task loop starts, the runtime can:

• materialize a repository-backed workspace
• prepare the filesystem layout
• inject task context and inputs
• set up git identity and related execution context

That gives the task a clean, task-scoped filesystem instead of direct access to long-lived platform state.

Execution Containers

The runtime then runs the task inside a dedicated execution environment with its own filesystem state and resource limits.

This is what lets agents:

• clone repositories
• run builds or tests
• write files
• install dependencies

without polluting the host or another task.

Why This Boundary Matters

The platform can describe what environment should be used, but the runtime is the system that actually creates the isolated workspace and execution container. That boundary is what makes agent execution repeatable and debuggable instead of ad hoc.

How It Connects To The Rest Of The System

This runtime behavior is the execution-side counterpart to several platform and dashboard surfaces:

• Workspaces defines the durable project record and retained context the runtime materializes from
• Environments defines the execution profile the runtime should launch inside
• Workflow Detail and Live Containers are where operators see the results of that materialization and container launch on real work

The platform owns the durable record and policy. The runtime turns those records into an isolated filesystem and container for one task.