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 superagnt's 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 plan, a running trial, or an active credit package. Without one, deploy returns402DEPLOY_GATE_FAILEDand the dashboard shows the plans. A deploy that would take the organization past its agent limit is refused with an upgrade offer instead, and nothing is provisioned. - 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: the first message names the endpoint and carries the delivery's headers and body. 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. |
Schedules, inbound webhooks and queues are covered in depth on their own pages: schedules, receiving webhooks and queues. An agent does not have to be woken by a webhook to see it: with agnt_webhooks_receive_recent in its tool list it can read the newest deliveries, which suits an agent on a schedule that looks at what has arrived since its last run.
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 on every plan. What a plan limits is how many agents are deployed at once, not which tools you may call.
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, and neither do archived agents. The no-card trial runs on Growth limits.
| Plan | Price | Agents | rpm |
|---|---|---|---|
| Starter | $49/mo | 3 | 60 |
| Growth | $149/mo | 15 | 300 |
| Scale | $399/mo | 50 | 600 |
| Solo | $99/mo | 5 | 120 |
| Team | $199/mo | 15 | 300 |
| Business | $499/mo | 50 | 600 |
At the cap, a deploy comes back as an upgrade offer naming the next plan and its price, for a person to confirm. On the builder plans, if a plan change leaves more agents deployed than the new plan carries, the oldest keep running and the rest pause until you upgrade or archive some. When a trial ends or a plan lapses, every agent stops starting new sessions until a plan is active again. Nothing is deleted.
ai credits are separate
Every limit on every plan lives on plans and limits. Agent compute is paid from the AI wallet; data calls are paid from the data wallet. See credits and wallets.