> ## Documentation Index > Fetch the complete documentation index at: https://agnt.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # The Builder > A self-hosted meta-agent that designs and deploys Claude agents through conversation. The Builder is a Claude agent that designs other Claude agents for you. It runs on agntdata's own backend (not Anthropic's managed runtime) so it can hold long-term context across sessions, read your live workspace state, and stage configuration changes for your approval before they go live. Internally we call it `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. | The split matters because the toolsets are different. The Builder has discovery, proposal, and lifecycle tools that a deployed agent doesn't need. Deployed agents have tools (e.g. `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 the `memory_*` 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 same `agnt_db_*` MCP tools the deployed agent will use at runtime. See [Workspace database](/agents/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 calls `propose_agent_patch` and a side panel opens with a diff and **Approve** / **Reject** buttons. Approving: 1. Applies the diff to `deployed_agents.config`. 2. If the agent is already deployed, re-syncs the Anthropic registration so the next conversation picks up the changes immediately. 3. Closes the proposal as `accepted`. Rejecting marks the proposal `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 a `meta_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: 1. **`workspace_profile`** — a freeform Markdown blob the Builder updates as it learns about your team, products, and preferences. 2. **`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. Both are scoped to your workspace; nothing leaks across workspaces. ## Onboarding adaptations The Builder reads your `experience_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. Both paths use the same tools — the difference is the synthetic system message that pre-seeds the conversation. See [Beginner mode](/agents/beginner-mode) for the full split. ## Next steps The deployed-agent tool registry. Schedule and webhook your agents. `always_ask` and the escalation inbox. How the Builder adapts for new users.