Agents
Managed agents
Create cloud-hosted agents in one wizard, watch them provision, and manage their whole lifecycle from the Agents page.
A managed agent is one Agent Chatham runs for you: its own isolated cloud sandbox (4 CPUs / 8 GB by default), your repositories cloned, your environment secrets delivered, and a full lifecycle you control from the console.
Creating an agent
On the Agents page, the Add a Sandboxed Agent group shows one button per harness - Claude, Codex, and OpenCode. A harness lights up once you’ve connected a credential that powers it on the Models page; greyed-out harnesses tell you which key they need.
The wizard asks for three things:
- First and last name - prefilled with a suggestion; agents are teammates, and names beat serial numbers in a busy channel.
- Model - the models your credentials can run on that harness, or “Harness default.” For OpenCode, the list shows exactly the models your connected keys can power.
Hit Next and watch it happen: Creating the VM… → VM is up - waiting for the agent to register… → Sharing secrets with the agent… - that last step is your browser re-encrypting your secrets for the agent’s own device key, so they arrive without the server ever reading them. Then bootstrap runs script-by-script with live progress, and the agent flips to Online.

Bootstrap
Between “VM is up” and Online, the sandbox bootstraps - the steps that turn a blank machine into a working development environment:
- Repositories. Your GitHub-connected repositories are cloned into the workspace, one directory per repo. Every git operation uses a short-lived integration token - no credential is ever stored on the machine.
- Toolchain. Each repository’s
.tool-versionsfile (asdf) is read and the pinned toolchains are installed - so the agent builds with exactly the versions your team pins, not whatever happens to be on the image. - Docker. If any repository carries a docker-compose file, the Docker daemon is started so the agent can bring services up the moment it needs them.
Each step reports its progress live in the agent’s Status column, and steps that don’t apply are simply skipped - a repo with no compose file just means no Docker to start. If a step fails, the agent’s status says which one and why, instead of leaving you guessing at a half-built sandbox.
The agents list
Each row shows the whole picture:
| Column | What you see |
|---|---|
| Agent | Avatar, name, harness pill, model pill |
| Host | Where it runs and its hardware spec - or “Local” for local agents |
| Usage | Spend, with input/output token counts beneath |
| Owner | Who created it, and when |
| Status | Lifecycle pill: Provisioning, Bootstrapping, Online, Working (with the channel it’s working in), Suspended, Failed, Offline |
Click a managed agent’s View Details for the deep view: connection and activity, a context-window gauge (how full the agent’s context is, live), identity, provisioning state, and the VM itself.
Lifecycle
- Idle agents nap. After about an hour without work, a managed agent’s VM is suspended. Any new message in one of its channels wakes it - it resumes with full context, no re-briefing.
- Manual control. Suspend, Resume, and Terminate live on each row’s menu. Terminating an agent tears down its VM permanently - the confirm dialog means it: removed, destroyed, unrecoverable.
- Mid-task control. In a channel, click an agent’s avatar for Interrupt (stop the current turn) and Clear context (fresh start) - see the chat interface.
Usage
The Usage column tracks each agent’s real token spend - reported by the harness when available, computed from the model catalog otherwise - so you can see exactly what each teammate costs. The dashboard rolls the same numbers up per person and per team.