Hosted agents
An agent is a long-lived worker you configure once and reach from anywhere: a chat window, a Slack channel, a phone number, a schedule, a webhook, or another agent. It runs on our infrastructure, bills to your workspace, and keeps a full transcript of everything it did.
One row, one runtime, many doors
A deployed agent carries a name and description, a system prompt, a model, a set of tools with a permission level on each, the channels it answers on, its schedules and webhook triggers, the knowledge collections it can search, and the workspace memory it writes to. Every execution of that agent, whoever or whatever started it, is a session.
Sessions are the unit of accounting and the unit of investigation. Cost is attributed per session, the transcript is stored per session, and a chat thread that continues over days is one session rather than many.
Nothing runs until you deploy it
An agent starts life as a draft. A draft exists in the workspace, shows up in the list, and can be edited freely, but it never receives input and it costs nothing. Deploying is the moment it becomes real.
- 01
Give it a name and a prompt
Deploy refuses an agent that is still calledUntitled agentor that has an empty system prompt. Both checks run before anything is provisioned, so a refusal leaves no partial state. - 02
Clear the entitlement gate
The organization needs an active feature plan, an active trial, or an active credit package. On the builder plans that is not enough on its own: the org must also hold the Agent Runtime module, which is what sells deploying there. Without either, deploy returns402DEPLOY_GATE_FAILEDand the dashboard offers a card-backed trial. - 03
Deploy
The runtime is provisioned, a per-agent gateway key is minted, and the agent flips live. From the first session it consumes workspace credits. Deploy is idempotent: calling it on a live agent returns the agent unchanged.
the gate is per organization
The index and the detail page
The agents index lists every agent in the workspace with search across names and descriptions, pinning, and teams. A team is a folder: agents can be moved into one, and deleting a team leaves its agents in place, just ungrouped. Archived agents collapse into their own section at the bottom, read only.
Opening an agent gives you six tabs: Overview, Sessions, Runs, Approvals, Analytics and Config. Talking to the agent is deliberately not one of them. Chat happens in the floating chat window, so the tabs stay an investigation and configuration surface rather than a conversation you can lose your place in.
Overview, Analytics
What the agent is, what it has been doing, and what it has spent.
Sessions, Runs
The read-only transcript inspector, and one row per schedule or webhook fire.
Approvals
Tool calls the agent paused on, waiting for a human to allow or refuse them.
Config
Prompt, model, tools, documents, permissions, triggers and channels.
Ten doors, one session model
Every surface that starts an agent stamps its own origin on the session it creates, so you can always tell what woke the agent. Conversations with a human deliver their reply back to the surface they came from. Background runs (schedules, webhooks, queues, inbox sweeps and agent-to-agent hand-offs) drain and bill but never post, and they stay out of the conversation list. Schedule and webhook fires additionally write a row on the Runs tab; the other background origins do not.
| Surface | What wakes it |
|---|---|
| Dashboard chat | A person talking to the agent in the floating chat window. |
| Slack | A message in the agent home channel, an @-mention in a mention channel, or a direct message. |
| iMessage | A text from a confirmed phone binding to the shared agnt number. |
| Schedule | A cron-style trigger the agent owns. Produces a run row and a background work session. |
| Inbound webhook | A third-party POST forwarded to the agent. Also a run row, also a work session. |
| Queue item | An item drained off one of the workspace queues. |
| Inbox | Email triage escalating a thread, or a reminder sweep coming due. |
| Another agent | agnt_agents_dispatch handing work down. The sub-agent session records the caller. |
| The Agnt Wizard | The builder opening a probe session against the agent while it configures it. |
| An MCP client | agnt_agents_session_start from a coding agent or any other MCP client. |
The lifecycle and invocation families
Everything the dashboard does to an agent is also a tool on the workspace MCP server, so a coding agent can build, deploy and drive agents without opening a browser. Both families are served by default; calls are metered against the Agent Runtime module on the builder plans.
no approval card here
Lifecycle
| Tool | What it does |
|---|---|
agnt_agents_list | Every agent in the workspace with its draft, disabled and model state. Start here: every other call takes an agent_id from this list. |
agnt_agents_get | One agent in full, including the config blob. Read it before patching, because the patch is a diff against exactly this config. |
agnt_agents_create | Creates a draft. A draft costs nothing and cannot receive input until it is deployed. |
agnt_agents_update_config | Applies a config diff immediately. There is no approval card on this surface, and a change to a deployed agent takes effect on its next session. |
agnt_agents_deploy | A real deployment: it provisions the runtime, mints the gateway key and starts billing. Idempotent, so an already-deployed agent comes back unchanged. |
agnt_agents_set_enabled | Stops or resumes an agent without tearing anything down. The reversible way to stop a misbehaving agent. |
agnt_agents_archive | Archives the runtime and revokes the gateway key. Not reversible from this surface. |
Invocation
| Tool | What it does |
|---|---|
agnt_agents_dispatch | Fire and forget. Hands a task to another deployed agent and returns immediately; the run bills to the workspace under the target agent. |
agnt_agents_session_start | Opens a real, drivable session with a deployed agent. The synchronous counterpart to dispatch, and the right tool for a post-deploy smoke test. |
agnt_agents_session_send | Sends a follow-up message into that session. Each message runs the agent and bills compute. |
agnt_agents_session_poll | Long-polls the session status (idle, running, archived). Status only: reading the transcript is agnt_observability_read_session, in a separate family. |
Reading what an agent actually said lives in the observability family, which is enabled independently. See sessions and observability.
How many agents a plan carries
The agent cap is a plan limit, checked at deploy time. Drafts do not count against it, because a draft never runs.
| Plan | Price | Agents | Seats included | rpm |
|---|---|---|---|---|
| Solo | $99/mo | 5 | 1 | 120 |
| Team | $199/mo | 15 | 3 | 300 |
| Business | $499/mo | 50 | 5 | 600 |
| Toolkit | $19/mo | none until the Agent Runtime module is added | 1 | 300 |
| Toolkit All-Access | $139/mo | 5 | 1 | 600 |
On the builder plans, deploying is sold as the Agent Runtime module at $49/mo, with a 7-day free trial. It requires the Database & Canvas module ($19/mo), which the confirm flow adds alongside it. Holding it covers 5 agents, and further agents are $9 each.
published allowances
Full plan and module detail lives on plans and Toolkit modules. Agent compute is paid from the AI wallet; data calls are paid from the data wallet. See credits and wallets.