Markdown

Sakana Fugu: orchestrator model family¶

Scope: Sakana Fugu (arXiv 2606.21228, Sakana AI) is a family of orchestrator models: language models trained to read a query and build a query-adaptive agentic scaffold over a pool of black-box frontier LLM workers (Gemini-3.1-Pro, Claude-Opus-4.8, GPT-5.5). This page covers the two released variants (Fugu, a latency-aware single-worker router; Fugu-Ultra, a quality-first multi-agent workflow composer), the three-part training pipeline (SFT on single-step tasks, evolutionary search on end-to-end trajectories, and GRPO for Ultra), the reported benchmark numbers with their honest exceptions, and how the design relates to plain request routing, the router-as-a-model idea, and multi-agent collaboration. It sits above the orchestration control plane: Fugu is a learned policy for which worker and what topology, not the governance layer that authorizes and budgets the calls.

The paper reports on proprietary models and a proprietary training corpus; the numbers below are transcribed verbatim from its Table 1, and the baseline columns are provider-reported (a comparability caveat, noted under Results). The runnable block under Architecture is a self-contained numpy model of the portfolio bound the system relies on; it is executed and its real output is pasted. The torch-style snippet is an unexecuted reference sketch of the selection head, not paper code.

What it is¶

Sakana Fugu is a learned orchestrator: a language model whose job is not to answer the query directly but to decide how a team of stronger frontier models should answer it. Given a query, a Fugu model constructs an agentic scaffold over a pool of frontier LLM workers, "deciding which workers to involve, what instructions or roles to assign, how intermediate outputs should be combined or verified, and when to synthesize the final answer".¹ The user calls Fugu as if it were a single model; internally it routes, delegates, and coordinates across specialized agents. The paper frames this as functional model composition at the behavioral level: a macro-analogue of model merging that treats each frontier model as a black box and learns to route, coordinate, verify, and synthesize their outputs, without any access to worker weights or activations.¹

Two variants ship, at different points on the quality-latency frontier:

Fugu (latency-aware) selects a single worker per query. It builds on the Trinity coordinator³ but drops role assignment, so the decision space is model selection alone. Crucially, it is a decision-only parametrization: a lightweight selection head reads a hidden state at an early token position and emits L logits (one per worker), so the query is dispatched without the orchestrator autoregressively decoding any text. Latency is therefore comparable to a direct call to a frontier model, while each query still goes to the best-suited agent.¹
Fugu-Ultra (quality-first) composes a multi-agent workflow per query. It builds on the Conductor framework⁴ and outputs a full agentic workflow in natural language: a sequence of up to five steps, each a subtask string, an integer worker id, and an access list naming which prior step outputs enter that worker's context. That expresses topologies from best-of-N and sequential chains to parallel trees. Ultra trades latency for quality and is aimed at the hardest multi-step tasks.¹

The distinction from prior multi-agent systems is that the scaffold is generated by a trained model at inference time rather than hand-designed, and the collective is exposed through a single model interface rather than a workflow the user must build and tune.¹

Why use it¶

Complementary specialization is real and exploitable. Frontier providers now diverge by domain (the paper cites Opus-class strength in software engineering and cybersecurity, GPT-class strength in mathematics, Gemini-class strength in scientific recall) and even within a domain. A per-query selector that picks the right specialist can exceed the best fixed single model when those strengths are complementary. This is the portfolio bound validated in the runnable block below.¹
Orchestration as a scaling axis without training compute. The central motivation is that composing existing models is an axis for expanding frontier capability that does not require training a larger model. New workers can enter the pool as they are released, without retraining the orchestrator against them.¹
A single interface over a heterogeneous, API-only pool. Because composition is behavioral (black-box workers), the pool can mix providers, and users can exclude specific providers or models to meet data, privacy, or compliance constraints, without retraining.¹
Adaptive aggregation, not a fixed synthesizer. Fixed mixture-of-agents routers pin one model as the final synthesizer and are bottlenecked when a task falls outside that model's expertise. Fugu-Ultra chooses the aggregator per query (the paper shows Gemini at a tree root for trivia-heavy tasks, GPT at the root for math-heavy tasks), which is the behavior a static aggregator cannot express.¹

