O Sakana Fugu é um sistema multi-agente entregue como um único modelo, criado pela Sakana AI para resolver o velho problema de escolher manualmente qual LLM usar em cada tarefa. Em vez de obrigar o desenvolvedor a manter vários clientes de API e regras de roteamento caseiras, o Fugu oferece um ponto de entrada único que monta, em tempo real, uma equipe de modelos especializados para cada pedido.
A proposta é simples no discurso e sofisticada na engenharia: tratar a inteligência artificial como uma equipe coordenada, não como um oráculo único. O sistema avalia o pedido, decide se responde sozinho ou se precisa dividir o trabalho, escolhe os agentes certos, acompanha a execução, faz a checagem cruzada e entrega uma resposta final. Tudo isso fica encapsulado atrás de uma API REST.
Neste artigo, vamos destrinchar o que é o Sakana Fugu, como ele funciona por dentro, o que muda em relação a simplesmente chamar um modelo maior, quanto custa usar, em quais cenários ele brilha e onde os resultados precisam ser olhados com cuidado. Se você está pensando em integrar uma camada de orquestração no seu produto ou só quer entender por que tanta gente está falando de sistemas multi-agente em 2026, este é o lugar.
O que é o Sakana Fugu
O Fugu é um produto da Sakana AI, laboratório japonês conhecido pelo trabalho com modelos evoluídos e arquiteturas eficientes. O nome vem de fugu, o peixe-balão japonês: bonito, perigoso se mal preparado, mas sofisticado quando manuseado por quem entende. É uma metáfora honesta, porque orquestração mal calibrada pode entregar resultados piores do que um único modelo bom.
O ponto de venda é claro:
- Performance de fronteira sem amarrar o usuário a um único fornecedor.
- Coordenação dinâmica dos melhores modelos do mercado para cada tarefa multi-etapa.
- Inteligência coletiva entregue via uma API única.
Em outras palavras, é um produto comercial que pega de orquestração multi-agente da Sakana AI e empacota em algo que empresas podem colocar em produção sem montar toda a infraestrutura de coordenação por conta própria.
Por que um sistema multi-agente, e não um modelo maior
A corrida tradicional da indústria foi “modelos cada vez maiores, cada vez mais capazes”. Em 2026 isso já não é suficiente por três razões práticas:
- Nenhum modelo único domina todas as tarefas. Um pode ser excelente em código, outro em matemática, outro em raciocínio longo. A média ponderada raramente vence uma boa seleção por categoria.
- Custo e latência importam. Mandar o mesmo modelo gigante para uma pergunta simples desperdiça dinheiro e tempo.
- Risco de fornecedor único. Depender 100% de uma API externa é se expor a mudanças de preço, indisponibilidade e mudanças de termos.
A resposta da Sakana AI foi tratar o problema como organização de equipe. Em vez de apostar tudo em um supermodelo, o Fugu monta times sob demanda: um agente pensa, outro escreve, outro verifica. O resultado final tende a ser mais barato e mais robusto.
Como funciona por dentro
O Fugu opera com base em dois trabalhos acadêmicos publicados no ICLR 2026: TRINITY e The Conductor. Ambos tratam da mesma pergunta, mas por ângulos complementares: como é que um sistema aprende a montar, atribuir e coordenar uma equipe de modelos especialistas sem depender de um fluxo desenhado à mão por humanos?
Trinity: o coordenador evoluído
O Trinity é um coordenador leve, treinado por meio de evolução, que organiza vários LLMs ao longo de múltiplos turnos. Em vez de prescrever uma estrutura fixa de equipe, ele aprende quais atribuições funcionam melhor: quem deve pensar, quem deve executar, quem deve verificar.
Na prática, três papéis giram em torno da tarefa:
- Thinker: analisa o pedido, decompõe em subproblemas, planeja a abordagem.
- Worker: executa uma etapa concreta, seja gerar código, resolver uma equação ou redigir um parágrafo.
- Verifier: revisa o que foi produzido, aponta buracos, sugere correções.
O coordenador distribui esses papéis dinamicamente. Para uma pergunta de matemática pura, o Thinker pode ser mínimo e o Worker pesado. Para uma tarefa de código que exige raciocínio longo, o Verifier pode ganhar mais turnos. A escolha é aprendida, não escrita em pedra.
The Conductor: orquestração aprendida em linguagem natural
O Conductor é treinado com reinforcement learning para descobrir estratégias de coordenação expressas em linguagem natural. Em vez de o sistema seguir um JSON-schema rígido, ele próprio escreve os prompts e os padrões de comunicação entre os agentes.
O resultado é uma coreografia flexível: o Conductor aprende que, para um problema X, é melhor fazer uma rodada de brainstorming antes de partir para a execução; para um problema Y, vale pedir que cada agente critique o output do outro. Esses padrões emergem do treino, não de um script.
Nos benchmarks mais pesados de raciocínio, conjuntos diversos de LLMs coordenados pelo Conductor costumam superar o melhor modelo individual do pool. Em outras palavras: três modelos medianos bem orquestrados batem um modelo top sozinho em problemas difíceis.
O que você vê na prática como desenvolvedor
Para o time de engenharia, a interface é propositalmente simples. Você fala com uma API única, manda o pedido em texto, e recebe a resposta final. Toda a complexidade de seleção, combinação e verificação fica do outro lado.
Em termos de produto, isso traz três efeitos práticos:
- Menos código de cola: dá pra aposentar o switch/case que escolhe modelo por categoria. O Fugu decide.
- Observabilidade centralizada: em vez de monitorar cinco painéis de cinco fornecedores, você monitora um.
- Onboarding mais rápido: novos modelos entram no pool sem precisar reescrever a aplicação.
Controle, privacidade e governança
Mesmo com toda a automação, o Fugu deixa o usuário no comando de quem participa. É possível montar um pool de agentes e optar por excluir provedores ou modelos específicos para atender a requisitos de:
- Privacidade: dados sensíveis podem ser roteados para um agente que roda on-premise ou sob contrato específico.
- Compliance: setores regulados podem banir fornecedores que não atendam auditoria.
- Custo: tirar do pool um modelo caro demais para um caso de uso simples é trivial.
O Sakana AI também deixa claro que o uso de dados para treinar modelos é opt-out, configurável no console. Isso importa para clientes corporativos que precisam de garantias por escrito.
Modelos e planos disponíveis
O Fugu é oferecido em três níveis que ajustam o tamanho do pool, a profundidade da coordenação e o preço. A ideia é a mesma do cloud computing: você escolhe quanto quer pagar pelo SLA e pela capacidade de cada requisição.
| Plano | Para que serve | Quando faz sentido |
|---|---|---|
| Fugu | Coordenação padrão, custo otimizado | Volume alto, tarefas mistas, protótipos |
| Fugu Ultra | Pool maior, raciocínio mais profundo | Tarefas críticas, pesquisa, código complexo |
| Fugu… | Topo de linha, máxima qualidade | Casos onde o resultado precisa estar certo de primeira |
Vale notar que os planos não são tiers de modelo único, mas sim configurações de pool e profundidade de coordenação. Você não está pagando por um LLM maior, está pagando por mais turnos de raciocínio e por um pool mais largo à disposição do coordenador.
Preço: como funciona a conta
O modelo de cobrança foi desenhado para ser simples apesar da complexidade do produto. A Sakana AI resume em uma frase: você paga a tarifa do modelo de topo presente no seu pool, não a soma das tarifas de cada modelo usado.
Na prática:
- Se o seu pool só tem o Modelo A, você paga a tarifa do Modelo A.
- Se o pool tem A, B e C, você paga a tarifa do mais caro entre os três, e só.
- Adicionar mais agentes ao pool não multiplica a conta, só pode elevá-la para o próximo nível de tarifa.
O custo por requisição é reportado no payload de resposta, com a contagem de tokens discriminada. Isso facilita projetar orçamento e construir alertas antes de colocar em escala.
Quando o Fugu brilha
Existem três perfis de uso onde o sistema paga o investimento rapidamente.
1. Workflows longos e multidisciplinares
Pesquisa que envolve leitura de documentos, síntese, citação, matemática e geração de relatório final. Um modelo único tende a falhar em uma dessas etapas; uma equipe coordenada distribui melhor o risco.
2. Tarefas críticas com checagem
Código que vai para produção, análise jurídica, peças técnicas que precisam de revisão. O papel de Verifier ajuda a pegar alucinações e inconsistências antes de devolver para o usuário final.
3. Produtos com volume e variedade
Se sua aplicação recebe milhares de pedidos por dia cobrindo desde perguntas simples até problemas profundos, o pool do Fugu decide automaticamente qual abordagem seguir, sem o seu código ter que adivinhar.
Quando olhar com cuidado
Nem tudo são flores. Orquestração adiciona complexidade invisível, e há cenários em que um único modelo bom é a escolha certa.
- Latência crítica: se você precisa de resposta em menos de 300 ms, os turnos de coordenação do Fugu podem não caber. Modelos menores servidos diretamente costumam ganhar.
- Tarefas triviais e repetitivas: classificar sentimento, extrair entidades, responder FAQ curto. Não vale pagar coordenação para algo que um modelo pequeno resolve em milissegundos.
- Custos previsíveis: se a sua métrica é “custo fixo por chamada”, a variabilidade do pool pode ser um incômodo. Dá para mitigar com tarifação por pool, mas exige modelagem.
Perguntas frequentes
O Fugu é um modelo ou um sistema?
É um sistema entregue como modelo. Por trás existe uma orquestração multi-agente, mas para o consumidor a interface é a mesma de qualquer LLM: prompt entra, resposta sai.
Posso ver quais modelos foram usados em cada resposta?
Não. O roteamento interno é considerado propriedade do produto e não é exposto por design. Isso é parte do SLA: você compra um resultado coordenado, não uma lista de modelos.
Funciona fora do Japão?
Sim, com exceção da União Europeia e do EEE, onde a Sakana AI ainda está trabalhando para adequar o produto a GDPR e regulações locais. Outras regiões podem ter restrições dependendo de provedores específicos no pool.
Posso excluir um modelo do pool por questão contratual?
Sim. O console permite configurar quais provedores e modelos participam. Isso é útil para empresas com políticas de dados sensíveis ou que já têm contratos preferenciais.
Como o Fugu se compara a montar minha própria orquestração?
Se sua equipe já tem maturidade para manter pipelines multi-agente, talvez não justifique. Mas para a maioria das empresas, o custo de manter cinco integrações, observabilidade, fallback, versionamento de prompts e balanceamento é alto o suficiente para justificar pagar pelo produto pronto.
Vale a pena para o seu caso?
O Sakana Fugu é uma aposta séria em uma tendência que veio para ficar: a melhor IA não é mais a maior, é a mais bem coordenada. Para empresas que já sofrem com a complexidade de manter múltiplos provedores, o ganho de simplificação operacional sozinho pode pagar a conta. Para quem está construindo um produto novo e quer qualidade de fronteira sem virar refém de um fornecedor, é uma porta de entrada pragmática.
Para casos muito simples ou de latência crítica, o caminho clássico de chamar um único modelo pequeno continua imbatível. O Fugu não veio para substituir isso; veio para ocupar o espaço onde um modelo só não dá conta.
Se você chegou até aqui, vale colocar o Fugu na lista de testes quando for avaliar a próxima camada de IA do seu produto. A melhor forma de saber se a orquestração ajuda o seu caso é medir com o seu próprio tráfego.