One agent cannot do everything well. A generalist that handles pipeline ingestion, financial forecasting, incident response, and board reporting will always be mediocre at each. Delphi solves this by letting you build a team of specialist agents under one root, each with its own focus, tools, and guardrails — so the root agent stays in charge while the specialists do the deep work.
Why a child agent
Use a child agent when a task is recurring, narrow, and benefits from a dedicated persona or a tighter toolset. A “Revenue Analyst” child that only touches finance datasets will produce sharper answers than the root juggling every domain at once. Child agents are also how you scope blast radius — a specialist only sees the tools and datasets you grant it, so it physically cannot wander into systems it shouldn’t.
Stay with the root agent for one-off questions, cross-domain investigations, or anything exploratory. Reach for a child when you find yourself asking the same shape of question over and over, or when you want to hand a piece of work to an agent with a stricter boundary.
Define a child
You define children by chatting with the root agent. Describe the specialist you want, what it should be responsible for, and what it needs access to. The root agent will clamp the child’s boundary to fit within its own — a child can never be granted capabilities, tools, or data access the parent doesn’t already have.
Create a child agent called “Revenue Analyst” that owns weekly pipeline health and forecast accuracy. Give it read access to the Salesforce and billing datasets, let it run queries and draft reports, but it should not send any outbound messages.
Every child has a clear responsibility statement, a system prompt that shapes its tone and approach, and a complexity level that determines how much reasoning horsepower it gets. Define children at the edges of your work — one per domain, one per audience, or one per recurring workflow.
Autonomy tiers
Every agent in Delphi runs at one of three autonomy tiers. Observe agents can read and analyze, but never propose or execute anything. Propose agents can draft action proposals — tickets, emails, notifications — that wait for a human approver before anything happens. Execute agents can carry out actions directly when an execution policy permits it.
The critical rule: a child can never escalate beyond its parent’s tier. If the root is set to propose, 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, and makes it safe to experiment with specialists without worrying they’ll go rogue.
Delegate a task
Once a child exists, hand work to it in chat. You can talk to the root and ask it to delegate, or you can reference the child by name directly. Delegation runs the child in a fresh session with only its own tools and boundary — the parent gets the result back and can fold it into the wider conversation.
Delegate this to the Revenue Analyst: pull last week’s closed-won deals, compare to forecast, and tell me which segments drifted by more than 10%.
Each delegation is recorded with a full execution trail so you can see what the child did, how long it took, and whether it succeeded. If a child keeps failing it trips a circuit breaker and stops accepting new work until it recovers — a specialist that’s broken shouldn’t quietly burn budget.
Inspect the hierarchy
Ask the root agent to show you the tree whenever you want to see what specialists exist, what each one is allowed to touch, and how recent runs have gone. The hierarchy view surfaces each child’s responsibility, current status, boundary, and recent execution summaries — useful for auditing before a sensitive workflow, and for pruning children that have drifted from their original purpose.
For the basics of talking to agents in the first place, see the chat guide. For the approval workflow that propose-tier children feed into, see governed actions.