Skip to content

Beyond one model

A live call can hand work to Claude.

The voice runs on Gemini because it has to. Longer, multi-step work can be delegated to an Orchestrator running on whichever model you prefer, and the answer comes back in the agent voice.

How it works

What the capability actually does.

Any model, through one field

An Orchestrator takes a bare Gemini name or a provider and model string. Anthropic, OpenAI, a model you host with Ollama, or any of a hundred others, with no provider-specific integration code.

Real multi-step work

Where an agent-to-agent handoff is a single question and answer, an Orchestrator carries out a job using its own tools and can call further Orchestrators beneath it.

Start from a working example

Three built-in templates, adapted from Google’s own ADK samples, each a top-level Orchestrator with two sub-Orchestrators already linked and tooled. A slug and a name is all it takes to instantiate one.

A human can hold the door

Sending an email or a WhatsApp message can be switched to require approval per Orchestrator. A gated call is recorded as a pending request rather than run on the spot, the run finishes on its own budget, and approving it replays the exact action that was deferred.

Loops are impossible, not merely caught

An Orchestrator structurally cannot call back into the agent layer, enforced by an automated test rather than a comment. Cycles between Orchestrators are rejected when you save and again when the graph is built.

In the product

The screens this happens on.

The Orchestrators list showing each one with its model and its sub-orchestrator links

Each one picks its own model

Each Orchestrator names the model it runs on, independently of the voice layer and of every other Orchestrator. One can call another beneath it, and the resulting graph is checked for cycles when you save and again when it is built, so a loop is refused rather than discovered at runtime.

  • Anthropic, OpenAI, a model you host, or any of a hundred others
  • Off unless the deployment opts in
Orchestrator tools with Google grounding options, several badged as Gemini only

Gemini-only tools are marked, not hidden

The tools an Orchestrator may use, with the Gemini-only ones badged and disabled when a different model is selected, rather than left enabled to fail at the moment they are called. Sending email or a WhatsApp message can be switched to require human approval, which turns the call into a pending request instead of an action.

  • Google grounding, search, and code execution are Gemini-only
  • The approval gate is off unless you turn it on
Boundaries

What it deliberately does not do.

Stated here rather than discovered in production. Every one of these is a real constraint, and knowing them before you buy is worth more than a longer feature list.
  • Off by default. A deployment that does not enable it never even imports the dependency.
  • ADK built-in tools such as web search and code execution work only on Gemini models. The dashboard marks them and disables them when a different model is selected.
  • Orchestrators do not run arbitrary customer code, and take no custom function tools by design. If your own logic needs to be involved, the answer is an MCP connection, so what runs stays explicit.
  • The approval gate covers email and WhatsApp, and is off unless you turn it on.
Elsewhere

The rest of the platform.

See what it costsCompare it