When to use it (and when not)¶

Use an orchestrator when your workload spans domains that different frontier models win, when the strongest model differs by query, and when a single model interface over many providers is worth more than raw per-call latency. The orchestration decision guide frames this build-versus-route choice.
Prefer plain request routing (llm-request-routing.md) when the goal is cost or capacity balancing across near-equivalent models rather than exploiting complementary skill; a learned orchestrator is heavier machinery than a routing table needs.
Prefer a single strong model when one worker dominates every query in your distribution. The runnable block below proves the boundary: with a dominant agent there is no complementarity to exploit, and the orchestrator can only tie it. The paper's own MRCRv2 row is a live instance (below).
Do not treat the SOTA claim as per-benchmark or per-variant. The abstract's "performance beyond any individual LLM agent" is an aggregate claim over headline benchmarks; the full table has rows where a baseline beats one or both Fugu variants (Results). Validate on your own tasks and worker set.
Do not skip the control plane. Fugu decides which worker and what topology; it does not authorize, budget, or bind identity to the resulting calls. Those remain the job of the orchestration control plane, and Ultra's fan-out of up to five workers per query makes budget gates more important, not less.

Architecture¶

Both variants share a backbone LLM and differ in the head and the training objective. Fugu attaches a lightweight selection head after the final hidden layer that scores the L workers from a single hidden state, and adapts the backbone cheaply with singular-value fine-tuning (train only the singular-value scales of selected weight matrices, keep the orthogonal factors fixed). Fugu-Ultra keeps the LM head and is RL-trained to emit a workflow specification as text, with two mechanisms for multi-agent function calling: intra-workflow agent isolation (each worker sees only its own transcript plus what the access list grants, preventing the first agent from railroading the rest, a failure the paper names orchestration collapse) and persistent shared memory (workers retain the ongoing conversation state across workflows so they do not repeat tool calls).¹

flowchart TB
  Q["User query"] --> BB["Fugu backbone LLM (single model interface)"]
  BB --> SEL{"Variant"}
  SEL -->|"Fugu: decision-only"| HEAD["Selection head on early hidden state h in R^d -> L worker logits"]
  HEAD --> PICK["Dispatch single best worker (no autoregressive decode)"]
  SEL -->|"Fugu-Ultra: RL Conductor"| WF["Emit NL workflow: up to 5 steps (subtask, worker id, access list)"]
  WF --> ISO["Execute workers with intra-workflow isolation + shared memory"]
  subgraph POOL["Frontier worker pool (black-box, API-only)"]
    W1["Gemini-3.1-Pro"]
    W2["Claude-Opus-4.8"]
    W3["GPT-5.5"]
  end
  PICK --> POOL
  ISO --> POOL
  POOL --> SYN["Synthesize final answer"]
  SYN --> A["Answer (single-model UX)"]

The portfolio bound (runnable): when a selector beats the best single agent¶

Fugu's load-bearing claim is a portfolio/oracle-selection statement: a per-query selector over complementary specialists can exceed the best FIXED single agent, but only if routing is good, and only if the specialists are actually complementary. This numpy-only block builds a 0/1 correctness matrix with four domain experts and checks the properties the claim rests on: (a) a per-query oracle strictly beats the best single agent when specializations are complementary, (a') a realistic prior-based router (estimated on a held-out half, no per-query peeking) also beats it, (b) a worse-than-random router underperforms the best single agent so routing quality is load-bearing, (c) naive majority vote loses to the good selector when the lone expert is outvoted, (d) the no-free-lunch boundary: one dominant agent makes the oracle tie the best single agent, and (e) a one-worker pool cannot beat itself. Run: python3 fugu_portfolio.py.

