Sakana Fugu og AI-agentorkestrering

Sakana Fugu er et AI-system fra Sakana AI, der lader flere sprogmodeller arbejde sammen bag én API. Nyheden peger på en bredere udvikling: avanceret AI handler ikke kun om større enkeltmodeller, men også om styring, kontrol og kombination af flere modeller i samme opgave.

Hvad er Sakana Fugu?

Sakana Fugu er en model- og agentorkestrering, som Sakana AI lancerede den 22. juni 2026. Systemet præsenteres som en multi-agentløsning, der opfører sig som én model udadtil. Brugeren sender en opgave til ét endpoint, mens Fugu internt vælger, om opgaven kan løses direkte, eller om flere modeller skal arbejde sammen.

Pointen er ikke, at Fugu er endnu en almindelig chatbot. Pointen er, at systemet forsøger at styre et samarbejde mellem flere AI-modeller, så planlægning, udførelse, kontrol og sammenskrivning kan ske i samme arbejdsgang. Det gør nyheden relevant for forståelsen af moderne AI-agenter.

Hvad er den centrale nyhed?

Den centrale nyhed er, at Sakana AI har gjort Fugu og Fugu Ultra generelt tilgængelige gennem en OpenAI-kompatibel API. Ifølge Sakana AI kommer Fugu i to varianter: Fugu, der prioriterer en balance mellem kvalitet og lav svartid, og Fugu Ultra, der er rettet mod sværere opgaver med flere trin.

Sakana beskriver Fugu som en sprogmodel, der er trænet til at kalde andre sprogmodeller i en agentpulje. Den kan også bruge instanser af sig selv rekursivt. I stedet for at brugeren selv skal bygge et komplekst multi-agent-setup, samler Fugu valg af model, uddelegering, verifikation og endelig syntese bag samme grænseflade.

Det er en vigtig forskel i forhold til mange agentværktøjer, hvor udvikleren selv skal definere faste roller, kæder, værktøjskald og kontrolpunkter. Her ligger en større del af orkestreringen i selve modellen.

Hvordan fungerer AI-agentorkestrering?

AI-agentorkestrering betyder, at et system styrer, hvilke AI-modeller eller agenter der skal løse hvilke dele af en opgave. En model kan være god til kode, en anden til analyse, en tredje til sprog, og en fjerde til at kontrollere et svar. Orkestreringen handler om at vælge rækkefølge, rolle og stopkriterium.

I en enkel arbejdsgang kan processen beskrives sådan:

1. Systemet modtager en opgave og vurderer dens type, kompleksitet og krav til kontrol.
2. En koordinator vælger en eller flere modeller, som får forskellige roller.
3. Modellerne arbejder i flere runder med plan, delresultater og kritik.
4. En verifierende rolle vurderer, om løsningen er færdig, eller om der skal arbejdes videre.
5. Systemet samler resultatet til ét svar, som brugeren modtager.

Det minder om multi-agent-systemer, men med en vigtig praktisk forskel: Brugeren ser ikke nødvendigvis hele samarbejdet. I Fugu er ambitionen, at kompleksiteten bliver skjult bag ét modelkald.

Hvordan adskiller Fugu sig fra en almindelig chatbot?

En almindelig chatbot besvarer typisk en besked med én model, eventuelt med adgang til værktøjer eller søgning. En orkestreret agentmodel forsøger derimod at fordele arbejdet mellem flere modeller og roller. Den kan bruge én model til at tænke strategisk, en anden til at udføre og en tredje til at kontrollere.

Den praktiske værdi afhænger af opgaven. En kort tekstbesked kræver sjældent mange modeller. En lang analyse, kodegennemgang, forskningsopgave eller juridisk orienteret dokumentkontrol kan derimod have gavn af tydelig opdeling mellem delopgaver og kontrol.

Hvilke arbejdsgange nævner Sakana AI?

Sakana AI nævner blandt andet kodning, kodegennemgang, chatbots, AI-forskning, reproduktion af forskningsartikler, cybersikkerhedsanalyse, litteratursøgning og patentundersøgelser. Fugu Ultra beskrives især som målrettet opgaver, hvor svarenes kvalitet og dybde betyder mere end lav svartid.

