# From an AI agent

How an AI agent stands up and drives runward end to end: the mental model, the neutral baseline written at init, and building against the charter.

The headline claim — an agent can "discover, install and operate runward with no human at the keyboard" — is true, with one deliberate exception this page explains in full: runward never wires the gate into your repo by itself. The agent can perform that wiring, but only on the operator's explicit say-so. That is a feature, not a gap.

The loop an agent drives is the same everywhere: build, run the check, and on gaps loop back; on green, cross the gate.

> **Diagram.** You describe the mission; your agent builds the code and fills the conformance manifests; then runward check --strict decides. If gaps remain, it sends you back to fill the named deliverable and re-run. When everything is filled and every rule accounted for, the gate goes green (exit 0). That is the loop: the check sends you back to build, or lets you exit.

## The mental model: agent drives, runward frames

### What runward is

runward does not generate code and is not a runtime. It is a deterministic frame around agent-produced delivery: the agent builds, and `runward check` audits whether the required deliverables exist and whether every CRITICAL/HIGH craft rule was accounted for with evidence that resolves. The audit is documentary — "runward did not run your code — it is not a runtime". The LLM lives in the harness driving runward, never in the gate.

### The operating loop

The whole operating loop for an agent is:

1. `runward init` — stand up the mission.
2. Build, consulting the charter and phase skills.
3. `runward check` / `runward check --strict --json` — read the verdict.
4. Optionally `runward wire` — identify the auto-trigger channel and, on approval, wire it.
5. Cross gates on evidence.

Exit codes are the primary signal throughout:

- `0` current gate clean
- `1` gaps
- `2` no mission found

## Step 1 — `init` writes a strictly vendor-neutral baseline

`runward init` scaffolds the mission. With no explicit `--tools`, it writes only the vendor-neutral core and privileges no harness (ADR-0030).

### Two surfaces always written

Two surfaces are always written, unconditionally, before any tool profile:

- **`AGENTS.md`** at the project root — the agent charter. This is the open standard read by Codex, Cursor, Copilot, Windsurf, Cline, Zed, Amp, opencode, goose, Junie, Warp and a long list of agents.
- **`.agents/skills/runward-<phase>/SKILL.md`** — the vendor-neutral phase skills, the converged SKILL.md format read by 14+ harnesses, no agent privileged.

### Profiles are opt-in

Under `--yes` (or any non-interactive run) the tool-profile list is empty and the wizard pre-checks nothing. A per-harness profile (`.claude/`, `.cursor/`, `GEMINI.md`, etc.) is an opt-in the operator or agent adds afterward, never a default. This closes a prior defect where `init` silently defaulted to the `claude` profile (ADR-0030).

### Why neutral by default

Detecting the harness and auto-selecting its profile is reliable for only two or three harnesses and blind for the rest, so a detection-first `init` would "dress a partial capability as a general one and privilege Claude/Gemini by accident". The baseline already carries full operability: from the end of `init`, `runward check` runs in any harness with nothing else wired.

### Agent recipe (fully non-interactive)

```
runward init --yes                 # neutral baseline, greenfield, floor tier
runward init --yes --tools cursor  # add one profile explicitly, on the operator's request
runward init --example             # a filled reference mission, every gate green out of the box
```

Supported `--tools` ids: `claude, cursor, copilot, gemini, windsurf, continue, junie, trae, kiro` (unknown ids warn but do not fail).

## Step 2 — build against the charter and phase skills

### The charter

`AGENTS.md` states five non-negotiable boundaries:

- architecture constrains the model
- boundaries before the stack
- complexity deferred until a trigger
- deterministic frontier
- security on actions not display

and the working loop:

- apply the craft rules at the point of action
- run the decision-loop before any structural decision
- one ADR per decision
- never mark a phase done without its Definition of Done

### The phase skills

The phase skills self-activate by relevance: each carries a `description` trigger an agent matches on, and points the agent at the CRITICAL/HIGH rules for that phase and at `runward manifest --sync` to scaffold the conformance rows it must fill. The skill helps apply rules; it does not enforce them — "`runward check --strict` is the sole authority".

## Continue in this section

- [The machine contract: check --json and wire](https://runward.dev/docs/en/operating/from-an-agent/machine-contract/)
- [The boundary: runward never wires itself](https://runward.dev/docs/en/operating/from-an-agent/the-wiring-boundary/)

## See also

- [The machine contract: check --json and wire](https://runward.dev/docs/en/operating/from-an-agent/machine-contract/)
- [The boundary: runward never wires itself](https://runward.dev/docs/en/operating/from-an-agent/the-wiring-boundary/)
- [Wire the gate](https://runward.dev/docs/en/operating/wire-the-gate/)
- [Quickstart](https://runward.dev/docs/en/getting-started/quickstart/)