Perplexity, een van de snelst groeiende AI-zoekmachines ter wereld, publiceerde onlangs een technisch manifest dat verder reikt dan een productaankondiging. De stelling: de manier waarop AI-agenten vandaag zoeken, is fundamenteel verkeerd ontworpen. Niet een beetje suboptimaal, maar structureel gebrekkig. En de oplossing die het bedrijf voorstelt, herdefinieert wat zoeken in de context van AI eigenlijk betekent.
Dit is niet primair een verhaal over Perplexity. Het is een verhaal over hoe de architectuur van AI-systemen de strategische keuzes van organisaties in de komende jaren zal bepalen.
Wat er aan de hand is
Wanneer een AI-agent vandaag informatie nodig heeft, doet hij in essentie wat een mens zou doen: hij typt een zoekopdracht, wacht op resultaten, leest wat er terugkomt, en verwerkt dat verder. Dat klinkt logisch. Het probleem is dat dit patroon, ontworpen voor menselijke zoekers, botst met de manier waarop AI-agenten werken.
Een menselijke zoeker leest een pagina en onthoudt wat relevant is. Een AI-agent laadt het volledige zoekresultaat in zijn werkgeheugen, het zogenoemde contextvenster. Dat contextvenster is niet oneindig. Bij elke extra zoekvraag stapelt er meer informatie op, waarvan het grootste deel niet relevant is. Tegelijk kan de agent de zoekopdracht niet verfijnen terwijl hij zoekt: hij gooit de vraag over de muur, wacht op een antwoord, en begint pas daarna te filteren.
Het resultaat: trage, ruis-vervuilde resultaten die de capaciteit van de agent opslokken nog voor de eigenlijke taak begint.
De logica van Search as Code
Perplexity's voorstel heet Search as Code, kortweg SaC. De kerngedachte is simpel: in plaats van dat een AI-agent een zoekservice aanroept als een zwarte doos, schrijft de agent zelf code om precies de zoekopdracht te bouwen die de taak vereist.
Een analogie maakt dit concreet. Stel dat u aan een medewerker vraagt om de kwartaalcijfers van duizend leveranciers op te zoeken. In het oude model gaat die medewerker naar de bibliotheek, pakt per leverancier een tijdschrift van de plank, leest het volledig door, noteert het relevante cijfer, legt het tijdschrift terug, en begint opnieuw. Tijdrovend, foutgevoelig, en na een paar uur is het notitieboekje vol met overbodige informatie.
In het SaC-model schrijft de medewerker eerst een instructieset: "zoek al deze duizend leveranciers tegelijk op, haal uitsluitend de alinea's met winstcijfers uit 2025, sorteer op sector, geef me alleen de getallen". Die instructieset wordt uitgevoerd in een beveiligde omgeving, en de medewerker ontvangt een overzichtelijke lijst. Geen overbodige pagina's, geen wachttijden per leverancier, geen vol notitieboekje.
De architectuur achter SaC bestaat uit drie lagen. Het AI-model beslist wat er gezocht moet worden en schrijft de bijbehorende code. Een beveiligde computeromgeving, een sandbox, voert die code onmiddellijk uit. En een gereedschapskist met losse zoekinstrumenten, een SDK, biedt bouwblokken aan: ophalen, rangschikken, filteren, ontdubbelen, samenvatten. De agent combineert die bouwblokken naar behoefte, voor elke taak opnieuw.
Zoeken wordt zo geen vaste dienst maar een variabele capaciteit. Niet een knop die een agent indrukt, maar een instrument dat een agent zelf bespannen kan.
Wat dit betekent voor uw organisatie
De technische details zijn relevant voor de mensen die AI-systemen bouwen. Maar de strategische implicaties gelden voor elke organisatie die AI inzet of wil inzetten. Vijf aandachtspunten.
De kwaliteit van AI-output hangt af van de architectuur, niet alleen van het model. Veel organisaties investeren in betere modellen, betere prompts, betere trainingsdata. Maar de manier waarop een AI-systeem informatie ophaalt en verwerkt, bepaalt mee hoe goed de output is. SaC illustreert dat de 'loodgietersinfrastructuur' achter een AI-agent, de manier waarop hij zoekt en filtert, even kritisch is als het model zelf. Wie AI strategisch wil inzetten, moet ook nadenken over het systeem rondom het model, niet alleen over het model.
Autonome AI-agenten vereisen een andere benadering van kennisbeheer. Wanneer een AI-agent zelf code schrijft en uitvoert om informatie op te halen, verschuift de rol van de organisatie. Het is niet langer voldoende om een kennisbank te bouwen en te hopen dat de AI er het juiste uit distilleert. Organisaties moeten nadenken over welke informatiebronnen beschikbaar zijn, hoe gestructureerd die zijn, en welke toegangsrechten van toepassing zijn. Kennisbeheer is infrastructuur voor AI-agenten geworden, niet alleen een HR-tool.
Snelheid en nauwkeurigheid zijn twee kanten van dezelfde munt. Het SaC-voorbeeld van duizend bedrijven analyseren in één minuut is opvallend. Niet omdat snelheid op zich interessant is, maar omdat het de aard van de taak verandert. Analyses die vandaag te arbeidsintensief zijn om systematisch te doen, worden haalbaar. Concurrentiebewaking, leveranciersanalyse, klantsegmentatie: taken die nu manueel of steekproefsgewijs verlopen, kunnen bij voldoende AI-rijpe infrastructuur automatisch en volledig. De lat voor wat "grondig onderzoek" betekent, wordt opgetrokken.
Afhankelijkheden van zoekproviders verdwijnen niet, ze verschuiven. SaC verplaatst de controle naar het AI-model, maar de onderliggende zoekcapaciteit blijft afhankelijk van providers als Perplexity, Google of interne kennissystemen. Wie vandaag AI-systemen bouwt, doet er goed aan na te denken over welke zoekcapaciteiten strategisch cruciaal zijn en of die afhankelijkheden beheersbaar zijn. Leveranciersonafhankelijkheid in AI gaat over meer dan het model: ook de databronnen en zoekinfrastructuur tellen mee.
Tegelijk stelt SaC een diepere vraag aan de hele zoekindustrie. Google en Bing beheersen vandaag de zoekinfrastructuur voor menselijke gebruikers, maar hun architectuur is ontworpen rond dat uitgangspunt: een gebruiker typt een vraag, krijgt een pagina met links terug. Een SaC-interface is fundamenteel anders, een SDK van bouwblokken waarmee een AI-agent zelf precies de zoekopdracht samenstelt die de taak vereist. Als AI-agenten voor hun informatiebehoeften massaal overstappen op providers die die interface aanbieden, staat dat haaks op hoe Google en Bing zijn gebouwd. De parallel met de overgang van desktop naar mobiel dringt zich op: wie zijn platform niet aanpaste aan het nieuwe gebruikspatroon, verloor marktaandeel aan spelers die dat wel deden. Of Perplexity's SaC-aanpak een nieuwe standaard zet waar Google en Bing niet omheen kunnen, valt vandaag niet met zekerheid te zeggen. Maar de vraag is gesteld, en ze verdient een antwoord.
De grens tussen zoeken en redeneren vervaagt. In het klassieke model zoekt een AI en redeneert daarna. In het SaC-model zijn zoeken en redeneren verweven: de agent redeneert al terwijl hij de zoekopdracht bouwt, en verfijnt die redenering op basis van wat hij terugkrijgt. Dat maakt AI-agenten fundamenteel anders dan de chatbots van de eerste generatie. Organisaties die AI-agenten inzetten voor complexe taken, werken niet meer met een zoekvraag en een antwoord, maar met een denkproces dat door informatie wordt gevoed.
De echte les
Search as Code is technisch interessant. Maar de diepere boodschap is dat AI-systemen volwassen worden op een manier die de meeste organisaties nog niet volledig hebben doorgrond.
De AI-agenten van de komende jaren zijn geen betere zoekmachines. Het zijn systemen die hun eigen gereedschappen bouwen voor elke taak. Die zelf code schrijven om precies de informatie op te halen die ze nodig hebben. Die hun werkwijze aanpassen aan de opdracht, niet aan de beperkingen van een vast platform.
Dat vraagt van organisaties iets anders dan tot nu toe. Niet alleen investeren in AI-tools, maar nadenken over de infrastructuur waarop die tools draaien. Niet alleen de output beoordelen, maar begrijpen welke architectuurkeuzes die output bepalen. Niet alleen de mens begeleiden in het werken met AI, maar ook de systemen ontwerpen die AI-agenten in staat stellen om hun werk goed te doen.
De vraag is niet of uw organisatie AI inzet. De vraag is of de infrastructuur waarop u dat doet, klaar is voor AI-agenten die zichzelf steeds meer tools aanmeten.