Det gør nyheden relevant ud over én produktlancering. Mange organisationer arbejder allerede med AI-workflows, hvor flere værktøjer kobles sammen. Fugu viser en beslægtet retning, hvor selve modelkaldet i højere grad forsøger at rumme koordinering, kontrol og sammenskrivning.

Sakana AI fremhæver også, at teams med data-, privatlivs- eller compliancekrav kan fravælge bestemte agenter i puljen. Det er en vigtig oplysning, fordi orkestrering ikke kun handler om bedre svar. Den handler også om, hvilke modeller der får adgang til hvilke data.

Hvad viser forskningen bag metoden?

Sakana AI knytter Fugu til forskning i lærte koordinatorer. Trinity-paperet beskriver en let koordinator, der vælger mellem flere store sprogmodeller og tildeler roller som Thinker, Worker og Verifier i et flertrinsforløb. Conductor-paperet beskriver en model, der lærer at orkestrere agenter i naturligt sprog.

Den tekniske idé er, at en mindre eller specialiseret koordinator ikke selv skal kunne løse alle dele af opgaven. Den skal i stedet være god til at vælge, hvem der skal gøre hvad, hvordan delresultater skal sendes videre, og hvornår et svar er godt nok. Det flytter noget af udviklingen fra rå modelstørrelse til testtid, koordinering og evaluering.

Det gør også benchmarkpåstande sværere at læse. Når et system bruger flere modeller, kan resultatet afhænge af agentpuljen, opgavens længde, budgettet for modelkald, den interne verifikation og de testopgaver, der er valgt. En høj benchmarkscore er derfor ikke det samme som en garanti for stabil kvalitet i en konkret arbejdsgang.

Hvilke begrænsninger bør holdes fast i?

Fugu ændrer ikke de grundlæggende problemer ved generativ AI. Et orkestreret system kan stadig misforstå en opgave, vælge en uegnet model, acceptere et forkert delresultat eller fremstille en usikker konklusion som sikker. Flere modeller kan øge chancen for intern kritik, men de kan også gentage eller forstærke hinandens fejl.

Begrænsningerne er især tydelige på områder med høj risiko:

• Faglige svar skal stadig kontrolleres mod autoritative kilder, når de bruges til beslutninger.
• Dataflowet skal være kendt, hvis opgaven indeholder personoplysninger, forretningshemmeligheder eller fortrolige dokumenter.
• Benchmarkresultater bør læses som testresultater under bestemte betingelser, ikke som dokumentation for alle fremtidige opgaver.
• Rekursive eller flertrinsbaserede agentforløb kræver logging, så fejl kan spores tilbage til det trin, hvor de opstod.

For en organisation er det derfor ikke nok at spørge, om systemet svarer godt. Det afgørende spørgsmål er, om arbejdsgangen kan afgrænses, efterprøves og stoppes, når opgaven bevæger sig uden for det tilladte.

Hvad betyder Fugu for virksomheder og udviklere?

For udviklere kan en OpenAI-kompatibel API gøre det lettere at teste en orkestreret model uden at omskrive hele applikationen. Det betyder dog ikke, at teknologien kan sættes ind uden arkitekturarbejde. Logning, fejlhåndtering, adgangsstyring, omkostningskontrol og dataklassifikation skal stadig designes uden om selve modelkaldet.

For virksomheder kan udviklingen gøre agentbaserede arbejdsgange mere tilgængelige. Hvor en intern løsning tidligere kunne kræve en særskilt agentplatform, modelrouter og evalueringslag, kan nogle dele nu ligge bag én API. Det kan sænke den tekniske tærskel, men det flytter ikke ansvaret for resultatet væk fra den organisation, der bruger systemet.

De mest realistiske anvendelser ligger i afgrænsede opgaver med tydelige mål: kodegennemgang, dokumentanalyse, researchopsummering, datasammenstilling, intern videnssøgning og rapportudkast. Opgaver med direkte afgørelser om mennesker, økonomi, sundhed eller rettigheder kræver en langt strammere kontrolramme.

Hvilke lokale forhold kan få betydning i Danmark?

For organisationer i Danmark er den praktiske betydning især knyttet til data, leverandørstyring og regulering. Hvis et orkestreret system sender indhold videre til flere underliggende modeller, skal dataansvarlige kunne forklare, hvilke leverandører der behandler hvilke data, til hvilket formål og under hvilke vilkår.

