Building a Meta-Agent: The Gemini 3 Orchestrator of Orchestrators

A meta-agent is a higher-order agent: an agent that operates on other agents. Just as a manager supervises employees, a meta-agent plans, inspects, forks, and rewrites the execution of worker agents. The “orchestrator of orchestrators” sits above domain orchestrators — it decomposes long-horizon objectives, delegates to specialist agents, monitors their progress, and revises the plan as results come back.

In this tutorial, you will learn the two architectures (flat mesh vs. hierarchy), the orchestrator/sub-agent split that keeps reasoning contexts compact, hierarchical tool discovery that scales prompts logarithmically, and the execution-trace primitives that make meta-agents actually programmable.

Why Flat Multi-Agent Fails

Flat multi-agent systems route natural language messages between workers and fail when coordination errors compound. Hierarchical systems keep a planning agent at the top that decomposes objectives and coordinates specialized sub-agents — consistently beating flat and monolithic baselines.

Meta-agents: higher-order agents that act on other agents, much like managers supervise employees. — SHEPHERD (https://arxiv.org/html/2605.10913)

AgentOrchestra’s evaluation on GAIA reached state-of-the-art performance (83.39%), and the hierarchical form consistently outperformed flat-agent and monolithic baselines in task success rate and adaptability.

The Architecture

flowchart TD
    U["User objective"] --> M["Meta-Agent<br/>(Orchestrator of orchestrators)"]
    M --> P1["Planning Tool<br/>(decompose + track)"]
    M --> O1["Domain Orchestrator A"]
    M --> O2["Domain Orchestrator B"]
    O1 --> S1["Specialist agent"]
    O1 --> S2["Specialist agent"]
    O2 --> S3["Specialist agent"]
    O2 --> S4["Specialist agent"]
    P1 -. "dynamic plan updates" .-> M

The Meta-Agent’s Three Jobs

1. Decompose. Turn a vague objective into explicit sub-goals with owner agents.
2. Coordinate. Assign tasks to the right specialist; adapt role allocation as context evolves.
3. Monitor and revise. Aggregate feedback from sub-agents, update the plan in real time, isolate failures.

The Planning Agent maintains a global perspective throughout the execution process, aggregating feedback from sub-agents and monitoring progress toward the overall objective… performing dynamic plan updates. — AgentOrchestra (https://arxiv.org/html/2506.12508v2)

The Orchestrator/Sub-Agent Split (Matryoshka)

For long-horizon tasks, decouple strategic exploration from costly execution:

• Orchestrator keeps a compact cross-round state — previous instructions, summarized outcomes, scores — and decides which direction to refine next. It never accumulates raw code, logs, or full sub-agent conversations.
• Sub-Agents are instantiated with fresh contexts to implement, run, and debug concrete attempts.
• Tools mediate: format the orchestrator’s instruction into a fresh sub-agent context, launch it, and return a compact structured summary + score.

The Orchestrator is the persistent decision-making component… Unlike a monolithic agent, the Orchestrator does not directly accumulate raw code, execution logs, debugging traces, or full Sub-Agent conversations. It therefore reasons over long-horizon progress at the level of strategic decisions and outcomes. — Matryoshka Agent (https://arxiv.org/html/2607.25090)

The payoff is dramatic: Matryoshka lets a 4B model reach o4-mini-level orchestrator performance, and lifts Qwen3-30B-Coder by up to 36.7% relative.

Hierarchical Tool Discovery: Sub-Linear Prompt Scaling

A flat registry of 128+ tools blows up the prompt. The formal hierarchical architecture fixes this with a capability tree + lazy discovery:

• Skills are internal nodes (orchestrators); leaves are deterministic actions.
• The runtime only loads a node’s localized JSON manifest when the node becomes active — the LLM sees only its immediate children.
• Prompt tokens scale with branching factor and depth (~log_k N) instead of N.

The numbers are stark: at N=128 tools, prompt tokens drop from 28k to 1.7k (16×). At N=512, the flat baseline fails outright when tool schemas exceed the context window, while the hierarchical agent keeps prompts under 3k tokens and holds 70% success.

In tests with a tool catalog of N=128 tools, the hierarchical architecture reduced the number of input tokens per LLM call by approximately 16 times compared to the flat approach (1.7k tokens vs. 28k tokens). — A Formal Hierarchical Architecture for Agentic Orchestration (https://www.alphaxiv.org/overview/2607.11138)

There’s a security bonus: exposing only the active branch shrinks the prompt-injection attack surface, because an attacker can’t easily trigger a sensitive tool that isn’t visible in the current branch of the tree.

The Meta-Agent Needs First-Class Execution Traces

To inspect, branch, and rewrite a worker’s execution, a meta-agent can’t just read transcripts. SHEPHERD treats an agent’s execution like a Git repository: every action is a commit, every fork opens a branch, any past state is reachable through checkouts, and replay is exact.

Four primitives:

• emit — write an effect to the scope’s stream.
• fork — open a copy-on-write child scope (carries the worker’s environment).
• merge — propagate a child’s effects to the parent.
• discard — abandon a child, reverting the worker to its pre-fork state.

SHEPHERD records every agent–environment interaction as a typed event in a principled Git-like execution trace where any past state can be cheaply forked and replayed. — SHEPHERD (https://arxiv.org/html/2605.10913)

The same primitives power three very different applications: a live supervisor (raising CooperBench joint pass rate from 28.8% to 54.7%), a counterfactual-replay meta-optimizer, and a tree-search RL trainer.

A Meta-Agent Sketch

# Conceptual meta-agent loop (SHEPHERD-style)
while not done:
    status = meta_agent.observe(worker_commits)       # subscribe to typed event stream
    if status.needs_redirect:
        worker = meta_agent.fork(worker, at=status.checkpoint)   # branch exact state
        meta_agent.rewrite(worker, task=status.new_task)          # modify the goal
        result = worker.run()
        meta_agent.merge(worker) if result.ok else meta_agent.discard(worker)
    done = meta_agent.evaluate_scores(worker_history)

Design Principles for the Orchestrator of Orchestrators

• Keep the orchestrator’s context compact — summary-level state, not raw logs.
• Standardize the agent interface — specialists plug in behind a common interface so new agents are cheap to add.
• Fence the capability tree — expose only the active branch (also shrinks the attack surface).
• Make the stack trace auditable — the stack of decisions is the compliance record.
• Isolate execution — data from one branch never leaks into another unless explicitly passed up the stack.

Conclusion

A meta-agent turns “a team of agents” into “a managed team.” Decompose at the top, coordinate specialists in the middle, execute in fresh-context sub-agents at the bottom, and make the whole thing inspectable. Hierarchical tool discovery keeps the prompt logarithmic in tool count. First-class execution traces — Git-like, forkable, rewritable — are what make the orchestrator-of-orchestrators possible rather than theatrical.

Next steps: sketch your own capability tree with mutually exclusive domains, add lazy discovery to a tool-heavy agent, and prototype a fork/discard loop so a supervisor can redirect a worker mid-run. Gemini 3 gives you the reasoning; the meta-agent gives you the management.

References

• SHEPHERD — Enabling Programmable Meta-Agents via Reversible Agentic Execution Traces (arxiv 2605.10913): https://arxiv.org/html/2605.10913
• AgentOrchestra — A Hierarchical Multi-Agent Framework for General-Purpose Task Solving (arxiv 2506.12508): https://arxiv.org/html/2506.12508v2
• Matryoshka Agent — Unfolding Sub-Agents for Long-Horizon Machine Learning Engineering (arxiv 2607.25090): https://arxiv.org/html/2607.25090
• A Formal Hierarchical Architecture for Agentic Orchestration with Stack-Based Execution and Lazy Discovery (arxiv 2607.11138): https://www.alphaxiv.org/overview/2607.11138