Hoe maak je je AI-workflow minder afhankelijk van één model?

Op 12 juni 2026 zette Anthropic de toegang tot zijn nieuwste modellen Fable 5 en Mythos 5 abrupt stil. Niet uit eigen beweging: de Amerikaanse overheid gaf die avond een exportcontroledirectief af dat toegang voor alle gebruikers verplicht uitschakelde, ook voor klanten die niets met de aanleiding te maken hadden. Organisaties die een workflow hadden gebouwd die rechtstreeks op een van die twee modellen leunde, stonden van het ene op het andere moment met een storing die niets met hun eigen techniek te maken had.

Het is precies het scenario waarmee AI-leverancier Sakana AI deze week opent in de aankondiging van zijn nieuwe product Fugu: een laag boven een pool van modellen, die zelf bepaalt welk onderliggend model een taak het beste kan uitvoeren en dat model desnoods vervangt zonder dat de gebruiker daar iets van merkt.

Het korte antwoord

Het risico dat één leverancier je workflow stillegt, verklein je door je workflow zo te ontwerpen dat het onderliggende model een vervangbaar onderdeel is. Dat betekent twee dingen: modellen onderling inwisselbaar maken zodra dat nodig is en verschillende modellen tegelijk laten samenwerken op basis van waar elk model relatief het beste in is. Dat is het uitgangspunt waarmee wij workflows voor klanten ontwerpen en het is ook precies het probleem dat Sakana Fugu commercieel probeert op te lossen.

De nuance

Sakana Fugu gedraagt zich naar buiten toe als één model, maar stuurt van binnen een pool van onderliggende modellen aan: het kiest welk model of welke combinatie van modellen een taak oppakt, verdeelt het werk, controleert tussenresultaten en voegt alles samen tot één antwoord. Sakana noemt de stillegging van Fable 5 en Mythos 5 expliciet als aanleiding: wie zijn workflow niet aan één leverancier vastlegt, ondervindt minder hinder zodra de toegang tot een specifiek model wegvalt of verandert.

Een paar kanttekeningen zijn hier op hun plaats. De prestatievergelijkingen die Sakana publiceert, zijn voor een deel gebaseerd op cijfers die de modelleveranciers zelf hebben gerapporteerd, niet op onafhankelijk getoetste scores. Fable 5 en Mythos Preview komen in die vergelijking voor, maar zitten zelf niet in de pool van modellen die Fugu daadwerkelijk aanstuurt, simpelweg omdat ze niet publiek toegankelijk zijn. De vergelijking zegt iets over waar Fugu volgens Sakana ten opzichte van die modellen staat, niet over hoe Fugu zich gedraagt zodra je het op je eigen taken inzet.

Belangrijker is dat een orkestratielaag zoals Fugu het probleem van leveranciersafhankelijkheid niet oplost, maar verplaatst. In plaats van afhankelijk te zijn van OpenAI, Anthropic of Google, word je afhankelijk van Sakana en van hoe goed die ene laag blijft functioneren als de markt verandert. Leveranciersonafhankelijkheid die je koopt bij één partij, blijft in de kern een keuze voor één partij. Echte onafhankelijkheid zit in hoe je je eigen workflow inricht, niet alleen in welk product je daarboven op zet.

De aanpak

Wij ontwerpen AI-workflows met twee vormen van flexibiliteit. Welke vorm je nodig hebt, hangt af van waarom je die flexibiliteit zoekt.

De eerste vorm is inwisselbaarheid. Je bouwt de stap waarin een model wordt aangeroepen als een los onderdeel van de workflow, met een vaste interface ertussen. Welk model die stap precies uitvoert, ligt dan niet vast in de rest van de architectuur. Dat is relevant bij een storing zoals bij Fable 5 en Mythos 5, maar net zo goed bij een prijswijziging. Nu Microsoft, Anthropic en binnenkort OpenAI agentisch gebruik per token afrekenen in plaats van tegen een vast tarief, kan een workflow die niet aan één leverancier vastzit, eenvoudig uitwijken naar een goedkoper alternatief voor de stappen waar dat kan.

De tweede vorm is heterogene samenwerking. Niet elk model is voor elke stap even geschikt. Die ongelijkheid volgt geen voorspelbaar patroon: het ene model is sterk in code, het andere in lange documenten, een derde in het strikt navolgen van instructies. Wij brengen per werkproces in kaart welke stappen welke sterktes vragen en ontwerpen de overdracht tussen stappen bewust, met een controlemoment op de plek waar de kwaliteit het meest kwetsbaar is. Een open standaard als MCP helpt daarbij, omdat die de koppeling tussen een workflow en de onderliggende modellen en systemen standaardiseert in plaats van vastzet aan één leverancier.

Geen van beide vormen betekent dat je voor elke taak een zware orkestratielaag nodig hebt. Niet elke taak heeft een autonome agent nodig en hetzelfde geldt voor modelonafhankelijkheid: een eenvoudige taak met één betrouwbaar model is vaak goedkoper en simpeler dan een laag die voortdurend beslist welk model iets oppakt. Bepalend is of de stap waar je nu aan vastzit, je daadwerkelijk pijn doet bij een storing of een prijswijziging. Dat verschilt per werkproces en pas dan wordt duidelijk of orkestratie de moeite waard is.

Resultaat

Een workflow die zo is opgezet, voorkomt geen enkele storing. Wat het wel doet, is de impact ervan beperken tot de stap die geraakt wordt, in plaats van de hele workflow. Voor de organisaties die wij hierin begeleiden, betekent dat concreet: een overzicht van welke stap in welk werkproces aan welk model vastzit, een vastgesteld alternatief per kritieke stap en een architectuur die dat alternatief kan inzetten zonder dat de rest van de workflow opnieuw gebouwd moet worden. Dat is minder spectaculair dan een nieuw product dat het hele probleem voor je oplost, maar het is wel het deel dat je zelf in de hand hebt.

Wil je weten waar jouw AI-workflows op dit moment aan één leverancier of model vastzitten? Plan een kennismaking in.