Every command center has a small team of agents — a router that picks the right specialist for each turn, a generalist that handles open-ended work, and a visualization specialist for chart-heavy answers. You can install skills, attach external MCP servers, and define autonomous agents that run on triggers. The Agents tab is where you configure all of it.
The five sub-tabs
The Agents tab is divided into five pages, each with its own URL so you can deep-link or bookmark:
- Chat — the chat-routing configuration. Lists the router and the chat agents it can hand a turn to (the shipped generalist, the visualization specialist, plus any custom agents you’ve added). This is where you tune the surface that answers the live chat panel.
- Skills — the skill catalog and per-agent allow-list. Lets you scope which skills apply to which agents. See Skills.
- Memories — the long-term notes the agent carries across every session on this command center. Editor-gated, audit-logged, and editable in place: add the things the agent should always know about this dashboard, remove things that no longer apply. The agent treats these entries as facts about the operation, not as instructions about how to behave.
- MCP — external MCP servers attached to this dashboard’s chat. The server URLs you paste here merge their tools into the agents’ available toolset at the start of every chat turn.
- Autonomous — trigger-driven agents that run on a schedule or in response to data changes. These never appear in chat; they execute on their own clock, propose actions, or write back to the dashboard. Each carries its own boundary, budget envelope, and autonomy tier. The governed execution policy — which action types are allowed, who can approve them, how many can fire per hour — is configured from this sub-tab.
How chat routing works
When you send a message in chat, it first hits a small, fast router. The router reads short pitches from every available chat agent on the dashboard and hands your turn to the one best suited to answer. The router itself has no tools — its only job is choosing the right specialist.
Two chat agents ship by default on every dashboard:
- Delphi — the heavy generalist. Reads connectors and datasets, writes KPIs and visualizations, queries documents, proposes scenarios, drafts reports, takes governed actions. The router defaults here for any open-ended turn that needs reasoning across multiple data sources.
- Layout — a visualization specialist. Read-only, narrow toolset, emits inline charts, KPI cards, and dashboard-style views directly in chat. The router hands off here when you ask for a chart, a card, or a structured visual answer.
You can add your own chat agents — finance specialists, compliance reviewers, support deflection agents — by writing a short pitch (a one-to-three-sentence description of when the router should reach for it). Each agent carries its own:
- System prompt — voice, domain framing, methodology. The shipped agents are kept current with each release; custom agents store their prompt with the dashboard.
- Tool allow-list — exact list of tools the agent may call, or a blanket “use everything available” permission.
- Capabilities — emit visualization envelopes, ground answers with live web search, run code, accept images. Capabilities gate which behaviors are available for the turn.
- Allowed thinking levels — Minimal, Low, Medium, or High reasoning depth. The user can pick from the levels you allow; a default fires when they don’t.
- Skills allow-list — which skills the agent can reach for. None, all, or a curated list.
- Knowledge sources — which vector stores the agent can query. All by default; restrict to a specific list when you want a Support agent inside the FAQ store and out of internal HR material.
- Daily token budget — a hard cap on total tokens the agent may consume in a single day. When today’s usage meets the limit, the next call is rejected before the model fires.
- Minimum role — the minimum role a user needs for the router to offer this agent. Defaults to viewer.
- Public chat — a per-agent toggle that opts the 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; the rest stay authenticated-only.
- Retry policy — when enabled, transient model errors trigger automatic retries with exponential backoff.
- Model tier — the underlying model is picked from the registry (Gemini, Claude, Llama, Mistral, plus tenant-hosted), with a region selected from the model’s supported list.
The default platform agents are sensible out of the box; you reach for the editor when you’re tightening posture for a sensitive command center, broadening it for an experimental one, or adding a custom agent for a specific workflow.
Skills
Skills are markdown-based capability packs that activate per turn. Each one teaches the model a methodology, a runbook, or a domain vocabulary — domain knowledge that would be too big to live in every base prompt, but pays off when the model needs it.
See Skills for the catalog, where skills come from, and the installation flow.
Autonomous agents
Trigger-driven agents — the one that runs every morning to summarize the overnight queue, the one that watches the alerts feed and proposes a ticket when something fires — live on the Autonomous sub-tab. They never appear in chat. They have the same boundary model as chat agents: capabilities, budget envelope, temporal policy (cooldown, max activations per window), mutation scope (which resources they’re allowed to change, and how), and autonomy tier (observe, propose, or execute).
The critical rule: a child agent can never escalate beyond its parent’s tier. If you set the root to observe, none of its children can execute, even if you ask them to. See governed actions for the approval workflow that propose-tier agents feed into, and child agents for delegation mechanics.
External MCP servers
The MCP sub-tab is where you attach external MCP servers to this dashboard’s chat. 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 agents’ available toolset. Each dashboard maintains its own list — a finance command center can connect to different tools than an operations command center in the same organization.
See Connect external MCP servers for URL validation and request-safety details.
Sessions from external agents
If you’ve exposed this command center as its own MCP server — letting external agents like Claude Desktop, ChatGPT, Cursor, or in-house stacks query its data — you’ll see the authenticated sessions on the Chat sub-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.
Run history
Every agent execution writes a ledger entry — start, tool calls, transfers, delegations, budget usage, final status. The Chat and Autonomous sub-tabs both surface the most recent runs alongside a short summary of what each 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 add a chat agent vs. an autonomous agent vs. a child
Three patterns, three different surfaces:
- Chat agent — when a recurring shape of human conversation deserves a dedicated specialist. A Finance Analyst that the router hands turns to whenever someone asks about pipeline, forecasting, or budget. Lives on the Chat sub-tab.
- Autonomous agent — when work should happen without a human in the loop. The morning summary, the alert triage, the scheduled report. Lives on the Autonomous sub-tab.
- Child agent — when an agent (chat or autonomous) needs to delegate a focused sub-task with a tighter boundary than the parent. See child agents.
For configuring the root agent’s behavior from chat, see Chatting with Delphi. For the approval workflow that propose-tier agents feed into, see governed actions.