Platform vs Runtime
The easiest way to misunderstand Agirunner is to blur workflow meaning and execution mechanics.
Agirunner becomes much easier to reason about once you treat the platform and runtime as separate product surfaces with a clear contract between them.
Platform
Section titled “Platform”The platform is the control plane. It owns:
- workflows and work items
- playbooks and role definitions
- approvals, escalations, and operator-facing state
- dashboard and public API surfaces
- task activation, routing, and claim contracts
In other words, the platform owns the durable record of what work exists, why it exists, what the system is allowed to do next, and what operators need to see or decide.
Runtime
Section titled “Runtime”The runtime is the execution plane. It owns:
- task claiming and heartbeat loops
- isolated workspaces and execution containers
- agent loop execution
- built-in tools and dynamic MCP tool exposure
- output capture, artifacts, and execution reporting
The runtime does not invent workflow meaning. It consumes an explicit task contract and turns it into actual execution with bounded tools, workspace setup, loop control, and result capture.
Why This Boundary Matters
Section titled “Why This Boundary Matters”If behavior changes because of workflow meaning, it belongs in the platform. If it changes because of execution, tooling, isolation, or transport mechanics, it belongs in the runtime.
That rule has practical consequences:
- approval and assessment legality belong in the platform
- model, role, and tool policy belong in the platform
- shell validation and workspace containment belong in the runtime
- artifact capture and execution logging belong in the runtime
The point is not purity for its own sake. The point is keeping the product coherent so the APIs, UI, and execution engine all make sense together.