Orchestrator AI Employees
An Orchestrator AI Employee coordinates other AI Employees, knowledge bases, and tools to handle multi-step requests. A person chats with the orchestrator, the orchestrator works out what needs to happen, and it either answers directly or hands each step to the right AI Employee and brings the results back into one conversation.
Chat, Dashboard, and Voice AI Employees are defined by a workflow you wire together in the AI Employee builder. An orchestrator has no workflow. You configure it on its Configuration tab with plain-language Instructions and a set of switches, then publish.
Orchestrator is an interaction type. You choose it in the create dialog, the same way you choose Chat or Dashboard. Once created, the type cannot be changed. See AI Employee Types.
When to use an orchestrator
Use an orchestrator when a single request needs more than one AI Employee, or when you want one front door in front of several specialists:
- One assistant, many specialists. An "Employee Help" orchestrator connected to a PTO assistant, an IT helpdesk, and a policy assistant. People ask one place; the orchestrator routes.
- Multi-step tasks. A request that needs a lookup in one system, a check against policy, and a document at the end. The orchestrator sequences the steps across the AI Employees that own each one.
- An AI Employee that builds or manages other AI Employees. With management abilities turned on, an orchestrator can create and edit AI Employees, knowledge bases, and integrations from a conversation.
Use a Chat AI Employee instead when one workflow can do the whole job. A workflow gives you exact control over each step; an orchestrator trades some of that control for flexibility across many AI Employees.
What you configure
Everything an orchestrator does comes from the settings on its Configuration tab. The builder guide walks through each one; here is what they mean.
| Setting | What it controls |
|---|---|
| Instructions | Who the orchestrator is and how it should help: its role, tone, when to answer itself, and when to hand work to a connected AI Employee. Markdown is supported. |
| Skills | Reusable know-how you upload as Markdown files, such as a step-by-step process for scheduling interviews. The orchestrator draws on a skill automatically when it is relevant. |
| Knowledge bases | Documents the orchestrator can search when answering on its own. Attached and managed the same way as on any other AI Employee. |
| Connected AI Employees | Which AI Employees the orchestrator may delegate to: a specific list, or every AI Employee in your workspace. |
| Built-in tools | General abilities you can turn on or off: creating files, web access, memory across chats, and interactive widgets in replies. |
| Management abilities | Whether the orchestrator may build and edit AI Employees, manage knowledge bases, or manage integrations. All off by default. |
| Sub-agents | Whether it can split a large request into parts and work on them in parallel. |
| Limits | How many chats one person can have running with this orchestrator at the same time. |
What happens in a conversation
When someone sends a message, the orchestrator reads its Instructions, its skills, and the conversation so far, then decides how to respond. In a single turn it may:
- Answer directly, searching its knowledge bases when it needs facts.
- Delegate to a connected AI Employee. It sends the sub-task to that AI Employee, waits for the result, and folds it into its reply. A connected AI Employee can be a Chat or Dashboard AI Employee, or another orchestrator, so you can build layered teams: an orchestrator that manages specialists, each of which manages its own helpers. Voice AI Employees cannot be connected yet; support is planned for a future release.
- Work in parallel when Sub-agents is on and a request breaks into independent pieces.
- Ask the person a question when it needs a decision or missing information. Where there is a clear choice, the options appear as buttons in the chat.
- Ask the person to connect an integration when a step needs a login the person has not completed yet. The connection prompt appears in the conversation, and the task continues once the connection is made.
The orchestrator only uses AI Employees that are connected to it and published. If a connected AI Employee is still a draft, the orchestrator cannot use it until it is published.
What people see
Replies stream into the chat as the orchestrator works, including a running account of which AI Employees it handed work to and what came back. Builders can switch the transcript between a Narrative view, which reads like a summary, and a Developer view, which shows every individual step. The switch is in the menu at the top of the AI Employee's page.
Each time an orchestrator delegates to a Chat or Dashboard AI Employee, that AI Employee records a normal run marked Triggered by the orchestrator, so you can trace the work from either side.
Drafts, publishing, and versions
Changes on the Configuration tab are saved to a draft. Nothing changes for people chatting with the orchestrator until you publish. Each publish creates a numbered version you can see in Version history, and you can restore any earlier version into your draft, review it, and publish it again.
The enable switch in the page header works a little differently for orchestrators. Turning it off stops new chats from starting; turning it back on makes the last published version live again. You do not need to republish to re-enable.
See Versioning for how drafts and versions work across the platform.
Where an orchestrator is available
People chat with an orchestrator from its Chat tab in the AI Employee builder and from the platform's chat surface, subject to the AI Employee's permissions. Each person can run several chats with the same orchestrator at once, up to the limit you set.
Orchestrators and Autopilot
Autopilot, the assistant built into the platform, works with orchestrators in two directions.
- Autopilot can build an orchestrator. Describe what it should do and which AI Employees it should use, and Autopilot proposes a configuration, creates the orchestrator, and publishes it once you approve.
- Autopilot can hand work to an orchestrator. Once an orchestrator is published, Autopilot can run tasks against it and test it for you, the same way an orchestrator delegates to its connected AI Employees. Think of a published orchestrator as a specialist that Autopilot can hand a task to and get a result back from.
A published orchestrator runs on its own configuration. Workspace-level Autopilot settings, such as workspace Instructions and workspace skills, apply only to the default Autopilot and have no effect on orchestrators you build.
Groups
If you create an orchestrator inside a group, it belongs to that group and can only connect to AI Employees and knowledge bases the group owns, including any it creates itself. Ownership is set at creation and cannot be moved later. See Groups.
Best practices
- One orchestrator per group. If your workspace uses groups, give each group its own orchestrator instead of one shared front door. A group's orchestrator can only reach the AI Employees and knowledge bases that group owns, so its choices stay within the group's remit. With the Memory built-in tool on, it also keeps what it learns from the group's chats, so over time it gets better at deciding which of that group's AI Employees to use and how. Those learnings stay with that orchestrator and do not carry over to other groups.
- Publish connected AI Employees first. An orchestrator cannot delegate to a draft. Publish the specialists, then connect them.
- Start narrow. Connect the two or three AI Employees the orchestrator needs most, get the routing right, then add more. Every connected AI Employee is one more choice the orchestrator makes on each request.
- Name AI Employees in the Instructions. Say which kinds of requests each connected AI Employee owns and what to do when a request fits nowhere. Most routing problems are fixed here, not in the settings.
- Keep management abilities off for end-user orchestrators. Turn them on only for an orchestrator whose job is to build or administer things, and pair them with a tight permissions list.
- Test across areas. Try at least one request that spans two connected AI Employees to confirm the orchestrator splits and recombines the work the way you expect. To test many requests at once, evaluate the orchestrator against a test dataset.
Where to go next
- Creating an Orchestrator AI Employee, the step-by-step guide.
- Evaluating Orchestrator AI Employees, to test an orchestrator against dozens of simulated conversations and see where it goes wrong.
- AI Employee Types, to compare orchestrators with Chat, Dashboard, and Voice.
- Autopilot, to have one built for you or to hand tasks to one you have published.