Core concepts
The vocabulary and mental model behind Teammates, agent servers, deploys, and how the platform is put together.
Teammates and agent servers
The dashboard talks about "Teammates" and "agent servers." The API and MCP tools use older, more technical names for the same things — you'll see both, so here's the map:
| What you call it | What the API/MCP calls it | What it is |
|---|---|---|
| Teammate | agent | A configured role: a prompt, a model, a set of skills, a personality. |
| Agent server | instance (instance_id) |
The always-on workstation a Teammate (or several) runs on — its own files, its own tools. |
| Workspace / soul documents | agent config files | The identity and instruction files (SOUL.md, IDENTITY.md, and others) that define how a Teammate behaves. |
| Skills | skills | Reusable capabilities you add to a Teammate; the same skill from the catalog can be added to multiple Teammates. |
| Channel | messaging config | The Telegram, Discord, or Slack connection a Teammate replies through. |
| Deploy | deploy | Promoting everything you've staged from pending to live. |
Built on OpenClaw
Your Teammates run on OpenClaw, an open-source agent framework — we didn't build a proprietary runtime and call it something else. OpenClaw is real, and it's good; running it well at scale is the hard part, and that's what we do. Think of it the way Vercel relates to Next.js: the framework is genuinely open, and we're the managed layer on top of it — the servers, the security model, the dashboard, the parts you'd otherwise have to build and operate yourself. See Run OpenClaw in the cloud for the full comparison against self-hosting.
Nothing goes live until you deploy
Every change you make — adding a Teammate, editing a workspace file, adjusting allowed models, adding a channel — stages as a pending change. Your live agent servers keep running exactly as configured until you explicitly deploy. That gives you a chance to review a diff of everything about to change before it goes out, rather than discovering the effect of an edit after the fact.
Some pending changes apply fast (workspace and skill edits reload in place); others — model, secret, or channel changes — require rebuilding the agent server from scratch, which takes longer. Either way, nothing changes on a running server without a deploy — the one exception is integration connections, which go live as soon as their sign-in completes. See Deploys & pending changes.
The configuration cascade
Settings resolve through layers: platform defaults, overridden by your organization, overridden by an individual agent server, overridden by a specific Teammate. Sane defaults everywhere, full control anywhere you need it. You'll see this pattern concretely in a couple of places — for example, your organization's allowed model list can be narrowed further for one agent server, and a Teammate's default model must come from whatever list applies to the server it's on. See Model configuration and Secrets & egress for the cascades that matter most in practice.
Managed vs. custom
Teammates and skills can come from a catalog template that we maintain — pick one and it keeps receiving updates automatically on future deploys. The moment you edit a managed Teammate's workspace files or a managed skill directly, it converts to custom: it's yours from then on, and it stops receiving template updates. That conversion is one-way and cannot be undone — template switching is only available while a Teammate is still managed. The only way back to managed updates is to create a new Teammate from a template.
Three equivalent ways in
Almost everything you can do in the dashboard, you can also do through the HTTP API or through MCP tools — the same actions, the same business rules, just a different door. That means you can configure Teammates by hand, script it, or let a Teammate propose changes to its own configuration for you to review and approve. A handful of workflows (like connecting a GitHub App) are dashboard-only for now. See API & MCP for the full parity map.
Security posture, in short
The platform is built assuming a Teammate will eventually be exposed to a prompt injection attempt — and designed so that doesn't matter as much as it would otherwise. Two structural pieces worth knowing up front:
- Workspace files are mounted read-only at runtime. A Teammate can't rewrite its own instructions on the fly; changes go through the same pending-change, review-and-approve path as everything else.
- Secrets are never handed to the model as real values. A Teammate holds a placeholder, not a key — the real value is substituted only when a request reaches the specific destination that key is bound to.
See Secrets & egress for how that plays out for your own provider keys and integrations.