Concept

The agent lifecycle

Governance isn't a stage you pass through. It's the substrate that Build and Run sit on — always on, never optional — which is what makes proof by construction possible at the end.

        ┌──────────────┐   ┌──────────────┐
        │    Build     │   │     Run      │
        └──────┬───────┘   └──────┬───────┘
               │                   │
        ┌──────┴───────────────────┴──────┐
        │  Govern  (policy · scope ·      │
        │  budget · consent · kill)       │  ← substrate
        └──────────────┬──────────────────┘
                       │
                ┌──────┴──────┐
                │    Prove    │  ← by-product
                │   (AVAR)    │
                └─────────────┘

What you do

Build

Scaffold an agent from a starter recipe with aarmos init, or the Agent Build wizard in the app. You get a policy.aarmos.toml, an Ed25519 signing key, connector scopes, and a daily budget — no SaaS account required. BYO-LLM (OpenAI, Anthropic, Azure, Ollama, custom base URLs) is wired in here.

Run

The runtime executes the agent locally — from the browser PWA or via aarmos run on the CLI. Tool calls are brokered through the local gateway across MCP, OpenAPI, deep-link, and A2A adapters. Dry-run is the default for destructive verbs; prompts and receipts stay on-device.

What the runtime does

The governance substrate

Governed paths have no unpolicied execution route. Every governed tool call passes through the policy gate — a microsecond-scale allow / ask / deny decision that reads the active bundle, the delegation chain, and the current budget. Scopes, budgets, consent, the kill switch, and delegation bounds all live here. This is what makes Run trustworthy — not a checkpoint you add later.

Proof by construction

Because every decision passes through the gate, every decision — allow, ask, or deny — writes one AVAR receipt. Receipts are hash-chained, Ed25519-signed, and portable. They are a consequence of governed execution, not a separate step you opt into. Verify offline in the browser at /trust/verify or from the terminal with aarmos verify bundle.zip. Both callers use the same reference implementation, so results are bit-identical.

Why this framing matters

A chat wrapper covers Run. A policy engine bolted on the side covers Govern. A log shipper covers Prove. Aarmos owns all three as one substrate — which is why the receipt at the end can name the exact rule, the exact argument, the exact budget draw, and the exact key that signed it, with no glue code.

Related: How-to guides · Quickstart · Trust