Ivan Nikitin, CEO en medeoprichter van Fortytwo – interviewreeks

Ivan Nikitin is CEO en medeoprichter van Fortytwo, waar hij technologie voor zwerminferentie ontwikkelt die meerdere AI-modellen laat samenwerken om elkaars werk te beredeneren en te beoordelen. Zijn ervaring omvat games, conversationele AI, generatieve AI en interactieve systemen bij Temporal en Sensorium. In 2011 richtte hij samen met Vlad Larin Temporal op. Larin is nu medeoprichter en CTO van Fortytwo. Daar deed Nikitin ervaring op met zich ontwikkelende populaties van agents en systemen die gespecialiseerde modellen combineren.

Fortytwo bouwt AI-infrastructuur waarmee modellen tijdens inferentie kunnen samenwerken. De Fortytwo Engine gebruikt een Swarm Decoder om een gezamenlijk redeneerproces te sturen terwijl dat zich ontvouwt, met als doel de nauwkeurigheid te verbeteren en onnodige tokenaanmaak bij lange taken te verminderen. Het bedrijf biedt ontwikkelaars een API via Fortytwo Engine en implementatie op locatie via Fortytwo Harbor.

Voordat je Fortytwo mede oprichtte, werkte je jarenlang aan producten rond conversationele AI, generatieve AI en interactieve systemen bij Sensorium en Temporal. Hoe hebben die ervaringen je kijk gevormd op de tekortkomingen van afzonderlijke grote taalmodellen, en hoe hebben ze je uiteindelijk geleid naar de zwermaanpak achter Fortytwo?

Een groot deel van ons team, en ikzelf ook, kwam via games in de AI terecht. Games vormden de bakermat van personal computing en moderne AI: ze zijn de reden dat de GPU bestaat, en games waren de eerste serieuze testomgeving voor reinforcement learning. Gamewerelden boden ons een praktische omgeving om agents te bouwen die konden leren, zich aanpassen en met elkaar concurreren. Bij Temporal, dat ik in 2011 samen met Vlad Larin oprichtte — nu medeoprichter en CTO van Fortytwo — begonnen we met zich ontwikkelende intelligentie: populaties agents die onder selectiedruk met elkaar concurreerden. We wilden weten hoe een populatie meer kon bereiken dan één agent, mits er een goed mechanisme was om de sterkste bijdragen te herkennen en daarop voort te bouwen. Selectie en evaluatie kwamen centraal te staan in onze manier van denken over intelligentie.

Toen transformermodellen opkwamen, breidden we ons werk uit naar conversationele AI en bouwden we een platform voor AI-gestuurde personages die open, niet vooraf uitgeschreven gesprekken konden voeren, met geheugen en persoonlijkheid. Dat was een paar jaar vóór ChatGPT; de modellen waarmee we werkten hadden contextvensters van slechts 512 tot 1.024 tokens. Het was uitgesloten om te verwachten dat één vroeg taalmodel betrouwbaar aan alle uiteenlopende eisen van die ervaring kon voldoen. We moesten een eigen pipeline bouwen met gespecialiseerde modellen, elk met een beperktere taak, plus logica om hun bijdragen te combineren. Het rangschikken en selecteren van reacties werd essentieel om de hele ervaring te laten werken. Daardoor leerden we hoeveel mogelijkheden je kunt ontsluiten door beperkte modellen te combineren in een goed ontworpen systeem.

De andere les was efficiëntie. We leerden dat gespecialiseerde modellen voor duidelijk afgebakende taken efficiënter konden worden getraind en ingezet, zodat we meer konden bereiken met beperkte rekenkracht. Het opschalen van inferentie bleef echter een uitdaging: aan de ene kant waren er gebruikslimieten voor API’s en aan de andere kant de kosten van zelf hosten op grote schaal. Omdat we geen toegang hadden tot de meest geavanceerde rekenkracht, moesten we goed nadenken over hoe we de beschikbare middelen zo efficiënt mogelijk konden benutten. Fortytwo bracht die lessen samen in de visie van zwerminferentie: meerdere modellen, of meerdere instanties van hetzelfde model, dragen bij aan het redeneerproces en beoordelen tegelijk het werk van hun collega’s. Zo is het collectief nauwkeuriger dan elk van zijn afzonderlijke leden.

