Op 5 augustus 2026 herschikte Google in één aankondiging de hele AI-leiding: DeepMind-CEO Demis Hassabis stapte terug naar de rol van voorzitter en chief scientist van Alphabet, de dagelijkse leiding over Gemini ging naar Koray Kavukcuoglu, en chief scientist Jeff Dean vertrok na 27 jaar om een concurrerend lab te starten. Als uw productie-agentstack de SDK van één leverancier rechtstreeks in de bedrijfslogica heeft verweven, is dít hoe leveranciersconcentratie-risico er in de praktijk uitziet — en de oplossing is een model router, niet een andere leverancier.
Wat er deze maand écht veranderde bij Google
Hassabis verruilde de CEO-stoel van DeepMind voor de rol van voorzitter en chief scientist van Alphabet, en blijft daarnaast Isomorphic Labs leiden, de dochteronderneming voor medicijnontdekking. Kavukcuoglu, voorheen CTO van DeepMind, leidt nu als SVP de Gemini-modelontwikkeling en Googles AI-platforms voor ontwikkelaars, en rapporteert rechtstreeks aan Sundar Pichai — waarmee hij feitelijk degene is die nu de roadmap en prioriteiten bepaalt voor elk team dat op Gemini of Vertex AI bouwt. Diezelfde dag maakte Jeff Dean bekend na 27 jaar te vertrekken, samen met senior fellow Sanjay Ghemawat, Google Brain-medeoprichter Quoc Le en DeepMind-VP Oriol Vinyals, om Discovery Loop op te richten, een public-benefit corporation die de wetenschappelijke onderzoekscyclus wil automatiseren. Google is oprichtend investeerder en cloudpartner van de nieuwe onderneming, naast Radical Ventures en Khosla Ventures.
Waarom dit een architectuurprobleem is, geen kantoorroddel
De reorganisatie kwam niet uit de lucht vallen. Gemini 3.5 Pro had al drie aangekondigde releasedata gemist; Google zou naar verluidt een bijna-klare versie van het model hebben geschrapt en de pretraining opnieuw zijn gestart vanaf een native Gemini 3-fundament, na aanhoudende problemen met codeerprestaties en betrouwbaarheid, en vier senior onderzoekers, onder wie Gemini-co-lead Noam Shazeer, waren al naar OpenAI en Anthropic vertrokken vóórdat de leiderschapswissel in augustus werd aangekondigd. Niets daarvan is uniek voor Google — elk lab had in 2026 wel een lastig kwartaal. Het punt voor een engineeringteam is specifieker: als uw architectuur uitgaat van de roadmap van één lab, erft u ook de interne onrust van dat lab. Een vertraagd model, een gereorganiseerd team, een gewijzigde prijsstaffel of een afgeschaft endpoint zijn hetzelfde faalpatroon in een ander jasje — modelkwaliteit is niet de enige variabele die onder u kan verschuiven.
Wat een model router precies is
Een model router is een middleware-laag tussen uw applicatie en een pool van beschikbare taalmodellen, met als taak elk verzoek naar het model te sturen dat er daadwerkelijk bij past — in plaats van de prijs van een topmodel te betalen voor een vraag die een klein model net zo goed beantwoordt. Per verzoek weegt de router signalen als taakcomplexiteit, kosten per token, latency en belasting van de leverancier, en actuele beschikbaarheid, en stuurt het verzoek door — of, in sommige implementaties, geeft alleen een aanbeveling terug waarna de aanroepende applicatie zelf het verzoek doet. De meeste teams grijpen hiernaar zodra LLM-gebruik geen experiment meer is maar gedeelde infrastructuur: meerdere modellen in gebruik, echte kostendruk, en betrouwbaarheidseisen die geen storing bij één leverancier kunnen verdragen zonder dat een hele functie uitvalt.
Regelgebaseerd, semantisch en voorspellend routeren
Productierouters gebruiken doorgaans een van drie strategieën, meestal in deze volgorde toegevoegd naarmate het verkeer groeit.
- Regelgebaseerd routeren: verzoeken worden toegewezen op basis van vooraf gedefinieerde voorwaarden — trefwoorden, lengtedrempels, headertags. Eenvoudig, voorspelbaar en makkelijk te debuggen, maar de regels vragen voortdurend onderhoud zodra de takenmix verschuift, en randgevallen worden verkeerd gerouteerd.
- Semantisch routeren: query's en kandidaat-routes worden als vectoren ingebed en op gelijkenis gematcht, zodat "wat is mijn saldo?" en "hoeveel geld heb ik?" op dezelfde route uitkomen zonder een gedeeld trefwoord. Dit vraagt een verstandige gelijkenisdrempel en een terugvaloptie voor alles wat daaronder scoort.
- Voorspellend routeren: een model leert uit gelabelde voorkeursdata welke leverancier een bepaalde query het beste afhandelt, en weegt kwaliteit tegen kosten. De referentie-implementatie hier is RouteLLM, waarvan de matrix-factorisatierouter 95% van de MT-Bench-score van GPT-4 behaalt terwijl slechts 14% van de query's naar het dure model gaat. Dit vraagt trainingsdata en een redelijk stabiele queryverdeling om stand te houden — de meeste teams beginnen regelgebaseerd en grijpen hier pas naar zodra een eenvoudigere router aantoonbaar tekortschiet.
Foutafhandeling is het onderdeel dat u écht redt
Kostenbesparing is meestal de reden dat teams met een router beginnen; veerkracht is de reden dat het ertoe doet in een week als die van Google's reorganisatie. Verschillende faalpatronen vragen verschillende reacties, en ze allemaal als hetzelfde retry-en-terugval-geval behandelen is een veelgemaakte fout: een harde 5xx-fout vraagt om direct overschakelen naar een ander model; een 429-ratelimiet betekent afremmen en opnieuw proberen na de door de leverancier opgegeven vertraging, niet meteen opnieuw aankloppen; oplopende latency zonder harde fout betekent nieuwe verzoeken verschuiven naar een snellere leverancier vóórdat gebruikers het merken; en een contentfilter-afwijzing betekent dat de prompt een veiligheidscontrole raakte, niet dat de leverancier stuk is, dus dat vraagt om beleidscorrectie in plaats van een nieuwe poging. Twee patronen doen hier het meeste werk, zoals Redis' analyse van productierouterarchitectuur beschrijft: een circuit breaker die stopt met verzoeken sturen naar een leverancier zodra het foutpercentage een drempel overschrijdt, en multi-provider failover die verkeer automatisch naar een tweede leverancier verschuift. Geen van beide brengt een uitgevallen leverancier terug online, maar beide voorkomen dat een team tijd en budget verspilt aan aanroepen waarvan al vaststaat dat ze zullen mislukken — precies de laag die een Gemini-verstoring tijdens de reorganisatieweek had opgevangen zonder dat iemand verderop in de keten het merkte.
Zelf bouwen of kopen: LiteLLM, OpenRouter en zelf hosten
Twee open paden dekken de meeste teams. LiteLLM is een zelf te hosten, open source proxy die één OpenAI-compatibele interface biedt naar meer dan honderd leveranciers, met ingebouwde kostentracking, guardrails en load balancing — u draait het zelf, dus u houdt controle over dataresidentie en infrastructuurkosten. OpenRouter is een gehoste gateway naar honderden modellen achter één API: sneller op te starten, minder operationele last, maar u vertrouwt de routeringslaag zelf toe aan een derde partij. Voor de meeste teams onder reële productiebelasting is een gehoste gateway het eerlijke startpunt; zelf hosten rendeert zodra volume, dataresidentie-eisen of margedruk de operationele kosten waard maken — doorgaans zodra een team agents in productie draait voor meerdere klanten in plaats van één pilot.
Wat dit betekent voor een Nederlands of Vlaams engineeringteam
De les hier is niet "stop met Gemini". Gemini blijft een concurrerend model, Google blijft zelf cloudpartner en investeerder van Discovery Loop, en niemand met verstand van zaken wedt erop dat Google door één leiderschapswissel uit AI stapt. De les is architecturaal: een softwareteam van pakweg 20-50 fte dat agentic workflows voor klanten bouwt, of een mid-marketteam voorbij de pilot in productie, moet de SDK van één leverancier niet rechtstreeks in de bedrijfslogica laten zitten. Een dunne interface — al is het maar de OpenAI-compatibele aanroep van LiteLLM — achter uw gekozen agentframework (LangGraph, Google ADK, Pydantic AI) kost vroeg een dag of twee om toe te voegen, en wordt duur om achteraf in te bouwen zodra drie productteams afhankelijk zijn van leveranciersspecifieke promptformaten en responsvormen. Dat is dezelfde les die we vanuit de architectuurkant trokken in ons stuk over de framework-convergentie van 2026, en dezelfde les die we vanuit de bedrijfskant trokken in waarom AI-strategie niet om het beste model moet draaien — dit is hoe die onafhankelijkheid er in code uitziet, niet alleen in een leveranciersgesprek.
Een minimaal haalbare router, in de praktijk
U heeft geen RouteLLM-niveau van verfijning nodig om het voordeel te pakken. Een verdedigbaar startpunt voor een klein team:
- Plaats één interface tussen uw agentcode en elke modelaanroep, ook als daarachter nu nog maar één leverancier actief is.
- Configureer een tweede leverancier als koude terugval vóórdat u hem nodig heeft, niet nadat een storing het gesprek afdwingt.
- Log timeouts, ratelimieten en contentfilter-afwijzingen als afzonderlijke gebeurtenissen — ze vragen andere geautomatiseerde reacties, niet één generieke nieuwe poging.
- Voeg een circuit breaker toe vóórdat u een tweede routeringsstrategie toevoegt; veerkracht verdient zich eerder terug dan verfijning.
- Beoordeel leveranciersconcentratie op uw architectuurreviewritme, niet alleen op uw contractvervaldatum — Google's reorganisatie viel voor de meeste teams die erdoor verrast werden tussen twee kwartaalreviews in.
Waar u begint
Als uw agents nog rechtstreeks vastzitten aan één modelleverancier, is het in kaart brengen van de interfacegrens een oefening van dagen, geen maanden — en het is de moeite waard om dat te doen vóór de volgende labreorganisatie, niet erna. Lees hoe wij productie-agentarchitectuur aanpakken op onze pagina voor AI-agentontwikkeling.
