supr_agnt. From your side, it’s just the chat you land in at /dashboard/chat.
Two contexts
| Context | Where | What runs |
|---|---|---|
| Builder context | /dashboard/chat and /dashboard/sub-agents/:id/chat | supr_agnt with the full meta-agent toolset described below. Stages changes; never edits agents directly without approval. |
| Runtime context | A deployed agent’s session | The agent you built, with whatever tools you picked. Runs on Anthropic’s managed runtime; the Builder doesn’t run here. |
agnt_db_* if you enabled the workspace DB) that the Builder doesn’t expose to itself.
Starting a session
Open the dashboard. The Builder is the default chat at/dashboard/chat. New session per agent or topic is fine — long-term memory pulls in the relevant context regardless of which session you’re in.
For a specific deployed agent, open the agent and switch to its Build tab. The Builder picks up where you left off on that agent and proposes patches against its current config.
What the Builder can do
The Builder’s toolset breaks into seven families. You don’t have to know these names — the Builder picks them — but it helps to know what’s reachable.Workspace memory
read_workspace_profile/update_workspace_profile— a freeform Markdown blob (WORKSPACE.md) the Builder maintains about your team, products, and conventions.enrich_workspace_profile_from_website— fetches your company website and writes a tailored profile (runs blocking for 10–30s during onboarding).recall_memory/remember— pgvector-backed long-term memory for design decisions, preferences, and rationale. Pulled into every new turn.
Discovery
get_workflow_guidance— semantic search over a curated library of agent design patterns and best practices.list_agent_capabilities— the catalog of tools the agent could use (data APIs, connectors, integrations, utilities, remote MCP).search_available_integrations— surfaces unconnected providers when the Builder wants to suggest one.list_workspace_integrations— what’s already connected.list_workspace_agents/get_agent— read existing agents in the workspace.
Live agent observability
These are read-only and let the Builder explain or debug what a deployed agent has been doing.list_live_agent_sessions,read_live_agent_session,search_live_agent_sessions— sessions and event history.get_live_agent_diagnostics— compact health report (deploy/runtime ids, dependency checks, recent sessions, escalations).list_agent_trigger_runs— schedule/webhook fire audit.get_agent_session_usage— per-session token and runtime cost.list_agent_escalations— human-in-the-loop audit.check_agent_runtime_dependencies— verify the agent’s prerequisites are still met.read_runtime_config_request— read pending config-change requests filed by a deployed agent at runtime.
Sub-agent delegation
For testing and “agent runs another agent” workflows:start_sub_agnt_session,send_message_to_sub_agnt_session,poll_sub_agnt_session— drive a deployed agent from inside the Builder.
Attachments
When you drop a file into the Builder chat:read_attachment— slice text/CSV by lines or bytes.csv_inspect,csv_query— type-aware CSV exploration.grep_attachment— regex/substring search.
Agent lifecycle
These tools stage changes — they don’t apply them until you approve:draft_agent— create or fill out a draft agent.propose_agent_patch— stage a delta against a deployed agent’s config (preferred — diff-only).propose_agent_changes— full-replacement config (used sparingly, for rewrites).request_connection— surface an inline OAuth / API-key card so you can connect Slack, Stripe, etc. without leaving the chat.request_deploy— surface a one-click Deploy card.enable_agent_memory/disable_agent_memory— atomically install / remove the per-agent memory pgvector setup and add/remove thememory_*tools.set_focus— switch the chat between build / chat / edit modes for a sub-agent.
Triggers and routing
For wiring an agent into the world:list_agent_schedules,create_agent_schedule,update_agent_schedule,delete_agent_schedule— cron schedules (writes directly; no approval gate because schedules are easy to undo).list_webhook_endpoints,create_webhook_endpoint,create_outbound_webhook,rotate_webhook_signing_secret,link_webhook_to_agent,link_webhook_to_data_job— inbound + outbound webhook management. An inbound endpoint binds to an agent (fan out a session per delivery) or a data job (enqueue one pipeline item per delivery), not both.list_slack_channel_routes,create_slack_channel_route,update_slack_channel_route,delete_slack_channel_route— which channel/DM routes to which agent.
Workspace database (DDL + CRUD)
When you ask the Builder to set up tables for your agent, it uses the sameagnt_db_* MCP tools the deployed agent will use at runtime. See Workspace database.
Proposals
Most config changes are staged. When the Builder wants to edit a deployed agent’s system prompt, tool list, or model, it callspropose_agent_patch and a side panel opens with a diff and Approve / Reject buttons.
Approving:
- Applies the diff to
deployed_agents.config. - If the agent is already deployed, re-syncs the Anthropic registration so the next conversation picks up the changes immediately.
- Closes the proposal as
accepted.
rejected and the Builder doesn’t try to apply the same change again unless you specifically ask it to.
Approval mode
Some live tool calls (e.g. sending a real Slack message during a test) can be gated behind a per-call approval. The Builder writes ameta_agent_pending_tool_call_approvals row and pauses; you confirm or cancel from the same chat. This is the inline equivalent of the always_ask rule for deployed agents.
Memory
Two things persist across Builder sessions:workspace_profile— a freeform Markdown blob the Builder updates as it learns about your team, products, and preferences.memories— discrete embeddings of design decisions, user preferences, and rationale. The Builder retrieves the most relevant ones at the start of each turn so it doesn’t ask you the same question twice.
Onboarding adaptations
The Builder reads yourexperience_level (set during onboarding) and adapts its opening behavior:
beginner— leads with two or three concrete starter agents tailored to the use case you described.experienced— leads with capability discovery, asks which platform you build on, and hands you a quickstart map.
Next steps
Tools
The deployed-agent tool registry.
Triggers
Schedule and webhook your agents.
Permissions
always_ask and the escalation inbox.Beginner mode
How the Builder adapts for new users.