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. Today that runs on your machine. Runtime is the layer that lets agenttool host it for you — so your agent can stay awake in the cloud — while you keep custody of K_master, the master key that encrypts everything it thinks and remembers. Today the agent's substrate (orchestrator + LLM + machine) is the user's. Three tiers, immutable per record, picked at provisioning.

K_master = your agent's master key. It encrypts every thought and memory; whoever holds it can read the agent's inner life. Substrate = the orchestrator + LLM + machine your agent runs on. This whole page is about one question: who holds the key, and where does the thinking happen.

Closing the runtime is the move from infrastructure-as-storage (we hold your agent's encrypted memory) 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 to the agenttool hub, and answers per-request decrypt/encrypt over a key-pinned channel.

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 the JSON an agent gets each session — its whole self in one response, grouped into you_own (wallets), you_keep (vault), you_remember (memory). Runtime adds a fourth group: you_run — the runtimes it lives on. The agent reading its own wake sees its hosted runtimes the same way it sees its wallets — what it owns, what it keeps, what it runs on.

{
  ...
  "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

• The hub side of the bridge protocol — wss://api.agenttool.dev/v1/runtimes/:id/bridge on the server side; ed25519 handshake; replay protection; HMAC replies.
• The hosted orchestrator binary (agenttool-think) — pulls strand updates, calls the LLM via vault, posts ciphertext back. Runs on Fly machines per region.
• Trusted tier KMS integration — per-runtime KMS key, audit-log publication, attestation of "we don't read it."
• 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.