Building an agent
You describe the job in plain language and the Agnt Wizard writes the agent: prompt, tools, permissions, triggers and channels. Everything it writes is visible and editable on the Config tab, and the same build is available as tools if you would rather do it from your own client.
The conversational builder
The meta agent is called the Agnt Wizard. The things it builds are called Agents. Keeping the two apart matters once you have several: you are always either talking to the Wizard about an agent, or talking to the agent itself.
Opening the Wizard from an agent reuses the wizard session already focused on that agent. Failing that it reuses the workspace's most recent wizard session, and failing that it starts a fresh one. You rarely start from a blank page, and a build you left yesterday is where you left it.
Every chat boots with an empty draft container, so the agent has a stable id and a config sidebar from the first message. Describing the job stamps that container with a name and an initial config rather than creating a second one.
A whole agent, staged for your approval
The Wizard writes the name and description, the model, the system prompt, the tool selection and a permission level on each tool, schedules and webhook triggers, Slack routes and iMessage bindings, the document collections the agent searches, and, when a mailbox is connected, email triage rules including where a thread escalates.
Edits to an agent that is already deployed are staged, not applied. The Wizard proposes a change with a written rationale, the server validates the full resulting config, and the change waits as a pending proposal until you approve it. An invalid proposal comes back with a problem per path and changes nothing.
you press deploy
Everything the Wizard wrote, in one screen
The Config tab is the direct-editing surface. Edits to the agent itself — name, description, model, prompt, tools, permissions, documents — stay local until you save, and the save button only appears once something is dirty. The channel and trigger cards below it (default channel, Slack channels, iMessage, schedules, webhook triggers) are separate records and each saves on its own action.
| Panel | What it controls |
|---|---|
| Configuration | Name, description, model and system prompt. The prompt is the agent, so this is the panel that changes behaviour most. |
| Tools | The picker for data sources, connections, connectors, remote MCP servers and built-in utilities. One flat list is stored on the agent. |
| Documents | Which knowledge collections this agent can search. Attaching one here is what grants it the document tools. |
| Permissions | A permission level per tool. Unset tools fall through to the workspace override, then the tool's own default, then a read/write heuristic. |
| Schedules | Recurring runs the agent owns. Each fire produces a run row and a background work session. |
| Webhook triggers | Inbound endpoints that wake the agent when a third party posts to them. |
| Default channel | Where approvals and escalations go when the agent is working outside a live chat. Auto, iMessage or Slack. |
| Slack channels | One home channel, any number of mention channels, and a direct-messages toggle. |
| iMessage | Phone numbers bound to this agent through the shared agnt number. Hidden when iMessage is not configured. |
| Code execution & skills | Read-only. Shows whether sandboxed code execution is on, and lists the TypeScript skills the agent carries with their source. |
| Skills (instructions) | Read-only. Lists the SKILL.md playbooks the agent loads on demand. |
Permission levels are act, ask, always_ask. See permissions and approvals for how a level is resolved and what an approval looks like when the agent hits one.
Two kinds, both human-approved
A skill is a reusable piece of the agent that does not belong in the system prompt. There are two kinds, and they solve different problems.
TypeScript skills
Real code, run in an external sandbox rather than in the model. Each one carries its name, description, version and dependency list. Use them when the work is deterministic: a transform, a calculation, a multi-step API sequence you do not want a model improvising.
Instruction skills
SKILL.md playbooks. Only the description sits in the prompt; the full body loads when the task calls for it, so a long playbook costs nothing on every turn. Use them for procedure: how this company writes a follow-up, how to run a weekly report.
Both kinds are authored through the builder chat, and both require human approval before they are applied to the agent. The Config tab shows them read-only so you can see exactly what the agent is carrying.
Same agent, from your own terminal
Point your client at the workspace MCP endpoint and the lifecycle family is there. This is the whole connection:
claude mcp add --scope user --transport http superagnt https://mcp.superagnt.com/mcp
claude mcp login superagntTools are attached by reference, not by name. Search the catalog, copy each tool's config_ref object verbatim, and add it in the patch. A tool with no config_ref is always-on base (the workspace database and files, the base utilities, the control tools) and cannot be attached to an agent.
# 1. find the tools you want, and copy each config_ref verbatim
agnt_tools_search { "query": "hubspot" }
# 2. create the draft
agnt_agents_create { "name": "Pipeline scout", "model": "claude-sonnet-5" }
# 3. patch it: send only the keys you are changing
agnt_agents_update_config {
"agent_id": "<uuid>",
"patch": {
"system_prompt": { "set": "You watch the CRM for stalled deals and ..." },
"tools": { "add": [ <config_ref>, <config_ref> ] },
"permissions": { "tools": { "connection_hubspot_update_deal": "always_ask" } },
"document_collection_ids": { "add": ["<collection-id>"] }
}
}
# 4. take it live (this bills from the first session)
agnt_agents_deploy { "agent_id": "<uuid>" }these apply directly
agnt_agents_update_config takes effect on the agent's next session, and agnt_agents_deploy starts billing. Confirm with your user first.Start with the one at the center
A workspace's first agent is its superagnt: the one you talk to daily and the one other agents report through. It is named for you by default, so the prefilled name is <first name>'s superagnt, or the company name on a shared team agent. It is only a default and always editable.
- 01
Describe the job, not the tools
Say what the agent is for and who it answers to. The Wizard picks the tools and asks for whatever credential is missing with an inline Connect card. - 02
Read the prompt it wrote
The system prompt is the agent. Skim it before deploying; editing one paragraph there beats adding three tools. - 03
Give it one door
An agent nobody can reach does nothing. Put it in a Slack channel or bind a phone number before you go looking for more capability. See channels. - 04
Deploy, then probe it
Send it one real task and read the session. The inspector shows the tool calls, so a wrong answer usually points at a missing tool or a permission level rather than the prompt. See sessions and observability.