---
title: 'Sakana Fugu: Learned LLM Orchestration'
url: https://www.emergentmind.com/topics/sakana-fugu
type: topic
---

# Sakana Fugu: Learned LLM Orchestration

Searching arXiv for the cited papers to ground the article.
Sakana Fugu is a family of learned LLM orchestrators developed to combine the domain specializations of frontier LLM agents into a collectively intelligent system [2606.21228]. In the technical report, Fugu models are described as language models trained to understand user queries and dynamically devise agentic scaffolds over a pool of specialized workers, including coding, math, search, and terminal/interpreter agents [2606.21228]. The report distinguishes two released variants: **Fugu**, a latency-aware orchestrator that routes each input to a single best-matched worker model, and **Fugu-Ultra**, a performance-first orchestrator that constructs multi-step, multi-agent workflows tailored per query [2606.21228]. The name “Fugu” has also been used for unrelated systems, including the Stanford “Fundamentals of Graph Understanding” benchmark for chart reasoning [2510.21740] and the Sandia National Laboratories neuromorphic framework for composing spiking neural algorithms [1905.12130]; Sakana Fugu is a separate system focused on learned orchestration of specialized LLM agents [2606.21228].

## 1. Definition and scope

Sakana Fugu is presented as **“Learned Orchestration of Specialized LLM Agents via Dynamic, Query-Adaptive Scaffolds”** [2606.21228]. Its central purpose is to expose multi-agent intelligence through a single model interface: a Fugu model receives a query, selects or coordinates worker models, decides what subtasks to assign, determines how workers communicate, manages tool use, and synthesizes outputs [2606.21228]. The report frames orchestration itself as a scaling axis, motivated by the increasing specialization of frontier models across domains such as mathematics, software engineering, cybersecurity, factual recall, and tool use [2606.21228].

The two released variants embody distinct operating points. **Fugu** is intended for “everyday interactive workloads, multi-turn tasks, and deployment scenarios where latency and cost matter,” and it uses a fast decision-only orchestrator that outputs logits for worker selection and then delegates execution to the chosen frontier model [2606.21228]. **Fugu-Ultra** is intended for “complex problems requiring composition of multiple specializations,” supports long-horizon function calling and memory, and generates multi-step workflows with chains, trees, parallel branches, and aggregation steps [2606.21228].

This design suggests that Sakana Fugu should be understood less as a monolithic assistant than as an orchestration layer over heterogeneous black-box models. A plausible implication is that its primary novelty lies in learned control over model composition, rather than in any single worker model’s intrinsic capability.

## 2. Orchestrator architectures and workflow semantics

The latency-aware **Fugu** orchestrator is described as a pre-trained language model equipped with a lightweight selection head operating on hidden states [2606.21228]. It performs **decision-only routing**: for a state $s$ such as a query or turn context, it computes a hidden state $h(s)$ at an early token position, maps it to agent logits $f_\theta(h(s))$, and dispatches immediately without autoregressive decoding [2606.21228]. Its selection policy is given as
$$
\pi_\theta(a \mid s) \propto \exp(f_\theta(h(s))_a).
$$
The report further states that Fugu uses **singular-value fine-tuning of selected backbone matrices**, with orthogonal components fixed, to refine the representation for routing with minimal trainable parameters [2606.21228]. Unlike Trinity, Fugu “does not assign explicit roles”; it selects a worker and invokes it, which narrows the coordination space and minimizes orchestration latency [2606.21228].

**Fugu-Ultra** is described as a workflow-generating orchestrator that “conducts an orchestra” by emitting an agentic workflow in natural language [2606.21228]. Each step contains three fields: **a subtask string**, **an agent id**, and **an access list** specifying which prior step outputs enter the worker’s context [2606.21228]. This workflow semantics supports “best-of-N, sequential chains, tree structures (parallel leaves, aggregator roots), repeated verification/critique cycles, test generation, debugging, multi-step tool use and terminal execution” [2606.21228]. The report emphasizes **intra-workflow agent isolation**, which prevents orchestration collapse by ensuring that each agent’s function-calling context is isolated, and **persistent shared memory across workflows**, which maintains multi-turn context while preserving isolation except where the access list permits cross-agent observation [2606.21228].

