Multi-Agent System as a Model: What Sakana's TRINITY Paper Means for Coders
Sakana shipped Fugu as a single multi-model API. The deeper story is the TRINITY research it's built on. A model trained to orchestrate other models. Here's what shifts.
Most of the coverage of Sakana Fugu's launch this week has been "another multi-model API." That's the wrapper. The actual story is two ICLR 2026 papers underneath it: TRINITY and Conductor. They trained a model to discover its own natural-language coordination strategies for other models.
This isn't a wrapper around model routing. It's orchestration becoming a model.
The orchestration layer has been hand-written Python (LangGraph, CrewAI, AutoGen) for the last 18 months. Sakana just made it a learnable thing. That's a bigger shift than the press releases captured.
The previous era: orchestration as glue code
LangChain. LangGraph. CrewAI. AutoGen. Semantic Kernel. Different names, same shape.
A human writes Python that says: "first call this model with this prompt, then take its output and call this other model with that other prompt, then merge the results." The orchestration logic lives in your code. The models themselves are dumb about coordination.
This worked. It still works. It's the default for most production multi-agent systems today. But it has a real ceiling: the routing decisions are only as good as the rules you wrote. And those rules are usually a handful of features (task type, prompt length, urgency) checked against a handful of cases.
That ceiling is the part Sakana just punched through.
The shift: orchestration as a model
TRINITY trained a 7B model on a coordination task. Given a request, the model decides which expert models to call, what to send each one, how to combine their answers. Sakana calls it the Conductor.
Conductor extends TRINITY with reinforcement learning. The model learns its own coordination strategies, including natural-language protocols between sub-agents. They don't communicate via JSON schemas or function calls. They talk to each other in natural language, and the Conductor introspects those exchanges to decide what happens next.
The result is an orchestrator that learned its policies, not one a human hardcoded. The routing decision uses everything the model sees, not just the few features a router author thought to check.
Why this matters (the four-point version)
1. Routing decisions get sharper.
A hardcoded router has access to: prompt length, detected intent, maybe a classifier output. A trained orchestrator has access to: every token in the request, every relevant token in the conversation history, every pattern it learned from training. The asymmetry is real.
2. No coordination code to maintain.
You don't write "if classification, call cheap model" rules. You don't write "if user is on a free plan, downsample the response." The conductor learned those policies (or close approximations) from training data. Less code to write, less code to break, less code to keep in sync as the model pool changes.
3. Natural-language protocols between sub-agents.
This sounds soft but it's actually load-bearing. When sub-agents talk in natural language, the conductor can read what they said and intervene. JSON-schema coordination locks you into rigid contracts. Natural-language coordination lets the orchestrator pivot mid-task.
4. It's a single API.
From the caller's view, multi-agent disappears. You hit one endpoint, you get one answer. All the orchestration complexity collapses behind a familiar OpenAI-shaped surface.
Where this breaks down
Three honest limits.
Opacity. A trained orchestrator's routing decision is a model output. You can't read it like a Python if statement. For debugging, this is a step backward. The conductor decided to use Opus for your subtask, and you can't audit why beyond reading model logprobs.
Specialization cost. Tuning the conductor for your specific task mix probably needs fine-tuning data you don't have. Sakana trained the public model on broad data. Your domain, your custom tooling, your specific model pool: that's a different distribution. You'll get mileage out of the public version, but adapting it to your workload is non-trivial.
Local execution gap. A hosted conductor can't touch your filesystem or run shell commands. It can't open your editor or commit to your repo. For hosted classification or chat, that doesn't matter. For shipping code, it's a structural limit you can't paper over.
What this doesn't kill
Despite the headlines, three categories of tools are not going away.
Local coding agents. Claude Code, Cursor, Codex CLI, AskCodi CTO. They touch your files. A hosted conductor can't. Local agents will keep evolving on the OTHER side of this divide.
MCP and the tooling protocol. Whatever orchestrates above, the agents below still need a standard way to call tools. MCP appears to be that standard. A conductor model still talks to its sub-agents, which still talk to MCP servers.
Hand-written orchestration libraries. Most teams will keep using LangGraph for the production-shaped stuff where they want explicit control over every step. You can't fine-tune a conductor's behavior on a release deadline. You can ship a Python change.
What this does change
A few real shifts coming over the next 6-12 months.
The "wrap N models in Python" approach gets harder to justify for new hosted apps. If the conductor model is a reasonable default, why are you writing routing code? You're either trying to add specific business logic the conductor wouldn't know about, or you're cargo-culting older patterns.
The market for "orchestration as a service" gets a credible product. Not an API that wraps one model. An actual orchestrator that picks between models on every request, hosted, paid per token.
Expect 2-3 more conductor-style releases. Anthropic, OpenAI, and Google have the data and the compute to train one if they want to. The question is whether they see it as a moat or a commodity layer. Sakana's bet is that there's a moat in being the dedicated orchestration vendor, the way Cloudflare is dedicated to the edge.
The 3-layer mental model going forward
Useful frame for the next year:
- Conductor layer. Trained models that orchestrate other models. Sakana Fugu now. Others soon.
- Specialist layer. Local agents that execute. Claude Code, Cursor, Codex CLI, AskCodi CTO. They touch files, run shells, hit tools.
- Tooling protocol. MCP, which lets specialists call tools without M×N integrations.
These three are increasingly distinct jobs.
Layer 1 just got productized. Layer 2 is in active competition. Layer 3 is stabilizing as a standard.
If you ship hosted AI products, layer 1 matters for you in 6 months. If you ship code in your own repo, layer 2 is your day-to-day. They're different problems.
Close
The interesting shift isn't "we now have another API for multi-model routing." It's that the orchestration code is becoming an artifact you train, not one you write.
That's a research direction we've been watching for two years. Sakana just made it a product. The next year is when we find out how big that bet is.
If you want context on what the local agent layer looks like in practice, the coding agent benchmarks post covers what those tools actually measure. If you want the dollar math behind why multi-model routing matters at all, Hit Claude's Weekly Limit? breaks down one sprint's worth of real numbers.
The orchestration layer just became a model. Now we get to see what that's worth.