GDPR kan få betydning, hvis opgaverne indeholder personoplysninger. EU AI Act kan få betydning, hvis systemet indgår i anvendelser med høj risiko, for eksempel i uddannelse, ansættelse, adgang til væsentlige ydelser eller offentlig sagsbehandling. Den lokale relevans er derfor ikke, at Fugu automatisk er tilgængelig eller lovklar i Danmark, men at teknologien gør datakæder og ansvar mere komplekse.

Offentlige arbejdspladser, skoler og regulerede virksomheder vil typisk have brug for en mere præcis vurdering end private enkeltpersoner. De skal kunne dokumentere formål, datatyper, adgangsrettigheder, menneskelig kontrol og leverandørvilkår, før et agentisk system bruges i kerneprocesser.

Hvordan bør orkestrerede AI-systemer kontrolleres?

Kontrol bør følge arbejdsgangen, ikke kun slutsvaret. Når et system bruger flere modeller, er det nødvendigt at kunne se, hvilken model der løste hvilken del, hvilke data den fik adgang til, og hvorfor resultatet blev accepteret. Det gælder især, når systemet kan arbejde i flere trin uden at spørge brugeren for hvert skridt.

En praktisk kontrolramme kan bestå af følgende punkter:

• Definer hvilke opgaver systemet må løse, og hvilke det skal afvise.
• Klassificer inputdata, før de sendes til en modelpulje.
• Log modelvalg, værktøjskald, delresultater og endelig vurdering.
• Brug menneskelig godkendelse ved beslutninger med juridisk, økonomisk eller sikkerhedsmæssig konsekvens.
• Test systemet med egne eksempler, ikke kun med leverandørens benchmarkresultater.

Denne type kontrol ligger tæt på bredere AI-governance. Når en agent kan vælge mellem flere modeller, bliver leverandørstyring og teknisk evaluering samme problem: Organisationen skal både forstå, hvem der behandler data, og hvordan svarene bliver til.

Hvordan hænger nyheden sammen med AI-sikkerhed?

Fugu handler ikke primært om sikkerhed, men om orkestrering. Alligevel har nyheden en sikkerhedsvinkel, fordi agentiske systemer bliver sværere at kontrollere, når de kan delegere opgaver, bruge flere modeller og arbejde i længere forløb. Den samme mekanisme, der kan forbedre et svar, kan også gøre årsagskæden mere uigennemsigtig.

Det minder om diskussionen om sikre AI-agenter og kontrollerede arbejdsgange. I en kontrolramme for AI-agenter handler spørgsmålet ikke kun om modellens rå evner, men om afgrænsning, overvågning, stopmekanismer og evaluering. Orkestrering gør den diskussion mere praktisk, fordi flere underliggende systemer kan være involveret i samme svar.

For softwareudvikling kan det betyde bedre intern review, hvis en verificerende rolle faktisk finder fejl. For informationssikkerhed kan det samtidig betyde større krav til sporbarhed, fordi et fejlbehæftet eller for bredt promptet deltrin kan få betydning for hele resultatet.

Hvad sker der nu?

Den næste fase bliver praktisk afprøvning. Sakana AI’s egne benchmark- og betaeksempler viser, hvad virksomheden mener systemet kan, men bredere erfaringer fra uafhængige brugere og organisationer vil afgøre, hvor robust orkestreringen er uden for udvalgte testopgaver.

Udviklingen peger på tre spørgsmål, som vil fylde mere i AI-feltet:

• Kan en koordinator vælge den rigtige model bedre end faste regler eller manuel routing?
• Kan verifikation inde i systemet reducere fejl uden at skjule dem?
• Kan organisationer dokumentere dataflow og ansvar, når én API reelt dækker flere modeller?

Hvis svarene bliver ja i tilstrækkeligt mange arbejdsprocesser, kan orkestreringsmodeller blive et vigtigt alternativ til både enkeltmodeller og håndbyggede agentplatforme. Hvis ikke, vil teknologien især være nyttig i snævre workflows, hvor fejl kan opdages hurtigt og konsekvenserne er begrænsede.

Hvilke kilder ligger til grund?

Artiklen bygger på Sakana AI’s lancering af Fugu og Fugu Ultra, de tekniske papirer om Trinity som LLM-koordinator og Conductor til agentorkestrering samt Europa-Kommissionens overblik over AI Act og GDPR-regler for organisationer.