AI-agents in drug discovery: waarom je benchmark belangrijker is dan je demo

De volwassen vraag is niet of de agent indrukwekkend lijkt

Bij AI-agents gaat de aandacht vaak naar wat het systeem zelfstandig lijkt te kunnen doen: plannen maken, stappen uitvoeren, resultaten terugkoppelen en opnieuw proberen. Dat is begrijpelijk, maar voor technische teams is het niet de belangrijkste vraag. De volwassen vraag is: meet je of het systeem daadwerkelijk het juiste probleem oplost, of meet je vooral een proxy die prettig in een demo past?

Drug discovery is een nuttige case om die vraag scherp te maken. Het is een domein waarin de uitkomst niet alleen tekstueel, procedureel of cosmetisch is. Een model moet omgaan met complexe structuren, domeinregels, onzekerheid, validatie en fouten die niet altijd direct zichtbaar zijn. Juist daardoor is dit geen goed onderwerp voor grootse claims over AI die onderzoek overneemt. Het is wel een uitstekend onderwerp om te kijken naar werkontwerp: welke taken laat je een systeem uitvoeren, hoe controleer je die taken, en wanneer is een resultaat goed genoeg om verder te gaan?

Voor AI-teams in andere sectoren is dat herkenbaar. Ook in B2B-processen, sales operations, support, vastgoed, automotive of interne kennisprocessen kan een agent een nette output geven terwijl de onderliggende evaluatie te zwak is. Een workflow kan er soepel uitzien, maar alsnog verkeerde aannames gebruiken, uitzonderingen missen of onvoldoende logging hebben. Wie alleen naar de demo kijkt, mist precies het stuk waar betrouwbare toepassing begint.

Een agent is zo sterk als zijn meetlat

In specialistische AI-projecten is de benchmark geen bijzaak. De benchmark bepaalt welk gedrag wordt beloond, welke fouten verborgen blijven en welke optimalisatie het team onbewust stimuleert. Als de meetlat te smal is, kan een systeem beter lijken dan het in de praktijk is. Als de meetlat te algemeen is, weet je niet welke subtaak faalt. En als de meetlat niet aansluit op het echte doel, bouw je vooral een machine die goed scoort op de verkeerde vraag.

Een bekende valkuil is dat teams een makkelijk meetbare proxy verwarren met kwaliteit. Dat kan bij drug discovery gaan over een structurele score die niet alles zegt over bruikbaarheid. In zakelijke AI-projecten kan dezelfde fout optreden bij bijvoorbeeld responstijd, samenvattingslengte, conversiesimulaties of classificatie-accuracy. Zo'n getal is nuttig als signaal, maar gevaarlijk als enige waarheid.

Daarom moet een AI-team vooraf drie dingen vastleggen. Ten eerste: wat betekent goed in deze context, niet in algemene termen maar per subtaak. Ten tweede: welke fouten zijn acceptabel, welke fouten zijn duur en welke fouten mogen nooit automatisch doorgaan. Ten derde: welk bewijs heb je nodig om te bepalen of het systeem leert, gokt of slechts een patroon reproduceert dat toevallig gunstig scoort.

Waarom bewegende context belangrijker is dan een statische input-outputtaak

Een interessant aspect van moderne AI voor moleculaire toepassingen is dat sommige systemen niet alleen kijken naar waar iets past, maar ook naar hoe de omgeving kan meebewegen. Zonder medische of wetenschappelijke conclusies te trekken, is dat als ontwerpprincipe waardevol: veel echte problemen zijn niet statisch. De input verandert, de context reageert, regels schuiven, uitzonderingen ontstaan en eerdere acties beïnvloeden de volgende stap.

Dat geldt ook buiten technische onderzoeksdomeinen. Een leadkwalificatieproces verandert wanneer een klant extra informatie geeft. Een supportproces verandert wanneer er nieuwe productinformatie binnenkomt. Een offerteproces verandert wanneer een uitzondering commerciële of juridische gevolgen heeft. Wie een agent ontwerpt alsof de wereld stil blijft staan, bouwt vaak een workflow die netjes werkt in de testomgeving en kwetsbaar wordt zodra de werkelijkheid beweegt.

Voor Funnel Adviseur is dit precies waar automatisering interessant wordt. Niet omdat elk proces volledig zelfstandig moet draaien, maar omdat je kunt ontwerpen waar context moet worden meegenomen. Soms is een vaste regel genoeg. Soms is retrieval nodig. Soms moet een domeinexpert meekijken. Soms moet het systeem stoppen en expliciet melden dat de informatie onvoldoende is. De kwaliteit zit niet in maximale autonomie, maar in de juiste verdeling tussen automatische voortgang en bewuste rem.

Niet elk AI-probleem is een taalprobleem

AI-teams grijpen snel naar taalmodellen, omdat ze toegankelijk zijn en veel interfaces tekstueel zijn. Dat is logisch, maar niet elk probleem is primair een taalprobleem. Sommige problemen zijn ruimtelijk. Andere zijn visueel, procedureel, statistisch, constraint-based of sterk afhankelijk van simulatie. Een chatbot bovenop een zwak probleemmodel kan dan vooral de illusie van intelligentie geven.

