What exactly does the Agent Orchestrator do?

taki

I would like to better understand the role of the Agent Orchestrator in Board AI Agents.

The documentation states that the Agent Orchestrator:

“manages context, routes requests to the right Agent, and ensures consistent handling of multi-step tasks.”

However, I am having difficulty reconciling this explanation with the actual configuration process.

When configuring an AI Agent in Board, the developer:

Creates or selects a specific type of Agent, such as the FP&A Agent or Controller Agent
Associates the Agent with a Dataset
Applies the configured Agent to a specific Screen

Therefore, it appears that the developer has already determined which Agent will be used before the user submits a request.

Could someone clarify what “routes requests to the right Agent” means in this context?

Specifically:

Does the Agent Orchestrator route requests only within the Agent already assigned to the Screen?
Can it call another Agent type that is not assigned to the current Screen?
If an FP&A Agent is assigned to a Screen, can the Orchestrator automatically involve the Controller Agent when required?
Is the Agent Orchestrator a separate Agent that developers must configure, or is it an underlying component that operates automatically behind all AI Agents?
What is the difference between selecting an Agent during development and routing a request at runtime?

I would appreciate any technical documentation or a concrete example showing how the Orchestrator works at runtime.

Robert Barkaway

Hi Taki, apologies for the delayed reply to this, I spoke to our AI Product team and below is the explanation they've given, if you have any further questions let me know and I can pass them on.

Kind Regards,

Rob

********************************

"Let me clarify how the Agent Orchestrator works, separating what happens when you configure the Agent from what happens at runtime, and being explicit about what ships today versus what is on the roadmap.

1. Agent configuration and runtime are two different jobs.

When you configure an Agent (selecting the type, associating a Dataset, applying it to a Screen), you are defining which Agent owns that Screen, the data it works on, and its governance boundary. This answers "which Agent is in charge of this Screen."

Runtime is a different moment: once the user submits a request, the system has to handle it and each of its steps. That is where the Agent Orchestrator operates.

2. What "routing" means in the current release.

Today the Agent Orchestrator is scoped to the single Agent you configured on the Screen. It does not pick between Agent types at runtime. Within that one Agent it maintains conversation and task context, decomposes multi-step requests, and sequences the steps so a multi-part task is handled consistently. So in the current release "routing" means orchestrating the steps of a request inside the configured Agent, not selecting among different Agents.

3. Can it call an Agent type not assigned to the Screen (e.g. Controller from an FP&A screen)?

Not in the current release. The orchestrator is locked to one Agent at a time, the one configured on the Screen. Automatic cross-domain delegation, for example an FP&A screen involving the Controller Agent when needed, is on the roadmap: it will be unlocked in a future release to enable interoperability across Agents of different domains. It is not available today.

4. Is the Agent Orchestrator something the developer configures, or an underlying component?

An underlying runtime component. You do not configure the Agent Orchestrator. What you configure is the Agent itself (type, Dataset, Screen); the Orchestrator operates automatically behind every AI Agent to manage context and handle the request.

5. Concrete runtime example (current release).

On an FP&A screen the user asks: "explain the EMEA revenue variance for Q3 and propose a Q4 re-forecast." The Agent Orchestrator receives the request and holds the context (cube, version, scenario, screen scope). It passes that request together with the context to the FP&A Agent configured on the Screen, which executes the analysis and produces the re-forecast proposal, returned with its proposed / in review / approved state. The Orchestrator manages the request and the context, the FP&A Agent does the domain work. Everything stays within the FP&A Agent, because that is the Agent configured on the Screen.

Once cross-domain interoperability ships, the same mechanism would let the Orchestrator route parts of the request to another Agent, for example the Controller Agent for an intercompany check. That is future, not current behavior."