Fortytwo Engine gebruikt verschillende modellen met open gewichten om één redeneerproces te sturen en elkaars werk te controleren terwijl het antwoord wordt gegenereerd. Hoe verschilt deze aanpak van conventionele multi-agentsystemen, modelensembles of simpelweg meerdere modellen laten draaien en achteraf het beste antwoord selecteren?

Het belangrijkste verschil is dat zwerminferentie rechtstreeks is ingebouwd in de inferentie-engine die we hebben ontwikkeld. We noemen dit de Swarm Decoder: meerdere modeldeelnemers geven voortdurend vorm aan één redeneertraject terwijl dat wordt gegenereerd. Evaluatie en sturing vinden binnen dat proces plaats, waardoor de modellen de richting ervan kunnen beïnvloeden voordat een antwoord af is.

De alternatieven werken anders. Bij een ensemble op antwoordniveau genereren modellen afzonderlijke reacties, die vervolgens worden gerangschikt, geselecteerd of gecombineerd. De oorspronkelijke architectuur van Fortytwo, die in 2025 werd geïmplementeerd, rangschikte voltooide antwoorden onderling. Dat verbeterde de nauwkeurigheid van antwoorden aanzienlijk, maar ging ten koste van extra latentie en rekenoverhead. Veel conventionele multi-agentsystemen verdelen het werk over agents en gebruiken een orkestrator en berichten in natuurlijke taal om hun bijdragen te beheren. Bij die overdrachten kunnen extra inferentieaanroepen en herhaalde context nodig zijn, evenals beslissingen over welke informatie van de ene agent aan de andere wordt doorgegeven. In de Swarm Decoder zijn er geen overdrachten: de deelnemers werken aan één traject en wisselen alleen een oordeel uit over welke richting beter is.

De Swarm Decoder is ontworpen om zwakke aannames tijdens het genereren op te sporen, voordat er veel moeite wordt gestoken in het daarop voortbouwen. Het doel is fouten, terugstappen en onnodige generatie te beperken; de efficiëntiewinst ontstaat wanneer die controle meer werk voorkomt dan ze zelf toevoegt. Daarom is er ook geen latentiestraf: de uitvoering volgt een directere route, waardoor de Engine taken sneller afrondt dan hetzelfde model op zichzelf en daarbij in totaal minder tokens gebruikt, waarbij elk deelnemend model wordt meegerekend.

Je hebt modeldrift tijdens langdurige taken aangemerkt als een groot probleem. Waardoor ontstaat die drift precies, en hoe komt die in de praktijk tot uiting bij toepassingen zoals softwareontwikkeling, onderzoek of autonome AI-agenten?

Drift ontstaat wanneer de context van een model geleidelijk niet meer over de taak gaat. Tijdens een lange uitvoering raakt de context gevuld met de eigen uitvoer van het model, resultaten van hulpmiddelen, bestandsinhoud en nieuwe pogingen. De oorspronkelijke instructie vormt daardoor een steeds kleiner deel van waar het model aandacht aan besteedt. Bovendien maken eerdere fouten van het model inmiddels deel uit van de input waarop het zijn redenering baseert, waardoor fouten zich opstapelen in plaats van elkaar op te heffen. Daar komt bij dat de redeneermodellen van vandaag met reinforcement learning worden getraind om taken af te ronden. Ze leren daarbij sluiproutes die op afronding lijken: een hulpmiddel niet gebruiken, succes uitroepen of samenvatten in plaats van iets te controleren. Wij noemen dat luiheid, en de meest geavanceerde modellen vertonen dat net zo goed als modellen met open gewichten. De onderliggende oorzaak is dat één model geen externe controle heeft. Het beoordeelt zijn eigen werk, en modellen zijn niet goed in nauwkeurige zelfreflectie.

Bij softwareontwikkeling zie je dit wanneer een agent de beschreven bug oplost, maar tegelijk de beperking schendt die je in je eerste bericht hebt genoemd, een test schrijft die zonder moeite slaagt of hetzelfde bestand vier keer leest omdat hij niet meer weet wat hij al heeft geleerd. Bij onderzoek gaat het om een langdurig proces dat afglijdt van de vraag die je stelde naar de vraag die het makkelijkst te beantwoorden is, en eindigt met een algemene samenvatting. Bij autonome agenten is het de kostbare variant: zijpaden, herhaalde aanroepen van hulpmiddelen, terugkrabbelen en een tokenrekening die meerdere keren hoger uitvalt dan nodig was voor de taak.