The report provides high-level orchestration loops for both variants. For Fugu, the loop performs per-turn routing until completion or budget exhaustion; for Fugu-Ultra, the model emits a workflow $W = [(subtask_1, id_1, access_1), \ldots, (subtask_S, id_S, access_S)]$ with $S \leq 5$ in training, executes each step under orchestrator-defined context composition, and then synthesizes a final output [2606.21228]. Ultra is also allowed to include the orchestrator itself as a worker in topologies if beneficial [2606.21228].

These mechanics formalize the paper’s notion of an **agentic scaffold**: a dynamic orchestration pattern generated per query, rather than a fixed prompt template or a static committee.

## 3. Training paradigm

The report describes a multi-stage training paradigm spanning supervised fine-tuning, evolutionary strategies, and reinforcement learning [2606.21228]. For **supervised fine-tuning** of Fugu on single-step tasks, the training data consists of large-scale tasks spanning “coding, mathematics, reasoning, language understanding, and agentic scenarios with verifiable ground truth” [2606.21228]. For each question $q_i$ and worker $M_j$, the system runs $n$ repetitions to obtain rewards $r_k^{M_j}$ and computes an average
$$
\bar{r}_{i,j} = \frac{1}{n}\sum_{k=1}^{n} r_k^{M_j}.
$$
These averages are converted into soft targets using a temperature-$\tau$ softmax,
$$
p_i(j) = \frac{\exp(\bar{r}_{i,j}/\tau)}{\sum_{j'=1}^{K}\exp(\bar{r}_{i,j'}/\tau)},
$$
and the objective is KL minimization,
$$
L_{\mathrm{SFT}}(\theta) = \frac{1}{|D|}\sum_{i=1}^{|D|} D_{KL}\!\left(p_i(\cdot)\ \|\ \pi_\theta(\cdot \mid q_i)\right).
$$
The stated rationale is that soft targets preserve relative performance magnitudes and robustness when multiple workers are similarly capable, while enabling stable, generation-free training of the orchestrator [2606.21228].

For **end-to-end tasks**, Fugu is further optimized with **sep-CMA-ES** using multi-turn trajectories from real coding-assistant environments such as Claude Code, Codex, and OpenCode [2606.21228]. A trajectory is written as $\tau = (s_0, a_0, s_1, a_1, \ldots, s_T)$ with terminal reward $R(\tau) \in \{0,1\}$, and the objective is
$$
J(\theta) := \mathbb{E}_{\tau \sim \pi_\theta}[R(\tau)].
$$
Candidate policies are sampled as
$$
\theta^{(k)} = \theta_t + \sigma_t D_t z^{(k)}, \qquad z^{(k)} \sim N(0, I),
$$
and recombined via
$$
\theta_{t+1} = \theta_t + \sigma_t D_t \sum_{j=1}^{\mu} w_j z_{j:\lambda}.
$$
The report states that this directly optimizes end-to-end outcomes with sparse or noisy signals and stably refines routing behavior from an SFT initialization [2606.21228].

For **Fugu-Ultra**, the training method is reinforcement learning for workflow design under the **Conductor framework** [2606.21228]. Ultra emits workflows, and rewards are defined by two conditions: a **format condition**, where $r_i = 0$ for malformed workflows, and a **correctness condition**, where $r_i = 1$ if executing the workflow yields the correct final output and $r_i = 0.5$ otherwise for a well-formatted but incorrect workflow [2606.21228]. The objective is GRPO over grouped completions with advantage normalization,
$$
J(\theta)=
E_{q \sim D,\ \{o\}_1^G \sim \pi_\theta(\cdot \mid q)}
\left[
\frac{1}{G}\sum_{i=1}^{G}\left(\min(r_i A_i,\mathrm{clip}(r_i,1-\epsilon,1+\epsilon)A_i)-\beta D_{KL}(\pi_\theta \| \pi_{\mathrm{ref}})\right)
\right],
$$
with
$$
A_i = \frac{r_i - \mathrm{mean}(\{r_1,\ldots,r_G\})}{\mathrm{std}(\{r_1,\ldots,r_G\})},
$$
and the report specifies $\beta = 0$ in the reported training [2606.21228].

Taken together, these methods indicate that Sakana Fugu is trained not merely to answer queries, but to estimate comparative worker utility, optimize routing under sparse terminal rewards, and learn valid workflow syntax jointly with task performance.

## 4. System design, tools, and memory model

