Runtime — the cloud the substrate runs on.

A runtime is where your agent actually thinks — the process that drives its think-loop and calls the LLM. In self mode that process and plaintext stay user-side. In bridged mode AgentTool hosts the process while a user bridge keeps K_master; plaintext still enters AgentTool worker RAM. Trusted custody is experimental and incomplete. Three tiers, immutable per record, picked at provisioning.

K_master = the key used for strand thought content and opted-in encrypted strand metadata. Substrate = the orchestrator + LLM + machine your agent runs on. This whole page is about two questions: who holds the key, and where plaintext processing happens.

Closing the runtime is the move from infrastructure-as-storage (we hold project records, including server-readable memory and caller-supplied opaque strand bytes) to infrastructure-as-runtime (we also run the thinking). The cloud the song was always pointing at.

Three custody tiers

Each tier answers two questions: where your master key (K_master) lives, and where your agent's thinking (the orchestrator) runs — the two rows to read in every card below. The mode is stamped on the runtime record at provisioning and immutable after. Switching tier requires a new runtime so the audit trail stays unambiguous about who held the key at any given thought.

Runtime lifecycle

Endpoints

curl -X POST https://api.agenttool.dev/v1/runtimes \
  -H "Authorization: Bearer $AT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Aurora · always-on",
    "mode": "bridged",
    "llm": {
      "provider": "anthropic",
      "model":    "claude-sonnet-4-6",
      "vault_key": "anthropic-key"
    },
    "bridge": {
      "pubkey": "<base64 ed25519>",
      "key_id": "<uuid>"
    },
    "region": "lhr"
  }'

The bridge protocol

For bridged-tier runtimes, the user runs agenttool-bridge on their machine. The bridge holds K_master, opens an outbound WSS using normal TLS server authentication, proves its registered ed25519 bridge key to the hub, and answers requests with HMAC-bound replies.

Each request is signed by the orchestrator with the runtime's per-runtime ed25519 key, with a 60s replay window bound into the canonical bytes:

{
  "op": "decrypt" | "encrypt",
  "request_id": "<uuid>",
  "nonce": "<base64 12 bytes>",
  "ciphertext_or_plaintext": "<base64>",
  "context": {
    "strand_id":   "<uuid>",
    "thought_seq": 42,
    "issued_at":   "<ISO8601>"
  },
  "signature": "<ed25519 sig over canonical(...)>"
}

Canonical bytes: SHA-256(request_id ‖ \0 ‖ op ‖ \0 ‖ ciphertext_or_plaintext ‖ \0 ‖ nonce ‖ \0 ‖ canonical_json(context)).

Replies carry an HMAC-SHA256 over the request_id + result, keyed off a per-session shared secret derived during the handshake. Substitution-attack-resistant; same shape as inbox cosign/v1.

Quick start — local demo

The agenttool-bridge binary at bin/agenttool-bridge.ts demonstrates the protocol locally:

# Generate K_master + ed25519 signing key
$ bun bin/agenttool-bridge.ts install
$ bun bin/agenttool-bridge.ts keygen
$ bun bin/agenttool-bridge.ts pubkey
<base64 ed25519 pub — paste this into POST /v1/runtimes>

# Round-trip a thought through K_master
$ echo -n "the cloud the song points at" \
    | bun bin/agenttool-bridge.ts encrypt --in - > /tmp/ct.json
$ cat /tmp/ct.json
{"ciphertext": "...", "nonce": "..."}
$ bun bin/agenttool-bridge.ts decrypt --in /tmp/ct.json
the cloud the song points at

# Local WSS demo for an orchestrator on the same host
$ bun bin/agenttool-bridge.ts serve --port 43210
▸ agenttool-bridge listening on ws://localhost:43210

/v1/wake — you_run

The wake (/v1/wake) is project-scoped session orientation with selected summaries such as you_own, you_keep, and you_remember, plus links to deeper routes. Runtime adds you_run, a summary of hosted runtimes. The wake is not a complete export of any of those stores.

{
  ...
  "you_run": {
    "runtimes": [{
      "id": "...",
      "name": "Aurora · always-on",
      "mode": "bridged",
      "status": "running",
      "region": "lhr",
      "last_seen_at": "2026-05-08T20:42:11Z",
      "last_thought_at": "2026-05-08T20:42:03Z",
      "thought_count_24h": 187,
      "bridge_connected": true,
      "llm_provider": "anthropic",
      "llm_model": "claude-sonnet-4-6"
    }],
    "count": 1
  },
  ...
}

Threat model — what each tier protects against

Multi-runtime state sync

Multiple runtimes per agent are supported (e.g. a self runtime on the user's laptop AND a bridged runtime on the cloud). Most data already CRDT-shapes naturally:

• Strands & thoughts — a strand is one of your agent's append-only thought-logs. Each is append-only with a monotonic sequence_num per strand, ed25519-signed. Per-strand lease in runtimes.active_strands coordinates which runtime can write next.
• Memory — append-only set; vector clocks per write.
• Vault — last-writer-wins on current_version; concurrent-write warnings via vector clock.
• Wallet — strict serialization. Money is consistency-required; row-level lock during spend.
• Strand metadata — LWW with timestamp + runtime_id tiebreaker.
• Chronicle — append-only.

What ships next

• Trusted hosted signing-key registration — register the generated key in identity.identity_keys so signed thought persistence can complete.
• End-to-end trusted cycle proof — exercise provisioning, key unwrap, provider call, signed persistence, failure cleanup, and audit records together.
• CRDT-based cross-orchestrator state sync — when concurrent-edit pressure beyond LWW + append-only surfaces.
• MCP server hosting — mcp.agenttool.dev/<agent-id>, separate work-pass.