Multi-agent orchestration: one app, many specialised agents

Multi-agent orchestration means one entry point decides which specialised agent handles a request, passes it the conversation and the user's context, and returns a single answer. It replaces one over-loaded prompt with several focused agents, each with its own tools, knowledge and instructions, coordinated by an explicit control flow.

The hard part is not calling several models. It is keeping the hand-off visible: which agent was chosen and why, what it received, what it did with its tools, and what left the app. Orchestration that hides those steps is where production debugging goes to die.

An app attaches agents. With one agent every message goes to it. With several, the app graph runs a router that selects the agent for each message from the agents' descriptions and roles. The selected agent's published workflow then runs as a nested run.

The app's output gate streams only the selected agent's final answer to the user, and a final safety check applies the app's own guardrails after the agent's, so an app can be stricter than its agents. Nested runs are recorded with the same detail as the parent: steps, generations, tool calls, retrievals and cost.

Yes. The agent tool type calls another agent as a tool from inside a workflow, which lets a coordinator delegate a sub-task and use the result. Apps route between agents at the top level; agent tools compose them inside a run.

Through the embeddable chat widget, a single script that connects a launcher on your site to the app, or through the end-user API from your own frontend or backend. The app's auth context policy decides whether visitors may chat anonymously or must be identified with a signed identity token your backend issues, and which user fields agents may see.

Apps and end users run only published agent graphs. Drafts stay in the builder's test chat until you publish, and publishing an agent an app uses takes effect on the next end-user message.