Skip to main content

Agent Delegates

An agent doesn't have to do everything on its own. With agent delegates, one agent can call other agents as tools and hand off sub-tasks to them. The calling agent is the supervisor; the called agents are specialists (delegates). This lets agents work together like a team of one coordinating lead and several focused experts.

When the supervisor's language model decides it needs a specialist, it calls it synchronously: the specialist runs, returns its answer, and the supervisor continues the conversation with that result. For the user it stays a single conversation with the supervisor — the delegation happens in the background and appears in the thread as an expandable, nested call.

Principle: shared workspace, own brain

A specialist runs in a sub-thread inside the same project as the supervisor. From that follows the guiding principle of delegation:

  • Shared workspace — the specialist sees the same workspace files as the supervisor. It can read what the supervisor produced and write its own results back as files. This is what makes handing intermediate results between agents possible.
  • Own brain — the specialist uses its own knowledge and its own tools, not the supervisor's. A "legal specialist" answers from its legal corpus, not from a blurred mix of the whole project's knowledge.

This separation is the heart of the idea: you combine one broad, coordinating agent with several focused specialists without mixing their knowledge bases.

Wiring up delegates

Delegates are wired in the agent editor (admin area at /admin/agents, see Configuring agents).

  1. Open the agent that should act as the supervisor. In the Agent Delegates section you see the specialists already linked to it.
  2. Click Add Delegate and pick a specialist agent from the list. (The agent itself and already-linked agents don't appear in the picker.)
  3. Under When to use this agent, provide a description. It is pre-filled with the specialist's own description, but you should set it deliberately — see below.

A delegate is not a separate configuration field; it appears as an entry among the supervisor's tools. Any agent can be a supervisor and a specialist at the same time.

The description drives the routing

The supervisor decides whether and when to call a specialist based solely on the When to use this agent description. That makes it the single most important piece of delegation configuration — treat it like a task brief for an expert.

Write it concretely and with clear boundaries:

For all questions about labor law, notice periods, parental leave and collective agreements. Not for general HR questions like leave requests.

Vague descriptions ("Helps with various topics") lead the supervisor to call the specialist too rarely or at the wrong moment.

Safety and limits

  • Identity — a specialist runs under the identity of the calling user and is subject to the same access control. A supervisor cannot grant users access to agents or data they could not otherwise reach. An administrator must explicitly wire in each specialist.
  • Cycle detection — if a delegation chain calls an agent that is already in the chain (A → B → A), the call is rejected. This holds across multiple hops too.
  • Depth limit — delegation chains are capped at five levels to bound cost and runtime.
  • Cost — every delegation is an additional model run. Nested delegation multiplies token usage; the nested calls are visible in the thread, so cost stays traceable.

Example use cases

Support desk with subject-matter experts

A supervisor Customer Service takes every request and routes it to the right specialist:

  • Billing specialist — own knowledge: price lists, invoice and contract documents.
  • Technical specialist — own knowledge: product documentation; own tools to check system status.
  • Onboarding specialist — own knowledge: getting-started and setup guides.

Why it works: each specialist answers only from its own corpus. The customer still asks one question to one point of contact, but gets precise expert answers without blended knowledge.

Research and reporting team

A supervisor Report Coordinator (with workspace files enabled) produces a report together with two specialists:

  • Web researcher — has web tools, researches, and drops the findings as files into the shared workspace.
  • Data analyst — reads those files, analyses them, and writes a summary with a table back into the workspace.

The coordinator assembles the finished report from the intermediate results.

Why it works: this uses the shared workspace as the hand-off point — one agent produces files, the next builds on them.

Citizen services for a public administration

A supervisor Citizen Services answers general enquiries itself and delegates domain-specific questions to the responsible office:

  • Building office specialist — own knowledge: building regulations, application procedures.
  • Registration office specialist — own knowledge: residence and ID matters.
  • Waste specialist — own knowledge: collection dates, separation rules.

Why it works: citizens need only a single entry point, while each department keeps its own curated knowledge base.

A supervisor HR Assistant answers everyday personnel questions from its own knowledge and delegates only tricky labor-law questions to a labor-law specialist with its own legal corpus.

Why it works: the broad everyday agent stays fast and simple; the specialized expertise is only pulled in when it is genuinely needed.

With delegation, the collaboration happens in the background of a single agent conversation. When you instead want a visible multi-participant conversation where users address several agents and see them answer under their own names, use team chat.