# fugu_portfolio.py -- oracle-selection bound behind Fugu's core claim. numpy only.
# Fugu routes each query to a specialized worker; Fugu-Ultra composes several.
# The claim "performance beyond any individual LLM agent" is a portfolio bound:
# a per-query selector can exceed the best FIXED single agent WHEN specializations
# are complementary, but only if routing is good. This models that, with the
# adversarial and boundary cases that keep the claim honest.
import numpy as np


def correctness_matrix(rng, n_per_domain, n_domains, p_hi, p_lo):
    """0/1 correctness C[q, a]: agent a is the expert on domain a (p_hi) and weak
    elsewhere (p_lo). domain[q] gives each query's home domain."""
    domain = np.repeat(np.arange(n_domains), n_per_domain)
    n = domain.size
    p = np.full((n, n_domains), p_lo)
    p[np.arange(n), domain] = p_hi                 # expert lifts its own domain
    C = (rng.random((n, n_domains)) < p).astype(int)
    perm = rng.permutation(n)                       # shuffle so any split covers all domains
    return C[perm], domain[perm]


def best_single_agent(C):
    """Accuracy of the strongest agent held FIXED for every query (best baseline)."""
    return C.mean(axis=0).max()


def oracle_router(C):
    """Ceiling: credit the query if ANY agent is right (perfect per-query pick)."""
    return C.max(axis=1).mean()


def prior_router(C, domain, n_domains):
    """Achievable router: route by a per-domain capability prior (argmax mean
    accuracy per domain), the inference-time analogue of Fugu's learned selector.
    Priors are estimated on a held-out half so it never peeks at a query's label."""
    half = C.shape[0] // 2
    pri = np.array([C[:half][domain[:half] == d].mean(axis=0) for d in range(n_domains)])
    pick = pri.argmax(axis=1)                      # best agent per domain
    routed = pick[domain[half:]]                   # apply to the eval half
    return C[half:][np.arange(C.shape[0] - half), routed].mean()


def bad_router(C, domain, n_domains):
    """Worse-than-random router: always routes to each domain's WEAKEST agent."""
    half = C.shape[0] // 2
    pri = np.array([C[:half][domain[:half] == d].mean(axis=0) for d in range(n_domains)])
    pick = pri.argmin(axis=1)
    routed = pick[domain[half:]]
    return C[half:][np.arange(C.shape[0] - half), routed].mean()


def majority_vote(C):
    """Fixed aggregation: answer is correct iff a strict majority of agents are."""
    return (C.sum(axis=1) > C.shape[1] / 2).mean()


rng = np.random.default_rng(7)
K = 4                                              # 4 specialized workers / domains
C, domain = correctness_matrix(rng, n_per_domain=4000, n_domains=K, p_hi=0.85, p_lo=0.30)

bs = best_single_agent(C)
orc = oracle_router(C)
pr = prior_router(C, domain, K)
br = bad_router(C, domain, K)
mv = majority_vote(C)

# (a) Complementary specialists: a per-query oracle strictly beats the best FIXED
#     single agent. This IS "performance beyond any individual LLM agent".
assert orc > bs + 0.10, (orc, bs)

# (a') And a realistic prior-based router (no per-query peeking) also beats the
#      best single agent: the gain is achievable, not just an oracle artifact.
assert bs < pr < orc, (bs, pr, orc)

# (b) Routing quality is load-bearing: a worse-than-random router UNDERPERFORMS
#     the best single agent. Orchestration is not free.
assert br < bs - 0.10, (br, bs)

# (c) Naive majority vote loses to the good selector here: the lone domain expert
#     is outvoted by three weak non-experts, so fixed aggregation < prior_router.
assert mv < pr, (mv, pr)

# (d) No free lunch (boundary): if ONE agent dominates every query, the per-query
#     oracle ties the best single agent. No complementarity -> no orchestration gain.
Cdom = C.copy()
Cdom[:, 0] = 1                                     # agent 0 correct everywhere
assert np.isclose(oracle_router(Cdom), best_single_agent(Cdom)), "dominant agent must tie"

