The Research Behind Fugu: TRINITY and the Conductor, Explained

Fugu didn’t appear from nowhere. Behind Sakana’s multi-agent model sit two peer-reviewed papers — both accepted at ICLR 2026 — and a technical report that explains how the research became a product. If you want to actually understand why Fugu behaves (and bills) the way it does, the papers are the ground truth. This article explains both for practitioners, then draws the line that matters: what the papers demonstrate versus what the shipped product does. Abstracts re-pulled from arXiv on August 19, 2026; links to all three documents at the end.

Diagram: TRINITY assigns Thinker, Worker and Verifier roles while the Conductor designs agent-to-agent communication

TRINITY: a tiny coordinator commanding giants

TRINITY: An Evolved LLM Coordinator (arXiv, December 2025) starts from a practical dead end: the obvious way to combine models — merging their weights — fails across mismatched architectures and is impossible with closed APIs. So TRINITY combines models the way organizations combine people: with a coordinator.

The numbers are the striking part. The coordinator is a compact language model of roughly 0.6 billion parameters plus a lightweight head of about 10 thousand parameters — a rounding error next to the frontier models it directs. It processes queries over multiple turns, and at each turn assigns one of three roles to a selected model from the pool: Thinker (reason about the problem), Worker (produce the output), or Verifier (check it). The coordinator never needs the skills itself; it learns delegation, offloading complex skill acquisition to the pool.

Two design choices matter for practitioners. First, the coordinator is optimized with an evolutionary strategy rather than gradient training — in keeping with Sakana’s nature-inspired research identity, and well-suited to a component this small. Second, the reported results: the paper shows TRINITY consistently outperforming individual models and existing combination methods across coding, math, reasoning, and domain-knowledge tasks, generalizing robustly out of distribution, and scoring 86.2% on LiveCodeBench — state of the art at the time, achieved by coordination rather than scale.

The takeaway in one line: a well-run team of existing models beats its best member, and the manager can be tiny.

The Conductor: learning who talks to whom

Learning to Orchestrate Agents in Natural Language with the Conductor (arXiv, December 2025) attacks the part of multi-agent systems humans always hard-code: the communication structure. Its Conductor is a 7-billion-parameter model trained with reinforcement learning to do two jobs at once — design the communication topology (should agents work in a chain? debate? fan out in parallel?) and write targeted instructions for each worker, prompt-engineering every agent individually to exploit what it’s best at.

Three findings stand out. A 7B Conductor coordinating a pool of powerful workers achieves gains beyond any individual worker, with state-of-the-art results on reasoning benchmarks including LiveCodeBench and GPQA. Training with randomized agent pools makes it adapt to arbitrary rosters of open- and closed-source models — the coordination skill transfers when the team changes, which is exactly the property a product would need as the frontier shifts. And most striking: allowed to select itself as a worker, the Conductor discovers recursive topologies — orchestrations inside orchestrations — that raise performance further.

The takeaway: coordination strategy itself is learnable — including structures no one hand-designed.

From papers to product: the technical report

The Sakana Fugu Technical Report (arXiv, June 2026) describes what shipped: a family of orchestrator models — language models “trained to understand user queries and dynamically devise agentic scaffolds to solve them.” Through those adaptive scaffolds, the report says, Fugu reaches performance beyond any individual agent, with state-of-the-art results among publicly accessible models on SWE-Bench Pro, Terminal Bench, LiveCodeBench, GPQA-Diamond, Humanity’s Last Exam, and CharXiv Reasoning. Two models were released: Fugu, balancing performance with latency, and Fugu Ultra, prioritizing answer quality on the hardest problems.

You can see both research lineages in the product’s documented behavior: role-structured teamwork and verification (TRINITY’s fingerprint), per-problem team composition with 1–3 expert agents on Ultra and targeted per-agent briefing (the Conductor’s), and robustness to a shifting pool — Sakana says it continuously updates the pool and retrains coordinators as new frontier models release, which is precisely what the Conductor’s randomized-pool training was built to enable. Even the billing follows from the research: scaffolds run on real tokens, which is why orchestration usage is metered and billed.

2026 update: the conductor goes modular

The Conductor paper’s randomized-pool training promised coordination skills that transfer when the team changes. In a verification post dated August 10, 2026, Sakana showed the same holds for the coordinator itself: it re-trained Fugu’s conductor on a different open base model — an open Gemma-family model under an Apache 2.0 license — using the same training method, and reports orchestration performance and cost reduction comparable to the production conductor. The post also reveals a production detail previously unpublished: the shipped conductor had been trained on a Qwen-family base.

Two structural facts confirmed along the way: the conductor is small (the whole point — heavy knowledge lives in the pool, so the coordinator can be retrained affordably and its base swapped), and the model pool was designed swappable from the start, with Sakana citing selection criteria like cost, provider location, and execution environment — and work underway to bring NVIDIA’s open Nemotron family into the pool. Sakana’s stated direction is conductors built on domestically developed models for sovereignty requirements. For Fugu users, the practical read: the orchestration layer, not any particular underlying model, is the product.

The line between the papers and the product

Sakana’s own framing, in the README and report, is that Fugu is based on these two papers — grounded in the research, not identical to it — and that “since publication, we have made several enhancements.” So keep the claims sorted:

  • What the papers demonstrate: a ~0.6B evolved coordinator assigning Thinker/Worker/Verifier roles beats individual models (TRINITY); a 7B RL-trained model can design communication topologies and per-agent instructions, adapt to arbitrary pools, and discover recursive structures (Conductor). Specific numbers like TRINITY’s 86.2% LiveCodeBench belong to those experimental systems, at their publication dates.
  • What the product does: ships orchestrator models that devise agentic scaffolds per query, with the June 2026 evaluation results Sakana reports for Fugu and Fugu Ultra. Whether today’s production coordinator is 0.6B or 7B, evolved or RL-trained, how it composes scaffolds — unpublished. Don’t attribute paper internals to the product, and treat anyone who does with suspicion.

The sources

Is Fugu literally TRINITY or the Conductor?

Neither, per Sakana’s own framing: the product is based on the two papers with subsequent enhancements. The papers describe the experimental systems (a ~0.6B evolved coordinator; a 7B RL-trained conductor); the shipped coordinator’s size, training method, and internals are unpublished.

Are the papers peer-reviewed?

Yes — both TRINITY and the Conductor were accepted at ICLR 2026, a top machine-learning venue. The technical report (arXiv, June 2026) is a company report, not a peer-reviewed publication.

Does Fugu use recursive orchestration?

The Conductor paper demonstrates recursive topologies (the conductor selecting itself as a worker), and Fugu’s public description mentions the system’s ability to recursively call instances of itself. How much of that runs in production, and when, isn’t published.

Why should a Fugu user care about the research?

Because the product’s oddities become design decisions once you’ve seen the papers: orchestration tokens exist because scaffolds run on real tokens; effort levels scale internal coordination; Ultra’s 1–3 agent routing is team composition. The billing model stops being surprising and starts being legible.

See the research in product form: What is Sakana Fugu? for the full picture, the billing consequences of running scaffolds on real tokens (and the full price list they land on), and the playground to watch an orchestrator answer you, cost meter running.