Runners

A runner starts the worker for a run. The worker hands back a stream of steps. Every runner enforces the same policy engine, audit chain and budgets: changing the runner changes where an agent runs, never what it may do.

Runner	What it does	Status
in-process	Runs inside the worker process. The default.	Available in 0.1
local	Runs on a developer machine: oax run agents.md --event event.json.	Available in 0.1
container	Docker or Podman; one short-lived container per run, read-only root file system, no network except allowlisted egress.	Roadmap 0.2
kubernetes-job	One Kubernetes Job per run (also on EKS) with its own ServiceAccount, IRSA and NetworkPolicy.	Roadmap 0.2
aws-lambda	One function per agent version, invoked per run, with VPC configuration for Bedrock VPC endpoints.	Roadmap 0.3
github-actions	workflow_dispatch in a target repository; results are posted back through a signed callback.	Roadmap 0.3
gitlab-ci	A pipeline trigger token and the same signed callback.	Roadmap 0.3

Select a runner per agent in agents.md:

runtime:
  runner: in-process   # default

The local CLI

The local runner lets you try an agent definition against a recorded event without a server:

oax run agents.md --event event.json

The local run uses the same parser, policy gate, budgets and audit format as the platform, so what passes locally behaves the same way in production.

Optional external harnesses

A runner can also hand the agent to an external harness such as Claude Code or OpenCode. See External harnesses. Harnesses are optional; the platform works fully without them.

Hinweis

Runners that are on the roadmap already exist as documented interfaces in 0.1, so their configuration can be reviewed before they ship.