# (e) Edge: with a single worker in the pool (K=1) every strategy collapses to it.
C1, dom1 = correctness_matrix(rng, n_per_domain=8000, n_domains=1, p_hi=0.7, p_lo=0.7)
assert np.isclose(oracle_router(C1), best_single_agent(C1)), "K=1 pool cannot beat itself"

print(f"best_single={bs:.4f}  prior_router={pr:.4f}  oracle={orc:.4f}")
print(f"bad_router={br:.4f}  majority_vote={mv:.4f}")
print(f"prior gain over best single = +{pr - bs:.4f}   oracle ceiling = +{orc - bs:.4f}")
print("all Fugu portfolio-bound assertions passed")

Run output:

best_single=0.4407  prior_router=0.8468  oracle=0.9487
bad_router=0.3028  majority_vote=0.1874
prior gain over best single = +0.4060   oracle ceiling = +0.5079
all Fugu portfolio-bound assertions passed

The model is deliberately abstract: the point is the structure, not the magnitudes. A good router closes most of the gap between the best single agent (0.4407) and the oracle ceiling (0.9487); a bad router (0.3028) falls below the best single agent; and fixed majority vote (0.1874) is worst here because the lone expert per query is outvoted. Real Fugu lives between the prior router and the oracle, and, as the MRCRv2 result shows, does not always reach the ceiling.

How the orchestration works¶

The two variants are trained by different objectives, both starting from a pre-trained LM backbone.¹

Fugu, stage 1 (SFT on single-step tasks). Assemble a large collection of verifiable single-step tasks (coding, math, reasoning, language, agentic scenarios). For each query, run every worker n times, score against ground truth, average each worker's reward into s_i, and convert to a soft target distribution over workers by a temperature-tau softmax. Train the selection head and the singular-value scales to minimize the KL divergence between that soft target and the orchestrator's worker distribution. Supervising on the soft performance distribution (not a single hard best-worker label) makes selection robust when several workers are similarly capable, and needs no generation from the orchestrator itself.

Fugu, stage 2 (evolutionary search on end-to-end tasks). Single-step accuracy does not capture how a model behaves inside an interactive harness. Collect real multi-turn trajectories from coding-assistant environments (Claude Code, Codex, OpenCode) and optimize the orchestrator to maximize the expected terminal reward R(tau) in {0,1} (task completed or not) with sep-CMA-ES. The decision-only parametrization is what makes this practical: no autoregressive decode per turn. The paper reports this stage is more stable than extending SFT to end-to-end tasks, because it optimizes sparse terminal outcomes directly rather than needing reliable per-turn ranking labels.

Fugu-Ultra (RL with the Conductor reward). Ultra is trained with GRPO⁵ to emit a natural-language workflow. The reward is progressive: 0 if the subtask/worker/access-list structure cannot be parsed; 1 if the executed workflow's final output matches the reference; 0.5 otherwise. Advantages are the group-relative, std-normalized GRPO advantages over sampled completions. Ultra is trained to design workflows of up to five steps over the frontier pool, and the paper notes it is trained without a KL penalty (the beta term is dropped in their setup). The orchestrator itself may be specified as a worker, enabling recursive topologies.

The observed routing distributions match capability priors: the paper reports the agent distribution peaking on GPT-5.5 for Terminal Bench, on Gemini-3.1-Pro for GPQA-Diamond, and, within Humanity's Last Exam, math questions routed to GPT while chemistry and biology route to Gemini. That is the prior-router behavior formalized in the runnable block.¹

How to develop and integrate with it¶

Model, not framework. Fugu is consumed as a single model endpoint (Sakana AI exposes it as an API; see the product page in References). Integration is a model swap, not a workflow you author: the scaffold is internal. This is the opposite of hand-built multi-agent collaboration, where you own the roles and the message protocol.
The worker pool is a first-class config. Because composition is behavioral, you can constrain the pool (favor a provider, exclude a model) to meet compliance or residency rules without retraining the orchestrator. Treat that allowlist as governed configuration.
Contrast with the router-as-a-model pattern. Fugu-fast is a concrete, trained instance of agent-as-a-router: the routing decision is a learned head over worker logits rather than a prompt-engineered classifier or a static routing table (llm-request-routing.md). Ultra generalizes routing to full topology synthesis.
Reproduction is out of reach; the mechanism is not. The training corpus and worker pool are proprietary, so the exact model is not reproducible from the report. What is portable is the recipe (soft-target SFT, evolutionary end-to-end refinement, GRPO topology synthesis) and the selection-head idea, sketched below as an unexecuted reference.