De les uit gespecialiseerde domeinen is dat modelkeuze moet volgen uit de aard van het probleem. Als de kern van je taak draait om 3D-structuur, procesconstraints of validatie door domeinregels, dan is een generieke taalinterface hooguit één laag in het systeem. Het onderliggende model, de datarepresentatie en de evaluatie bepalen dan of de toepassing betekenisvol is.

Voor zakelijke AI-projecten betekent dit dat de eerste workshop niet moet gaan over welke agent-tool het meest populair is. De eerste workshop moet gaan over de taak: wat moet worden waargenomen, wat moet worden voorspeld, wat moet worden gecontroleerd en wat moet worden vastgelegd? Pas daarna kies je of je een LLM, retrieval-laag, regelsysteem, classificatiemodel, planningstool of combinatie nodig hebt.

Gebruik agentic systemen als controlelus, niet als toneelstuk

Een agentic systeem kan waardevol zijn wanneer het een taak opdeelt, tussenresultaten controleert, ontbrekende informatie signaleert en keuzes traceerbaar maakt. Dat is iets anders dan een systeem dat vooral lang nadenkt, veel stappen uitvoert en overtuigend formuleert. Meer stappen zijn niet automatisch betere stappen. Autonomie zonder duidelijke stopregels kan juist extra ruis toevoegen.

Een bruikbare agentic workflow heeft daarom grenzen. Welke subtaken mag de agent zelfstandig uitvoeren? Waar moet een mens expliciet goedkeuren? Welke data mag worden gebruikt? Wanneer moet het systeem stoppen? Wat wordt gelogd? Hoe wordt een fout achteraf geanalyseerd? En hoe voorkom je dat een fout in een vroege stap onzichtbaar doorwerkt in de rest van de keten?

In projecten waar Funnel Adviseur naar automatisering kijkt, is dit vaak het verschil tussen een leuk experiment en een werkbaar systeem. Een agent die een conceptmail schrijft, vraagt om andere controles dan een agent die klantdata verrijkt, een offerte voorbereidt of een beslisadvies maakt. Hoe hoger de impact, hoe belangrijker de audittrail, validatie en taakafbakening worden.

Checklist voor AI-teams die verder willen dan demos

Begin met de vraag of je het echte doel meet of alleen een makkelijke proxy. Een proxy is niet verkeerd, maar moet herkenbaar blijven als proxy. Combineer kwantitatieve scores met domeinreview, foutanalyse en voorbeelden van randgevallen. Leg vast welke score verbetering betekent en welke score alleen cosmetisch beter lijkt.

Breng daarna de bewegende context in kaart. Welke regels, klanten, datasets, uitzonderingen of afhankelijkheden kunnen tijdens het proces veranderen? Welke informatie is stabiel genoeg voor automatisering en welke informatie moet telkens opnieuw worden opgehaald of gevalideerd? Een agent die deze context niet kent, kan niet betrouwbaar beslissen wanneer hij moet doorgaan of stoppen.

Ontwerp vervolgens de controlelus. Splits het werk op in subtaken met een duidelijke input, output, validatiestap en eigenaar. Geef de agent alleen ruimte om te itereren binnen veilige grenzen. Zet menselijke validatie niet als symbolisch vinkje achteraan, maar op de plekken waar de foutkosten hoog zijn of waar domeininterpretatie nodig is.

Tot slot: log genoeg om te kunnen leren. Niet alleen het eindantwoord, maar ook de gebruikte data, tussenkeuzes, afwijzingen, onzekerheden en escalaties. Zonder audittrail kun je een agent niet goed verbeteren. Dan blijft elk incident een losse discussie in plaats van input voor beter systeemontwerp.

Minder demo, meer falsifieerbaarheid

De kern is eenvoudig: een AI-agent wordt pas interessant wanneer je hem kunt tegenspreken. Niet als filosofisch punt, maar operationeel. Kun je zien waarom een stap is gezet? Kun je testen wanneer het systeem faalt? Kun je aantonen dat een verbetering echt het doel raakt? Kun je voorkomen dat een goede presentatie een zwakke evaluatie maskeert?

Voor AI-bouwers en technische beslissers is dat een nuchtere maar krachtige verschuiving. Begin niet met de vraag hoeveel autonomie je kunt geven. Begin met de vraag welke waarneming, voorspelling, controle en falsificatie nodig zijn om het systeem serieus te nemen. Daarna wordt agent-autonomie geen marketinglaag, maar een ontwerpkeuze.

Wie zo naar AI-projecten kijkt, bouwt minder snel een indrukwekkende demo die later uit elkaar valt. Je bouwt eerder een systeem dat klein begint, meetbaar leert en verantwoord kan groeien. Dat is minder spectaculair in de eerste presentatie, maar veel waardevoller voor teams die AI echt in hun werkprocessen willen opnemen.