We kunnen daar cijfers aan hangen. We hebben Qwen 3.8 27B ingezet voor 450 DeepSWE-taken: echte softwareontwikkelingsopdrachten waarbij hulpmiddelen werden gebruikt en de context lang was. Dat deden we één keer met het model op zichzelf en één keer via Fortytwo Engine. Op zichzelf verbruikte het model gemiddeld 16,3 miljoen tokens per uitvoering, in totaal 7,4 miljard. Via de Engine verbruikte hetzelfde model gemiddeld 12,3 miljoen tokens per uitvoering, in totaal 5,6 miljard: 24,7% minder. Bovendien loste het meer taken op: 47,8% tegenover 42,2%. Er veranderde niets aan het model. De vier miljoen tokens per uitvoering die werden bespaard, waren het gevolg van drift: het opnieuw lezen, de nieuwe pogingen en het terugkrabbelen waartoe één model zijn toevlucht moet nemen omdat niemand zijn verkeerde afslagen opmerkt terwijl het ze neemt. De zwerm merkt ze op, zodat het model daar geen tokens aan hoeft te verspillen.

Eerder liet Fortytwo modellen elkaars afgeronde antwoorden beoordelen, terwijl de huidige architectuur ze in staat stelt het redeneerproces te beïnvloeden terwijl dat nog gaande is. Wat hebben jullie van de eerdere aanpak geleerd, en waarom werkt bijsturing in realtime beter?

De architectuur uit 2025 bewees dat we met horizontaal opschalen capaciteiten op het niveau van de meest geavanceerde modellen kunnen bereiken: door meer modellen te laten deelnemen in plaats van achter het grootste model aan te jagen. Een zwerm opengewichtsmodellen die elkaars volledige antwoorden rangschikte, presteerde tot 17 procentpunten beter dan het beste individuele model in de zwerm. Bovendien was de zwerm robuust op manieren waarop één model dat niet is: bij onduidelijke prompts, geïnjecteerde instructies en een meerderheid aan foute antwoorden.

Wat die architectuur niet kon, was ingrijpen. Afgeronde antwoorden rangschikken werkt voor één vraag, maar agentuitvoeringen bestaan uit honderden stappen met daartussen aanroepen van hulpmiddelen. De beslissende fouten ontstaan vroeg en stapelen zich op. Als je pas aan het einde beoordeelt, heeft elk model de volledige tokenkosten al gemaakt en kan de beoordelaar alleen kiezen uit trajecten die al uiteen zijn gelopen. Bovendien betekende dit dat de kosten van de zwerm toenamen met het aantal modellen. Dat is prima voor één moeilijke vraag, maar ongeschikt voor een codeeragent.

Bijsturing in realtime lost beide problemen op. Doorlopend rangschikken zorgt gedurende de hele uitvoering voor selectiedruk, zodat een verkeerde afslag wordt gecorrigeerd zodra die ontstaat, voordat de fout zich verder verspreidt. De zwerm neemt nooit genoegen met een gemakzuchtige poging, want die verliest in de rangschikking van een zorgvuldiger poging. Daarom levert hetzelfde mechanisme ons nu zowel een hogere nauwkeurigheid als een lager tokenverbruik op.

In tests met Qwen 3.8 27B meldt Fortytwo dat het over 450 DeepSWE-uitvoeringen 24,7% minder tokens gebruikt, terwijl de resultaten op zes benchmarks verbeteren. Wat gebeurt er binnen de zwerm waardoor de prestaties verbeteren en tegelijk het tokenverbruik daalt?

De controles van de zwerm brengen beperkte, vaste kosten met zich mee; de kosten van het herstel dat ze voorkomen, nemen toe met de lengte van de taak, omdat elke niet-gecorrigeerde verkeerde afslag alles kost wat daarop voortbouwt. Hoe langer de taak dus duurt, hoe meer er te besparen valt. DeepSWE bevindt zich aan het lange uiteinde van dat spectrum. Daarom komt de besparing uit op bijna een kwart van alle tokens.