# REFERENCE SKETCH (torch, not executed): Fugu-style decision-only selection head.
# A lightweight head scores L workers from ONE early hidden state; no text decode.
# Faithful to the paper's parametrization, not to any released weights. Validate.
import torch

class WorkerSelectionHead(torch.nn.Module):
    def __init__(self, d_model: int, n_workers: int):
        super().__init__()
        self.proj = torch.nn.Linear(d_model, n_workers)   # h in R^d -> L logits

    def forward(self, hidden: torch.Tensor) -> torch.Tensor:
        # hidden: [batch, d_model] taken at the head-input token position.
        return self.proj(hidden)                          # [batch, n_workers]

def soft_targets(worker_rewards: torch.Tensor, tau: float) -> torch.Tensor:
    # worker_rewards: [batch, L] mean reward of each worker on the query.
    return torch.softmax(worker_rewards / tau, dim=-1)    # paper eq. (1)

def sft_loss(logits: torch.Tensor, worker_rewards: torch.Tensor, tau: float):
    p = soft_targets(worker_rewards, tau)                 # KL( p || pi_theta ), eq. (2)
    logq = torch.log_softmax(logits, dim=-1)
    return torch.nn.functional.kl_div(logq, p, reduction="batchmean")

How to run it in production¶

Pick the variant per latency budget. Fugu targets interactive latency comparable to a single frontier call and is the everyday default; Fugu-Ultra spends up to five worker calls (plus their tool loops) per query and belongs on the hardest, latency-tolerant tasks. Do not put Ultra on a hot interactive path.
Budget for fan-out. Ultra's per-query cost is a variable number of worker calls, each a full frontier model, plus function-calling loops. That is the exact shape the control plane budget gate exists for: cap spend per request, because the orchestrator, not you, decides the fan-out.
Identity and audit still live outside Fugu. The single-model interface hides many worker calls; bind a brokered identity and write an audit span per worker call so the trail records who asked and which providers ran, as any governed agent system requires.
Provider drift is your operational risk. The value proposition is that new workers can be added as they appear; the flip side is that a worker's deprecation, price change, or quality regression shifts the orchestrator's realized behavior. Monitor per-worker call outcomes, not just end-to-end success.

How to maintain it¶

Re-evaluate on refresh, per worker and per benchmark. The reported numbers are tied to a specific pool (Gemini-3.1-Pro, Claude-Opus-4.8, GPT-5.5) at a fixed reasoning effort. When any worker changes, re-run your own evaluation; the routing priors the orchestrator learned may no longer match reality.
Watch for orchestration collapse in multi-agent mode. Ultra's isolation and shared-memory mechanisms exist to stop the first worker from railroading the rest. If a refactor of the harness weakens isolation, later workers add nothing; monitor per-worker contribution, not just final correctness.
Keep a single-model regression anchor. Run the strongest single worker alone on your task as a baseline. If the orchestrator ever trails it, either the task lacks complementarity (the no-free-lunch boundary) or routing is misconfigured; the runnable block distinguishes the two.
Treat constants as version-specific. The softmax temperature, the five-step workflow cap, the dropped KL penalty, and the reward tiers (0 / 0.5 / 1) are from one report on a proprietary setup. Do not assume they transfer.

Results¶

Table 1 of the paper (transcribed verbatim; higher is better). Columns are the two Fugu variants and the three public frontier baselines that also form the worker pool. Best in each row is in bold. Baseline scores are provider-reported, so cross-column comparison carries a harness-and-effort caveat that the paper partly controls by using minimal harnesses (Mini-SWE-agent, Terminus 2) and matched maximum reasoning effort.¹²