The report organizes the system around four core principles: **robustness**, **adaptivity**, **verification**, and **modularity** [2606.21228]. Robustness is implemented through format validation, terminal rewards, budgets and turn caps, and workflow parsing checks [2606.21228]. Adaptivity appears at multiple levels: per-query scaffold generation, per-turn routing in Fugu, and per-step topology adaptation in Ultra [2606.21228]. Verification is supported by self-critique, aggregation, test generation, and environment feedback through terminal or harness execution [2606.21228]. Modularity follows from treating frontier workers as black-box models in a configurable agent pool that can respect provider, privacy, and compliance constraints [2606.21228].

The tooling layer includes **terminal and code execution** through reference agent harnesses such as **Mini-SWE-Agent** and **Terminus 2**, along with coding environments including **Claude Code** and **Codex** [2606.21228]. Web search, browsing, retrieval, file I/O, sandboxing, and caching are environment-managed, while the orchestrator tracks function-call origins and routes responses to the correct agent [2606.21228]. For Fugu, tool interaction is delegated to the selected worker and harness [2606.21228].

The memory model differs between the two variants. In **Ultra**, intra-workflow agent function-calling trajectories are isolated, while **persistent shared memory across workflows** retains conversation background and avoids redundant tool calls [2606.21228]. The orchestrator also tracks selected models, communication topology, and assigned subtasks across user-agent interactions so that function-call loops can be returned to the originating agent while preserving topology [2606.21228]. In **Fugu**, the multi-turn state $s_t$ includes transcript, tool calls, and environment feedback, and routing is recomputed per state [2606.21228].

This architecture suggests that Sakana Fugu’s operational complexity lies not only in choosing strong workers, but in preserving correct communication structure under tool-mediated execution.

## 5. Empirical performance and benchmark profile

The technical report evaluates Sakana Fugu on a range of challenging tasks with the same frontier worker pool and compares it against those frontier models run directly with matched reasoning effort [2606.21228]. The headline results position **Fugu-Ultra** as the strongest variant on several difficult benchmarks, while **Fugu** often provides a lower-latency operating point with competitive or superior performance to individual workers [2606.21228].

| Benchmark | Fugu-Ultra | Fugu |
|---|---:|---:|
| SWE-Bench Pro | 73.7 | 59.0 |
| Terminal Bench 2.1 | 82.1 | 80.2 |
| LiveCodeBench v6 | 93.2 | 92.9 |
| LiveCodeBench Pro (Q2 2025, text-only, no tools) | 90.8 | 87.8 |
| GPQA-Diamond | 95.5 | 95.5 |
| Humanity’s Last Exam (multimodal samples, no tools) | 50.0 | 47.2 |
| CharXiv Reasoning | 86.6 | 85.1 |
| SciCode | 58.7 | 60.1 |
| $\tau^3$ Banking (pass@4) | 20.6 | 21.7 |
| Long Context Reasoning | 73.3 | 74.7 |
| MRCRv2 (8-needle retrieval up to 128k) | 93.6 | 86.6 |

On **SWE-Bench Pro**, the report gives 73.7 for Fugu-Ultra, compared with 69.2 for Claude Opus 4.8, and notes that this is consistent with “generational-level gains” [2606.21228]. On **Terminal Bench 2.1**, Fugu-Ultra scores 82.1 and Fugu 80.2, versus 78.2 for GPT-5.5; the report attributes Fugu’s strength here to alternation between GPT-5.5 and Opus-4.8 at critical debugging steps despite its single-selection design [2606.21228]. On **GPQA-Diamond**, both Fugu variants score 95.5 and are described as setting new state of the art by dynamically drawing on GPT’s math and physics expertise and Gemini’s scientific recall [2606.21228]. On **Humanity’s Last Exam**, Ultra reaches 50.0, ahead of Claude Opus 4.8 at 49.8, and the report states that Ultra uses tree-like debate and task-dependent aggregation such as choosing Gemini for trivia-heavy tasks [2606.21228].

The report also includes several expert-designed end-to-end evaluations. In **AutoResearch**, after 123 experiments on a single H100 GPU, Fugu-Ultra achieves mean best validation BPB of **0.9774 ± 0.0019** and best single seed **0.9748**, compared with Model C at **0.9781 ± 0.0011**, Model B at **0.9793 ± 0.0025**, and Model A at **0.9822 ± 0.0017** [2606.21228]. In **Classical Japanese kana letter reading order**, the mean normalized edit distance is **0.776** for Fugu-Ultra, **0.473** for Fugu, and **0.116** for the baseline heuristic [2606.21228]. In **one-shot Rubik’s cube solver synthesis**, Fugu-Ultra solves **300/300** with mean **19.72 HTM** and mean time **72.6 s**, while Fugu also solves **300/300** with mean **21.15 HTM** and mean time **1.9 s** [2606.21228]. The report states that Ultra achieves the shortest solutions, whereas Fugu trades approximately one extra move for approximately 35 times faster solving [2606.21228].

