Ways to Use Engineering Runtime
The same runtime binary serves three consumers. Behaviour is identical —
Bootstrap → Context → Policy → Auth → Execution → Audit — only the
caller changes.
┌─────────────┐ ┌─────────────┐ ┌──────────────────┐
│ Human │ │ CI/CD │ │ AI / Runtime │
│ engineer │ │ pipeline │ │ Agent │
└──────┬──────┘ └──────┬──────┘ └────────┬─────────┘
│ │ │
└────────────┬────┴───────────────────┘
▼
runtime binary
▼
Engineering platforms
| Mode |
Who drives |
Typical entry |
Guide |
| Local (human) |
You, in a terminal |
runtime github …, runtime capability execute … |
Local setup |
| CI/CD |
A pipeline job |
Composite action → runtime capability execute … |
CI/CD |
| AI agent |
Claude / Cursor / any agent under the Runtime Agent contract |
Agent may only invoke runtime … |
AI agent |
What every mode shares
- One binary. Install from
engineering-runtime-releases
(or build from source). No daemon, no language runtime.
- One Runtime Home. Config, policy, context, specs, commands, audit —
see Runtime Home.
- Two execution surfaces.
- Provider operations:
runtime github …, runtime files …
- Command Engine:
runtime command run <binary> …
- Capabilities. Markdown workflows that compose the surfaces above —
runtime capability validate|execute ….
- Governance before work. Policy can deny before auth or execution;
every outcome (including denial) is audited.
Pick a path
Identity on the audit trail
Set ENGINEERING_RUNTIME_CONSUMER
so audit records show who drove the binary:
| Value |
Use when |
human |
Interactive terminal (default when unset and not CI) |
ci |
Pipelines — samples set this explicitly |
ai |
Runtime Agent sessions |
export ENGINEERING_RUNTIME_CONSUMER=ai
runtime github user get
runtime audit tail -n 1