Benchmark	Fugu-Ultra	Fugu	Claude Opus 4.8	Gemini 3.1	GPT-5.5
SWE Bench Pro	73.7	59.0	69.2	54.2	58.6
Terminal Bench 2.1	82.1	80.2	74.6	70.3	78.2
LiveCodeBench	93.2	92.9	87.8	88.5	85.3
LiveCodeBench Pro	90.8	87.8	84.8	82.9	88.4
Humanity's Last Exam	50.0	47.2	49.8	44.4	41.4
CharXiv Reasoning	86.6	85.1	84.2	83.3	84.1
GPQA Diamond	95.5	95.5	92.0	94.3	93.6
SciCode	58.7	60.1	53.5	58.9	56.1
tau^3 Banking	20.6	21.7	20.6	8.4	20.6
Long Context Reasoning	73.3	74.7	67.7	72.7	74.3
MRCRv2	93.6	86.6	87.9	84.9	94.8

Reading the table honestly:

On the six headline benchmarks named in the abstract (SWE Bench Pro, Terminal Bench, LiveCodeBench, GPQA-Diamond, Humanity's Last Exam, CharXiv Reasoning), Fugu-Ultra is best among these five columns, and on GPQA-Diamond both Fugu variants tie at the top (95.5). On agentic coding the paper reports gains "in the range of 5-6% relative to the next best performer", consistent with a generational upgrade, with Fugu-Ultra beating Claude-Opus on SWE Bench Pro and GPT on Terminal Bench, which the paper reads as fine-grained cross-benchmark adaptivity.¹
The "beyond any individual LLM agent" claim is aggregate, not universal. On MRCRv2 (long-context needle retrieval), GPT-5.5 (94.8) beats both Fugu variants (Ultra 93.6, Fugu 86.6): a clean instance of the no-free-lunch boundary from the runnable block, where one worker dominates and the orchestrator cannot exceed it. The fast Fugu variant also trails a baseline on SWE Bench Pro (59.0 vs Opus 69.2) and on LiveCodeBench Pro (87.8 vs GPT 88.4), and Fugu-Ultra trails a baseline on SciCode (58.7 vs Gemini 58.9) and Long Context Reasoning (73.3 vs GPT 74.3). The two variants are also non-monotonic: plain Fugu outscores Fugu-Ultra on SciCode, tau^3 Banking, and Long Context Reasoning.
tau^3 Banking scores are low and clustered (about 20.6 for most systems; Gemini collapses to 8.4), so that row separates little.

Beyond the standardized table, the paper reports qualitative wins on expert-designed tasks: on the AutoResearch training-optimization benchmark Fugu-Ultra reaches a lower mean validation bits-per-byte (0.9774 +/- 0.0019 over three seeds) than three anonymized frontier baselines (0.9781, 0.9793, 0.9822), a small but consistent margin; and on a bespoke classical-Japanese reading-order task it leads a beam-search field (mean NED 0.776 vs 0.642 for the strongest baseline).¹ These are single-lab, small-sample results and should be read as illustrative.

A separate Figure 4 claims Fugu exceeds the "Mythos Preview and Fable 5 model class" purely through intelligent orchestration, across three panels (GPQA-Diamond, CharXiv Reasoning, and Terminal Bench 2.1, so agentic coding alongside scientific reasoning). The paper itself notes these models are not publicly accessible, are not in Fugu's worker pool, and reports their scores from vendor-published material and third-party leaderboards rather than a run the paper's authors controlled, so this comparison is against systems a reader cannot independently check; treat it as a vendor claim rather than a reproducible result.

Failure modes¶

No complementarity, no gain (the boundary). If one worker dominates the query distribution, an orchestrator can only tie it, and pays extra latency for the privilege. MRCRv2 is the live example. The runnable block proves this is structural, not a tuning failure.
Routing quality is load-bearing. A misconfigured or stale router underperforms the best single agent (the bad_router case). Learned priors decay when the worker pool shifts, so a router that was good can silently degrade after a worker update.
Orchestration collapse in multi-agent mode. Without intra-workflow isolation, the first worker to touch the environment railroads the rest into redundant contributions; the mechanism exists specifically to prevent this, and any harness change that weakens it reintroduces the failure.¹
Fan-out cost blowup. Fugu-Ultra composes up to five workers per query, each a full frontier call with its own tool loop; an unbudgeted interactive deployment can multiply per-request cost without a matching quality gain, especially on tasks with no complementarity.
Comparability of the headline numbers. Baseline columns are provider-reported under provider harnesses; the paper controls for this with minimal harnesses and matched effort, but a strict apples-to-apples reproduction on your own harness is the only way to trust the margins for your setting.
Proprietary and non-reproducible. Training data, worker pool, and hyperparameters are not fully disclosed; the exact system cannot be rebuilt from the report, and near-future model names in the pool make independent replication harder still. Port the mechanism, not the numbers.

References¶

Sakana Fugu Technical Report (arXiv:2606.21228, Sakana AI, 2026): https://arxiv.org/abs/2606.21228
Sakana AI, Fugu product page (multi-agent system as a model): https://sakana.ai/fugu
Nielsen et al., Learning to Orchestrate Agents in Natural Language with the Conductor (arXiv:2512.04388), the Fugu-Ultra basis: https://arxiv.org/abs/2512.04388
Xu et al., Trinity: An Evolved LLM Coordinator (arXiv:2512.04695), the Fugu basis: https://arxiv.org/abs/2512.04695
Shao et al., DeepSeekMath: introduces GRPO, used to train Fugu-Ultra (arXiv:2402.03300): https://arxiv.org/abs/2402.03300

Sakana Fugu Technical Report (arXiv 2606.21228). Orchestrator models that "construct an agentic scaffold over a pool of frontier LLM workers", deciding which workers to involve, roles, how outputs are combined or verified, and when to synthesize. Fugu: decision-only parametrization, lightweight selection head over L worker logits from an early hidden state, singular-value fine-tuning of the backbone, single worker per query, builds on Trinity minus role assignment; trained by soft-target SFT (softmax temperature tau, KL loss) then sep-CMA-ES on end-to-end multi-turn trajectories with terminal reward R in {0,1}. Fugu-Ultra: Conductor-based, GRPO-trained to emit up to five-step natural-language workflows (subtask, worker id, access list) with reward 0 (unparseable) / 0.5 / 1 (correct), trained without KL penalty, plus intra-workflow agent isolation and persistent shared memory for multi-agent function calling. Worker pool named as Gemini-3.1-Pro, Claude-Opus-4.8, GPT-5.5. Table 1 numbers as transcribed. https://arxiv.org/abs/2606.21228 ↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩
Table 1 caption: "Fugu models, through intelligent orchestration of leading frontier models, harness and amplify their differing skillsets to achieve new SOTA capabilities. Best scores are in bold and second-best are underlined. Baseline scores are provider-reported wherever available." Evaluation used minimal harnesses (Mini-SWE-agent, Terminus 2) and matched maximum reasoning effort across the three baseline workers. ↩
Xu et al., Trinity: An Evolved LLM Coordinator (arXiv 2512.04695): a lightweight coordinator that orchestrates LLMs with role assignment, evolved (sep-CMA-ES) rather than fully fine-tuned; Fugu scales this to production and removes role assignment. https://arxiv.org/abs/2512.04695 ↩
Nielsen et al., Learning to Orchestrate Agents in Natural Language with the Conductor (arXiv 2512.04388): an RL-trained model that emits natural-language agentic workflows over an LLM pool; Fugu-Ultra extends it with long-horizon function calling, agent isolation, and shared memory. https://arxiv.org/abs/2512.04388 ↩
Shao et al., DeepSeekMath (arXiv 2402.03300): introduces Group Relative Policy Optimization (GRPO), a critic-free PPO variant using group-relative, std-normalized advantages; Fugu-Ultra is trained with GRPO over the Conductor reward. https://arxiv.org/abs/2402.03300 ↩