Every command center has a root Delphi agent — the agent that answers the chat panel, proposes actions, and serves as the parent of any specialists you spin up later. The Agents tab is where you configure that agent and see what it’s been doing. Delegation to child specialists is covered separately in Child agents and delegation; this page is about the root.
Why the Agents tab is its own surface
Chat is where you work with Delphi — ask questions, get answers, build things. The Agents tab is where you work on Delphi — shape the agent’s behavior, define what it’s allowed to touch, and review its operating history. Most day-to-day work never opens the Agents tab at all. You reach for it when you want to change the agent’s personality, tighten its boundary, attach a new tool source, or audit a run after the fact.
The root Delphi agent
Each command center’s root agent carries:
- A system prompt that shapes tone, approach, and domain framing. The default is a general-purpose Delphi prompt tuned to the dashboard’s stated problem and domain model; you can override it when you want the agent to lean into a specific voice or methodology.
- A set of capabilities drawn from the shipped capability list — reading data, writing data, managing alerts, creating child agents, calling external APIs, executing code, sending notifications, and using custom model endpoints. Capabilities are the most explicit form of “what the agent is allowed to do.” Turning one off removes the corresponding tools from the agent so they cannot be called.
- A budget envelope — max tokens per execution, max tokens per hour, max delegations per execution, max tool calls per execution, and max concurrent executions. These aren’t guidelines; they’re hard ceilings enforced before the agent runs, so a misbehaving or runaway agent can’t drain its budget.
- A temporal policy — max execution duration, cooldown between runs, max activations per rolling window. This is how you say “this agent can run at most four times an hour, with at least a minute between runs, and never for more than 90 seconds at a stretch.”
- A mutation scope — a list of resource path patterns with allowed operations (
create,update,delete). The agent can only modify resources whose paths match an entry in this list. If you want an agent that can only update alerts but never touch connectors, this is where you enforce it. - An autonomy tier —
observe,propose, orexecute. See governed actions for what each tier allows and why the root’s tier is the ceiling for the whole subtree. - Model tiers — a
low/medium/highmapping that lets the agent pick a cheaper model for simple tasks and a more capable one for complex reasoning, all configurable per dashboard. The dropdown spans Google’s Gemini family, Anthropic’s Claude family, Meta’s Llama family, and Mistral, plus any tenant-hosted models your operator has wired up — pick whichever combination of cost, latency, and capability fits the work. - Public chat — a per-agent toggle that opts that agent into the public chat surface. When the dashboard is published as a public dashboard, agents with public chat on appear in the unauthenticated Q&A; everything else stays authenticated-only. The toggle is independent per agent so you can expose a Q&A specialist to anonymous visitors while keeping the root agent and its mutating capabilities reserved for signed-in users.
Most of these defaults are sensible out of the box. You edit them when you’re tightening posture for a sensitive command center, loosening it for an experimental one, or adapting the root to a domain that needs a different voice.
Attaching MCP servers
The Agents tab is also where you attach external MCP servers to the root agent. Paste a server URL, give it a short name, and Delphi loads its tool catalog at the start of every chat turn and merges those tools into the agent’s available toolset. Each dashboard maintains its own MCP server list — your finance command center can connect to different tools than your operations command center on the same tenant.
See Connect external MCP servers for the full mechanics, URL validation, and request-safety story.
Sessions from external agents
If you’ve exposed this command center as its own MCP server to let external agents (Claude Desktop, ChatGPT, Cursor, in-house stacks) query its data, you’ll see the authenticated OAuth2 sessions on the Agents tab grouped by user. Each entry shows the client, the authorizing user, when it last made a request, and a revoke button. Cutting off an external agent is a one-click operation; the next request from that session fails immediately.
Recent runs
Every agent execution writes ledger events — start, tool calls, delegations to children, budget usage, final status. The Agents tab surfaces the most recent runs alongside a short summary of what the agent did and how long it took. If a run failed, the error and the budget state at failure time are both visible. If a child agent tripped its circuit breaker after too many consecutive errors, the tab makes that visible so you can intervene before it silently falls off the rails.
When to create a child
Reach for a child agent when a recurring, narrow, well-defined task deserves its own persona and a tighter boundary than the root. The root stays general-purpose; specialists handle the deep work. The Agents tab is where you kick off that flow — describe what you want, the root clamps the child’s boundary to fit within its own, and the new specialist shows up in the hierarchy view next to its parent.
The critical rule: a child can never escalate beyond its parent’s tier. If the root is set to observe, none of its children can execute, even if you ask them to. This keeps the safety posture of your whole agent tree anchored to the topmost decision you made about the root.