Agent servers
Sizing, disk, self-deploy tokens, and what happens when you delete an agent server.
What an agent server is
An agent server — instances in the API and MCP tools — is the always-on workstation one or more Teammates run on: its own files, its own tools, always running. You create one, decide which Teammates share it, and wire up who on your team can talk to them. Everything you configure here (size, disk, self-deploy) stages as a pending change and takes effect on your next deploy.
Size
Every agent server has a size, chosen from two families:
| Family | Best for |
|---|---|
| Standard | Ops, support, SEO, sales — general-purpose Teammates |
| Performance | Engineering — heavier compute workloads |
Each family comes in Small, Medium, Large, and XL, differing in vCPU and RAM. See pricing for the full size catalog and current rates — this page won't restate numbers that live there.
Changing size later works the same as setting it initially: it's a pending change, applied on deploy.
Disk
Disk size ranges from 20 GB to 1000 GB. The default for a new agent server is 20 GB — raise it if your Teammates' workspace, skills, or working files need more room.
Self-deploy
Each agent server has its own MCP token, used when a Teammate (or a script acting through that server) calls the API on the server's behalf. The allow_self_deploy toggle controls whether that token is allowed to trigger a deploy for its own server. Leave it off unless you specifically want a Teammate to be able to deploy changes to its own server without a human clicking Deploy.
Turning self-deploy off takes that permission away from the token right away, not on your next deploy. Turning it on takes effect the next time that server restarts or is redeployed.
If an agent server stops responding
The platform checks every agent server around the clock. If one stops responding, the platform starts a fresh copy of the same server and switches over once the new copy is healthy. The old copy keeps running until then, so the switch itself adds no extra wait. If the old copy had stopped answering completely, your Teammates won't reply until the new one is ready, which takes about 10 minutes. Their files and memory carry over.
If the problem comes back within an hour, or keeps coming back, automatic replacement pauses so the server isn't replaced over and over. If your Teammate is still answering, it can see this and will tell you. Contact us so we can look at it. You don't need to deploy anything or change any settings for this.
Each agent server's page has a Health section listing the current issues the platform found on that server, such as automatic replacement being paused or a channel turned on without its token, along with when each one started. When there are none, it shows "No issues detected". "Updated" is when that list of issues last changed. "Last report" is when the server last checked in, which it does about once an hour. If Last report is more than a couple of hours old, the server may have stopped reporting, so contact us.
Deleting an agent server
Deleting an agent server permanently tears down its machine, files and backups. Deleting stages the removal; the teardown runs on your next deploy. Until the teardown starts you can discard the pending deletion; once it is running it can't be stopped or undone.
Your company memory database and your Langfuse project are kept. Deleting a server also removes the secrets you saved for its Teammates. Company secrets are kept. Contact support within 30 days if you need a deleted server's Teammate secrets back.
Once the server is gone, its MCP tokens are revoked — anything that was authenticating with that server's token stops working. Make sure nothing outside the platform depends on that token before you delete.
Deleting removes every Teammate on that server along with it.
Shutdown vs. delete
Shutting down an agent server stops it without deleting its configuration. Deleting is permanent; shutdown is not.
Also configurable per server
A few things that live at the agent-server level are documented on their own pages because they have enough surface area to need it:
- Model configuration — an agent server can narrow the company-wide allowed model list to a subset for its own Teammates.
- Secrets & egress — host allowlists and secret overrides can be scoped to a server.
- Deploys & pending changes — force-deploy and discard operate per server.
API and MCP
Agent servers have full dashboard/API/MCP parity — everything above is available through the HTTP API and MCP tools as well as the dashboard. See API & MCP for the resource map.