De nauwkeurigheid hangt samen met de grilligheid van intelligentie. Verbeteringen van modellen zijn doorgaans ongelijk verdeeld: op het ene gebied redeneren ze op PhD-niveau, terwijl ze op een ander gebied volkomen onzin produceren. Dat komt doordat finetuning, RL en andere vormen van training na de voortraining een model verbeteren op basis van de data waarop het is getraind, en de winst afneemt naarmate echte taken verder van die data afstaan. De Swarm Decoder verandert niets aan het model. Hij verbetert de redenering zelf, op consistente wijze. De zes benchmarks zijn dus niet zes domeinen waarvoor we het model hebben geoptimaliseerd; het zijn zes plekken waar we hetzelfde hebben gemeten. Het model is in het algemeen slimmer en aandachtiger. Doordat andere modellen elke stap controleren, lijkt het alsof het veel meer moeite doet voor je taak. Daarom kunnen we de Engine ook aanbieden tegen het tarief per token van het basismodel: de klant betaalt niet voor een groter budget, maar voor een kortere weg naar het juiste antwoord.

AI-ontwikkelaars maken zich steeds meer zorgen over de inferentiekosten, nu redeneermodellen langere tokenreeksen genereren. Denkt u dat het efficiënter maken van het redeneerproces zelf uiteindelijk net zo belangrijk kan zijn als individuele modellen kleiner, sneller of goedkoper maken?

Ja, en ik zou zelfs willen stellen dat dit nu al de grootste hefboom is. Door modellen kleiner, sneller en goedkoper te maken, daalt de prijs per token. Maar niemand koopt tokens. Mensen willen een afgeronde taak, en in het tijdperk van agents is het aantal tokens per taak enorm toegenomen: een redeneermodel verbruikt bij een echte programmeertaak miljoenen tokens, waarvan een groot deel wordt besteed aan het opnieuw doorlopen van eerdere stappen. Een verlaging van het aantal tokens per taak met 25% is precies evenveel waard als een prijsverlaging van 25%, maar komt daar nog bovenop bij elke verbetering in hardware, kwantisering en kernels. Bovendien kunnen we dit toepassen op elk model met open gewichten op de markt.

De sector heeft drie hefbomen. Betere modellen, waarvoor training nodig is en die duur is. Goedkopere tokens, waarvoor hardware en het aanbieden van modellen nodig zijn; op dat vlak groeien de mogelijkheden naar elkaar toe, omdat iedereen dezelfde GPU’s heeft. En minder tokens per taak, wat afhangt van de manier waarop inferentie wordt uitgevoerd en vrijwel onontgonnen terrein is. Tot nu toe betekende opschaling grotere modellen en langere redeneerketens, waarbij één model in beide gevallen alles in één traject moet doen. Wij denken dat de volgende ontwikkelingsrichting collectief is: meerdere modellen die samen redeneren, met het beoordelingsvermogen verdeeld over die modellen, zodat het traject zelf korter en betrouwbaarder wordt. Dat is een andere vorm van opschaling dan meer parameters of meer rekenkracht tijdens inferentie, en daarop zetten wij in. Wij noemen het: peers in plaats van parameters.

Fortytwo Engine is compatibel met de OpenAI-API en draait op modellen met open gewichten. Hoe belangrijk was compatibiliteit met bestaande AI-ontwikkelomgevingen, en hoe eenvoudig kunnen ontwikkelaars een toepassing overzetten van een conventionele API met één model naar een zwermarchitectuur?

Compatibiliteit is essentieel. Het ecosysteem van agents — programmeeragents, uitvoeringsomgevingen, frameworks en evaluatietools — is gebouwd rond de structuur van de OpenAI-API. Voor ontwikkelaars die Fortytwo Engine gebruiken, is de overstap dus vergelijkbaar met de overstap naar een andere inferentieprovider: voor een compatibele app, agent, uitvoeringsomgeving of dienst volstaat doorgaans één wijziging in de configuratie: het eindpunt, de API-sleutel en de modelkeuze.

Wat verandert, is het gedrag, niet de integratie. Het verschil blijkt tijdens lange agentische taken, waarbij het tokenverbruik en de nauwkeurigheid bij de eerste poging de kosten bepalen: via Engine rondt hetzelfde model taken sneller af, met minder tokens, en voert het meer taken correct uit. Mijn advies is om het aan te pakken zoals elke modelwissel: voer de evaluatie uit die u al voor uw agent gebruikt, vergelijk het aantal tokens per taak en het slagingspercentage, en houd de optie die het beste presteert.

Bedankt voor het geweldige interview. Lezers die meer willen weten over zwerminferentie en hoe evaluatie door peers de efficiëntie van redeneren kan verbeteren, kunnen terecht bij Fortytwo.