Runtimes

A runtime is where the work runs. Most operators run in-process — Guilde executes the LLM calls and tool loops inside its own server. For some workloads you want a different runtime: an agent CLI on your laptop, an e2b cloud sandbox, a long-lived workstation.

The shape of a runtime

Three things plug together to make an operator's compute:

Runtime = Daemon (where it boots) × Sandbox (where it runs) × Adapter (what it speaks)

• Daemon — agentproto serve on your laptop (local) or a managed Guilde-hosted daemon (cloud). Issues sessions, brokers files, streams output.
• Sandbox — the actual compute. Local process, e2b sandbox, codespace, or the workstation's persistent shell.
• Adapter — the agent CLI binary that gets spawned: claude-code, hermes, codex-cli, aider, …

The Runtime page surfaces all three: Machine tokens (daemon credentials), Active sessions (currently-running adapters), Sandbox instances (the cloud shells your guild has booted).

Local daemon — your laptop as a runtime

npm i -g @agentproto/cli
agentproto serve --workspace ~/agentproto-workspace

The daemon registers, the page lights up, and your operators can drive local claude-code / hermes sessions against your real file system. First-class for code-editing operators that want to live in your repo, not a sandbox.

Cloud sandboxes — e2b, codespaces

When you don't want to expose your laptop, runtimes run in e2b-style sandboxes. Each row shows:

• Provider (local, e2b)
• Status (LIVE, COLD, STOPPED)
• Workspace attachment — which file root the sandbox sees

Sandboxes pause when idle (paused-disk billing rate), resume in seconds. Long-lived "named" sandboxes are workstations.

Adapters — the agent CLIs

Adapters are managed under Agent CLI (sibling page). The Runtime page shows their live sessions; Agent CLI is where you pick which adapter to spawn against which workspace.

Picking a runtime per operator

Each operator has a runtime field:

runtime:
  kind: agent-cli       # vs "in-process" (default)
  ref: claude-code      # which adapter
  session:
    mode: persistent    # ephemeral | persistent | resumable
    idle_timeout_ms: 600000

You set this when hiring (advanced options) or by editing the operator after. The Operators page shows the active runtime per operator with an icon next to the name.

Session modes

• ephemeral — fresh CLI process per turn. Slow start, no state across messages. Good for one-off tools.
• persistent — long-lived process, kept alive between turns. Faster. Loses state if the process dies.
• resumable — process can be paused and resumed across server restarts via state snapshots. Best for long-running operators with expensive setup.

Sibling surfaces

The Runtime page bundles a lot. Related surfaces:

• Workstation — the long-lived, named, persistent variant of a sandbox.
• Terminal (/terminal) — interactive shell against any workstation, for quick debugging.
• Sandbox (/sandbox) — the template registry; pick a template and spawn a fresh sandbox from it.
• Agent CLI (/agent-cli) — adapter library, dispatching, session history.

Troubleshooting

If a session lands in failed: click the row → look at the dispatch error. Common causes:

• Adapter not installed in the sandbox (use a template that pre-bakes it)
• Workspace not bound (pick one from the dropdown on the agent CLI row)
• Daemon offline (check the daemon section; the page auto-detects when it comes back)

What's next

• Operators — pick the right runtime per role
• Workstation — persistent named runtime
• Skills — bundle runtime-specific defaults