The benchmark profile supports a clear division of labor between the variants. Fugu is optimized for low-latency routing and can outperform single frontier models through per-turn alternation in interactive settings; Fugu-Ultra uses dynamic topologies, critique, and aggregation to maximize accuracy on difficult tasks [2606.21228].

## 6. Observed orchestration strategies, limitations, and interpretation

The report gives several qualitative descriptions of the orchestration strategies learned by the system. **Debate and aggregation** are common in Ultra, which can build tree topologies with adaptive aggregators such as Gemini for knowledge-intensive trivia and GPT for math-heavy synthesis [2606.21228]. **Build-and-debug** patterns are also described: Ultra can deploy GPT as builder and Opus as debugger or verifier, while Fugu can alternate selections across turns so that GPT builds and Opus resolves merge conflicts or derives required logic [2606.21228]. In another case, Ultra “brings in a specialist” by invoking GPT as a math specialist after Opus constructs a cybersecurity attack, thereby composing math, engineering, and security expertise [2606.21228].

The report also presents **ablation-style findings**. It states that **ES on end-to-end tasks is more stable than supervised fine-tuning on those tasks** and that SFT provides a strong initialization anchored by empirical worker performance [2606.21228]. It contrasts **router vs multi-agent workflows**, arguing that Fugu’s per-turn router achieves low-latency gains while Ultra’s adaptive topologies unlock new state of the art [2606.21228]. It further notes that **verifier and critic use** in Ultra improves correctness on multidisciplinary and knowledge-intensive tasks, and that **tool access** is crucial for coding-heavy evaluations such as SWE-Bench and Terminal Bench [2606.21228].

Several limitations are stated explicitly. **Fugu single-selection may miss synergy when a composite approach would be superior**, though this is precisely what Ultra is designed to address at the cost of latency [2606.21228]. **Sparse rewards and environment brittleness** in end-to-end tasks can limit learning signal, and benchmark scores can depend on harness fidelity, with package-version differences affecting measurements such as SciCode [2606.21228]. The report also identifies complexity in **persistent memory design** for multi-agent function calling, where subtle bugs can arise if isolation or access lists are mis-specified [2606.21228]. More broadly, dependence on heterogeneous frontier providers can introduce latency and cost variability, mitigated through configurable pools, caching, and provider prioritization [2606.21228].

These limitations indicate that Sakana Fugu’s performance gains are inseparable from systems engineering concerns: workflow validity, harness fidelity, provider heterogeneity, and memory isolation are part of the method rather than peripheral implementation details.

## 7. Relation to other systems named “Fugu”

The term **Fugu** is overloaded across multiple research contexts. In **“Diagnosing Bottlenecks in Data Visualization Understanding by Vision-Language Models”**, FUGU is an acronym for **Fundamentals of Graph Understanding**, a Stanford benchmark and analysis suite for diagnosing why current vision-language models fail on basic chart and plot understanding [2510.21740]. That work uses controlled synthetic scatter plots, activation patching, and linear probes to analyze perceptual encoding, the vision-language handoff, and language-side reasoning in VLMs [2510.21740]. Its subject matter is data visualization understanding rather than LLM orchestration [2510.21740].

In **“Composing Neural Algorithms with Fugu”**, Fugu is a **high-level, hardware-independent framework** from Sandia National Laboratories for composing spiking neural algorithms into executable neuromorphic applications [1905.12130]. It centers on abstractions such as **bricks**, **scaffolds**, and a platform-independent graph-based intermediate representation, and is intended to simplify neuromorphic programming rather than orchestrate frontier language models [1905.12130].

Sakana Fugu is therefore distinct from both of these earlier uses. Its scope is learned orchestration over specialized LLM agents, using query-adaptive scaffolds, tool-mediated execution, and multi-agent workflow design [2606.21228]. The shared naming does not imply shared architecture, authorship, or research program.

Source: https://www.emergentmind.com/topics/sakana-fugu