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.