Wat Agent Seer werkelijk bewijst over het automatisch evalueren van tool-gebruikende AI-agents

Wetenschappelijk oordeel

Agent Seer adresseert een reëel en urgent probleem: organisaties kunnen sneller nieuwe tools en MCP-servers aansluiten dan zij betrouwbare evaluatiescenario's kunnen ontwerpen. De paper introduceert daarom een geautomatiseerde pijplijn die uitsluitend vanuit een Model Context Protocol-specificatie complete testharnassen genereert, inclusief gebruikersvragen, verwachte toolcalls, argumenten, synthetische toolresultaten en multi-turndialogen.

De curatoriële samenvatting van DAIR.AI reduceert dit aantrekkelijk tot: "the spec is the dataset". Dat is communicatief sterk, maar wetenschappelijk te stellig. Een specificatie is geen empirische dataset van werkelijk gebruikersgedrag, operationele toestanden, uitzonderingen, autorisatiebeslissingen en bedrijfsuitkomsten. Zij is hoogstens een gestructureerde generatieve prior over mogelijke handelingen.

Mijn oordeel is daarom:

Beoordelingsvraag	Oordeel
Methodologische originaliteit	Hoog
Interne consistentie van de gegenereerde artefacten	Redelijk sterk
Bewijs dat scenario's operationeel realistisch zijn	Onvoldoende
Bewijs dat scores echte agentprestaties voorspellen	Niet geleverd
Bruikbaarheid als cold-startgenerator	Hoog
Bruikbaarheid als zelfstandige release gate	Laag
Geschiktheid voor gereguleerde productieomgevingen	Alleen na aanvullende assurance
Eindadvies	PROCEED_WITH_CONSTRAINTS

Agent Seer moet worden beschouwd als een benchmarkcompiler die testkandidaten produceert, niet als een autonome waarheidsmachine die kan bepalen of een agent veilig en correct functioneert.

Het fundamentele probleem: agents ontwikkelen sneller dan hun evaluaties

Tool-gebruikende agents verschillen principieel van klassieke chatbots. Hun kwaliteit wordt niet alleen bepaald door het gegenereerde antwoord, maar door een keten van beslissingen:

• Moet er überhaupt een tool worden gebruikt?
• Welke tool past bij de intentie?
• In welke volgorde moeten tools worden aangeroepen?
• Welke argumenten zijn vereist?
• Welke waarden moeten uit eerdere resultaten worden overgenomen?
• Welke autorisatie is nodig?
• Is de uiteindelijke toestand correct?
• Heeft de agent het doel bereikt zonder beleid of veiligheidsgrenzen te schenden?

Handmatig samengestelde benchmarks zijn duur, vereisen domeinexpertise en verouderen wanneer API's veranderen. Vooral bij nieuwe, interne of snel evoluerende tools ontbreekt vaak trainings- en evaluatiedata. De auteurs noemen dit het cold-startprobleem van agent-evaluatie.

Dit probleem is groter dan een tekort aan testvragen. Een bruikbaar agentscenario vereist een samenhangende relatie tussen gebruikersintentie, toolselectie, argumentwaarden, tussenresultaten, toestandsoverdracht en uiteindelijk resultaat. Juist die samenhang is moeilijk uit een statische API-beschrijving af te leiden.

Agent Seer stelt dat MCP-specificaties voldoende semantische informatie bevatten om deze eerste evaluatielaag automatisch te genereren. Dat is de centrale hypothese van de paper.

Hoe Agent Seer werkt

Een MCP-toolspecificatie bevat doorgaans een toolnaam, een natuurlijke-taalbeschrijving en een JSON Schema voor invoerparameters. In de actuele MCP-specificatie kunnen tools daarnaast een uitvoerschema en gedragsannotaties bevatten.

Agent Seer transformeert deze specificaties in vier stappen:

S --I_θ→ Ŝ --G_θ→ Q --M_θ→ O --X_θ→ H

Hierbij staat:

• S voor de oorspronkelijke toolspecificatie;
• I_θ voor semantische interpretatie;
• G_θ voor scenariogeneratie;
• M_θ voor het synthetiseren van toolresultaten;
• X_θ voor multi-turnexpansie;
• H voor het uiteindelijke evaluatieharnas.

Fase 1: semantische interpretatie

De ruwe specificatie wordt verrijkt met een functionele beschrijving, semantische rollen van parameters, primaire use-cases en organisatorische context.

Dit is nuttig wanneer een toolspecificatie technisch correct maar semantisch arm is. Tegelijkertijd ontstaat hier de eerste epistemische verschuiving: organisatorische context die niet expliciet in de specificatie staat, wordt door het taalmodel ingevuld vanuit zijn vooraf aangeleerde kennis.

Fase 2: scenariogeneratie

Agent Seer genereert eenvoudige en complexe bedrijfsscenario's. Ieder scenario bevat:

• een gebruikersdoel;
• een geordende reeks toolcalls;
• concrete argumentwaarden;
• een toelichting op de gekozen workflow;
• een vervolginteractie.

Het onderscheid tussen eenvoudig en complex wordt door promptinstructies gerealiseerd, niet door formele structurele eisen. De auteurs erkennen zelf dat hierdoor niet gegarandeerd is dat de uiteindelijke scenario's daadwerkelijk verschillende complexiteitsklassen vertegenwoordigen.

Fase 3: synthetische toolresultaten

Voor iedere verwachte toolcall genereert het model een fictief resultaat. Wanneer de specificatie voorbeeldresultaten bevat, kan het model daarvan de structuur overnemen. Zonder voorbeelden wordt het resultaat uitsluitend afgeleid uit toolnaam, beschrijving en parameterschema.

In het beschreven experiment bevatten geen van de zeven gebruikte MCP-specificaties voorbeeldresultaten. Alle 871 gegenereerde toolresultaten kregen daarom de laagste groundingclassificatie.

Fase 4: multi-turnexpansie

Langere workflows worden bij natuurlijke faseovergangen opgesplitst. Een eerste beurt kan bijvoorbeeld informatie verzamelen, waarna een tweede beurt voortbouwt op een concreet ID, statusveld of aantal uit een synthetisch toolresultaat.

Het uiteindelijke harnas bevat onder meer:

• de gebruikersprompt;
• de verwachte tools en argumenten;
• synthetische toolresultaten;
• de multi-turnconversatie;
• een voor de geëvalueerde agent verborgen oracle.

De paper noemt dit oracle held-out omdat de agent het niet ziet. Epistemisch is het echter niet onafhankelijk: hetzelfde generatieve proces produceert zowel het scenario als het antwoord waarmee dat scenario later wordt beoordeeld.

Wat is hier werkelijk nieuw?

De afzonderlijke generatietechnieken zijn niet fundamenteel nieuw. De auteurs positioneren hun bijdrage zelf vooral in de architecturale combinatie van:

• spec-gebaseerde generatie;
• semantische verrijking;
• schema-gevalideerde tussenartefacten;
• synthetische toolresultaten;
• mock-data-gestuurde multi-turndialogen;
• een backend-onafhankelijk harnasformaat.

De kracht zit dus niet in een nieuwe theorie van agentgedrag, maar in het systematiseren van de weg van specificatie naar herbruikbaar evaluatieartefact.

Dat is bedrijfsmatig relevant. Een organisatie zou bij iedere wijziging van een MCP-specificatie automatisch nieuwe testkandidaten kunnen laten genereren. Daarmee wordt evaluatie onderdeel van de API- en agentlevenscyclus, in plaats van een eenmalige handmatige exercitie.

Maar automatisering van testproductie is nog geen automatisering van waarheid.

De gerapporteerde resultaten

De experimenten gebruiken zeven MCP-specificaties uit verschillende domeinen: Illustrator, Selenium, Redis, Git, Elasticsearch, Slack en Filesystem. Deze bevatten samen 250 tools. Scenario's werden gegenereerd met Gemini 2.5 Flash Lite. Gemini 2.5 Flash fungeerde als primaire beoordelaar, waarna het corpus opnieuw werd beoordeeld door Qwen3.5-122B.

Maatstaf	Gerapporteerd resultaat
MCP-specificaties	7
Tools in de specificaties	250
Gegenereerde scenario's	337
Evaluatierecords	391
Succesvol geëxpandeerde multi-turnscenario's	54
Multi-turnrendement	16,0%
Synthetische toolcalls	871
Toolcalls met lage grounding	871
Gemiddelde tool-calling-score	0,911
Gemiddelde coherentiescore	0,855
Perfecte tool-calling-records	31,7%
Records onder 0,5	2,3%
Perfecte argumentscore	42%
Partiële argumentscore	57%

De gemiddelde tool-calling-score had een gerapporteerd 95%-bootstrapinterval van 0,897 tot 0,925. De coherentiescore had een interval van 0,838 tot 0,872.

Multi-turnexpansie slaagde bij 30,8% van de complexe scenario's, maar slechts bij 2,8% van de eenvoudige scenario's.

De scores per MCP laten aanzienlijke verschillen zien:

MCP	Tools	Tool calling	Coherentie	Gemiddelde workflowlengte
Illustrator	64	0,898	0,855	3,3
Selenium	56	0,935	0,850	9,7
Redis	47	0,966	0,902	1,3
Git	33	0,857	0,757	2,2
Elasticsearch	20	0,930	0,902	1,9
Slack	16	0,886	0,938	1,4
Filesystem	14	0,876	0,825	2,0

Redis behaalt de hoogste tool-calling-score, terwijl Git de laagste tool-calling- en coherentiescores heeft. Slack scoort relatief hoog op coherentie, maar lager op tool calling. Daarmee blijken technische correctheid en conversationele kwaliteit gedeeltelijk onafhankelijke constructen.

De sterkste bevinding: argumentwaarden zijn de zwakke plek

Het meest overtuigende resultaat is niet de gemiddelde score van 0,911. Het is de lokalisatie van fouten naar de inhoud van argumenten.

De toolnoodzaak was in 98% van de records perfect. Toolselectie was in 77% perfect en volgorde in 71% van de relevante multi-toolgevallen. Bij argumenten was slechts 42% perfect. Verkeerde waarden kwamen veel vaker voor dan verkeerde parameternamen, typen of formaten.

Deze bevinding bleef zichtbaar bij beide beoordelingsmodellen:

Argumentprobleem	Gemini	Qwen 3.5
Onjuiste waarde	240	252
Onvoldoende relevant	53	54
Formaatfout	46	58
Typefout	46	42
Ontbrekend argument	23	33
Onjuiste parameternaam	16	21

De dominantie van verkeerde waarden is vier tot vijf keer zo groot als het volgende fouttype.

Dit sluit aan bij bredere onderzoeksresultaten. FuncBenchGen vond dat sterke modellen syntactisch correcte calls kunnen uitvoeren, maar verouderde of verkeerde waarden tussen stappen doorgeven. ToolWeave probeert dit expliciet te mitigeren door voor iedere parameter de herkomst bij te houden.

Voor enterprise agents is dit cruciaal. Een agent die de correcte functie aanroept met een verkeerde tenant-ID, verkeerde branchnaam, verkeerd dossiernummer of verkeerde bewaartermijn kan syntactisch perfect en operationeel rampzalig zijn.

De centrale epistemische fout: input uit een specificatie is niet hetzelfde als kennis uit een specificatie

De paper toont aan dat Agent Seer alleen een specificatie als expliciete invoer nodig heeft. Zij toont niet aan dat alle gebruikte kennis uit die specificatie afkomstig is.

Het generatieve model beschikt al over omvangrijke vooraf aangeleerde kennis over Git, Redis, Slack, Selenium en algemene bedrijfsprocessen. Dit wordt zichtbaar in drie Git-scenario's waarin het model bestaande Git-commando's genereert die niet in de MCP-specificatie voorkwamen: fetch, revert en filter-repo. De auteurs duiden dit terecht als pretraining leakage.

Daarmee moet onderscheid worden gemaakt tussen:

spec-only input  ≠  spec-only information

De bewering dat de specificatie zelf voldoende semantische informatie bevat, is pas overtuigend bewezen wanneer dezelfde kwaliteit wordt bereikt bij:

• fictieve tools die niet in trainingsdata kunnen voorkomen;
• semantisch nieuwe domeinen;
• willekeurig hernoemde tools;
• synthetische API's met onbekende conventies;
• modellen met verschillende kennisprofielen.

Een sterk falsificatie-experiment zou de oorspronkelijke toolnamen vervangen door neutrale identifiers, bijvoorbeeld tool_17 en tool_42, terwijl de schema's gelijk blijven. Als de kwaliteit vervolgens sterk daalt, was niet de specificatiestructuur maar vooraf aangeleerde domeinkennis de dominante informatiebron.

Het oracleprobleem: een gegenereerd antwoord wordt zijn eigen waarheid

De kwaliteitsevaluatie kan formeel worden weergegeven als:

J_φ(S,H) → (TC, Coh)

Hier beoordeelt taalmodel J_φ of harnas H plausibel en coherent is ten opzichte van specificatie S.

Maar organisaties hebben uiteindelijk een andere functie nodig:

V(H,E,P,U) → (taaksucces, veilige toestand, beleidconformiteit)

Hierbij vertegenwoordigt:

• E de feitelijke uitvoeringsomgeving;
• P het geldende beveiligings- en autorisatiebeleid;
• U werkelijke gebruikersdoelen en gebruikspatronen.

Agent Seer meet vooral interne plausibiliteit. Het meet niet of:

• de opgegeven toolreeks werkelijk uitvoerbaar is;
• de synthetische outputs overeenkomen met echte serveroutputs;
• afhankelijkheden tussen calls kloppen;
• de eindtoestand correct is;
• autorisatie en functiescheiding worden gerespecteerd;
• de taak daadwerkelijk is afgerond;
• een menselijke domeinexpert het scenario realistisch vindt.

De paper erkent dit expliciet: scenario's fungeren zowel als gegenereerd product als als oracle, en de auteurs positioneren het systeem daarom als proxy-evaluatie in plaats van als definitieve ground truth.

Een oracle dat uit hetzelfde generatieve proces voortkomt als het scenario kan drie soorten fouten reproduceren:

• Gedeelde omissie: zowel scenario als oracle vergeten dezelfde noodzakelijke stap.
• Gedeelde hallucinatie: beide nemen een niet-bestaande capability aan.
• Gedeelde normfout: beide beschouwen een onveilige of ongeautoriseerde workflow als correct.

Dit creëert het risico op een epistemische false green: het testsysteem beoordeelt een agent als correct omdat de agent overeenkomt met een eveneens onjuiste synthetische verwachting.

Overeenstemming tussen beoordelaars is nog geen waarheid

Het Qwen-model en het Gemini-model zijn het grotendeels eens over tool calling. De gepaarde correlatie bedraagt ongeveer 0,79 en de gemiddelde tool-calling-scores verschillen nauwelijks. Voor coherentie is het beeld zwakker: Qwen scoort gemiddeld ongeveer 0,16 lager en de gepaarde correlatie bedraagt slechts 0,42.

Dit is nuttig bewijs voor beoordelaarsrobuustheid, maar niet voor criteriumvaliditeit.

Twee thermometers die steeds dezelfde afwijking vertonen, zijn betrouwbaar ten opzichte van elkaar, maar kunnen beide verkeerd gekalibreerd zijn. Op dezelfde manier toont overeenstemming tussen twee taalmodellen aan dat zij vergelijkbare patronen herkennen. Zij toont niet aan dat die patronen overeenkomen met menselijke praktijk of operationele waarheid.

Daarvoor is ten minste één onafhankelijke ankerbron nodig:

• beoordeling door domeinexperts;
• productielogs of realistische gebruikssimulaties;
• executie tegen een echte of deterministische testomgeving;
• verificatie van de uiteindelijke systeemtoestand;
• vergelijking met handmatig gevalideerde scenario's.

EigenData rapporteert bijvoorbeeld een outcome-aware evaluatiemethode waarbij database-eindtoestanden worden beoordeeld in plaats van alleen tooltrajecten. Die aanpak correleerde volgens de auteurs beter met menselijke oordelen over functionele correctheid. MCP-AgentBench gebruikt operationele MCP-servers en outcome-georiënteerde taakbeoordeling. Deze methoden leveren precies de externe ankers die Agent Seer nog mist.

De statistische claim over schemacomplexiteit is te sterk geformuleerd

De paper rapporteert op MCP-niveau:

• gemiddeld aantal parameters tegenover tool-calling-score: r = -0,60;
• aandeel optionele parameters tegenover tool-calling-score: r = -0,66;
• aantal tools tegenover tool-calling-score: r = +0,40.

Deze verbanden zijn gebaseerd op slechts zeven MCP-specificaties. De paper zelf waarschuwt daarom terecht dat het om observaties binnen deze steekproef gaat, niet om universele wetmatigheden. De DAIR.AI-formulering dat schemacomplexiteit kwaliteit "voorspelt" gaat verder dan het beschikbare bewijs.

Met de standaard tweezijdige Pearson-toets:

t = r · √((n-2) / (1-r²))

en n = 7, volgt bij benadering:

Verband	r	Herberekende p-waarde
Gemiddeld aantal parameters	-0,60	0,154
Aandeel optionele parameters	-0,66	0,107
Aantal tools	+0,40	0,374

Geen van deze MCP-niveauverbanden bereikt de conventionele grens van 0,05. Dat betekent niet dat het effect afwezig is. Het betekent dat de dataset te klein is om de sterkte van het verband betrouwbaar te schatten.

De auteurs rapporteren daarnaast toolniveau-analyses over 222 gebruikte tools, met kleinere maar statistisch significante correlaties. Dat grotere aantal observaties lost het probleem echter niet volledig op, omdat tools zijn genest binnen slechts zeven MCP-suites.

Tools binnen dezelfde suite delen documentatiestijl, domein, naamgeving, generatorcontext en schemaconventies. Een analyse die iedere tool als volledig onafhankelijke observatie behandelt, riskeert pseudo-replicatie.

Een geschikter model zou zijn:

TC_ij = β_0 + β_1·C_ij + u_j + ε_ij

waarbij C_ij de complexiteit van tool i binnen MCP j representeert en u_j een suite-specifiek random effect is.

Daarbij moeten ten minste de volgende confounders worden meegenomen:

• kwaliteit en lengte van de toolbeschrijving;
• bekendheid van het domein in de trainingsdata;
• semantische overlap tussen tools;
• statefulness;
• workflowlengte;
• aanwezigheid van voorbeelden;
• naamgevingskwaliteit;
• nesting en conditionele schema's;
• autorisatievereisten;
• ambiguïteit van optionele velden.

Bovendien bevatten de zeven suites samen 250 tools, terwijl de toolniveau-analyse 222 gebruikte tools omvat. De 28 niet-gedekte Illustrator-tools zijn dus niet meegenomen. Wanneer moeilijk te genereren tools vaker ongedekt blijven, kan selectie van alleen gebruikte tools het effect onderschatten of vertekenen. De paper rapporteert voor Illustrator inderdaad slechts 36 gebruikte tools van de 64 beschikbare tools.

"Volledige coverage" betekent slechts dat iedere tool één keer verschijnt

Agent Seer bereikt 100% tooldekking voor suites met 14 tot 56 tools. Voor Illustrator, met 64 tools, wordt 56% bereikt.

Tooldekking is echter de zwakste vorm van coverage. Zij zegt alleen dat een toolsymbool minimaal één keer voorkomt. Zij zegt niets over:

• verplichte en optionele parametercombinaties;
• minimale, maximale en ongeldige waarden;
• oneOf, anyOf en conditionele branches;
• volgordeafhankelijkheden;
• toestandsovergangen;
• foutafhandeling en retries;
• time-outs en gedeeltelijke resultaten;
• autorisatiescopes;
• cross-tenantgrenzen;
• idempotentie;
• compensating transactions;
• vijandige tooloutputs;
• herstel na verlopen state handles.

De paper rapporteert 781 unieke toolco-occurrenceparen. Op basis van de omvang van de zeven afzonderlijke suites bestaan er maximaal 5.566 ongeordende toolparen binnen suites. De 781 geobserveerde paren vertegenwoordigen ongeveer 14% van die ruwe combinatorische bovengrens. Veel theoretische combinaties zijn uiteraard semantisch zinloos, waardoor 14% geen kwaliteitsmaatstaf is. De berekening laat wel zien waarom 100% tooldekking niet mag worden gelijkgesteld aan workflowdekking.

Voor agent-assurance zijn minimaal verschillende coveragebegrippen nodig:

Coveragelaag	Voorbeeldmaatstaf
Tool coverage	Percentage tools minimaal eenmaal gebruikt
Schema branch coverage	Afgedekte oneOf, anyOf, conditionals en enums
Parameter boundary coverage	Geldige en ongeldige grenswaarden
Dependency edge coverage	Afgedekte gegevensstromen tussen calls
State transition coverage	Afgedekte begin-, tussen- en eindtoestanden
Error coverage	Validatiefouten, time-outs, partial failures en retries
Policy coverage	Scopes, rollen, toestemming en functiescheiding
Adversarial coverage	Injecties, manipulatieve outputs en schema-aanvallen
Outcome coverage	Correct bereikte bedrijfsuitkomsten
Drift coverage	Gedrag over opeenvolgende specificatieversies

Multi-turn is nog geen bewezen sterke eigenschap

Van de 337 scenario's konden slechts 54 scenario's succesvol worden uitgebreid tot meerdere beurten. Dat is 16%. De steekproef is bovendien sterk geselecteerd: complexe scenario's worden veel vaker uitgebreid dan eenvoudige scenario's.

Daar komt een fundamenteler probleem bij. De synthetische outputs van opeenvolgende calls worden onafhankelijk gegenereerd. Daardoor kan een ID uit call 1 afwijken van het ID dat call 2 verwacht. De auteurs noemen het ontbreken van cross-call referential integrity expliciet als beperking.

Dat raakt precies het hart van multi-turnagentgedrag. In echte workflows moeten agents:

• identifiers foutloos doorgeven;
• wijzigingen in toestand onthouden;
• omgaan met verlopen handles;
• partiële resultaten verwerken;
• eerdere aannames herzien;
• autorisatie opnieuw evalueren;
• herkennen wanneer een vorige call niet het verwachte effect had.

Een dialoog waarin de tekst logisch doorloopt, maar de onderliggende toestand niet kan bestaan, is conversationeel plausibel en operationeel ongeldig.

Schemacomplexiteit is meer dan het aantal parameters

De paper operationaliseert complexiteit vooral via het gemiddelde aantal parameters en het aandeel optionele parameters. Dat was al een beperkte benadering. Door de MCP-specificatie van 28 juli 2026 is deze beperking nog relevanter geworden.

MCP-tools kunnen inmiddels de volledige expressiviteit van JSON Schema 2020-12 gebruiken, waaronder:

• oneOf, anyOf en allOf;
• conditionele if, then en else;
• $ref en $defs;
• complexe uitvoerschema's;
• willekeurige gestructureerde JSON-resultaten.

De officiële richtlijnen waarschuwen bovendien voor onbeperkte schemadiepte, validatietijd en externe referenties.

Een robuustere complexiteitsrepresentatie is daarom een vector:

C_schema = (D, B, R, V, H, P, T)

waarbij:

• D staat voor nesting depth;
• B voor branch- en conditionele complexiteit;
• R voor de structuur van referentiegrafen;
• V voor de semantische omvang van mogelijke waarden;
• H voor cross-call state-handle-afhankelijkheden;
• P voor autorisatie- en policykoppeling;
• T voor temporele voorwaarden, time-outs en verloop.

Twee tools met ieder vijf parameters kunnen radicaal verschillen. Een platte zoekfunctie met vijf strings is niet vergelijkbaar met een tool waarin drie parameters conditioneel verplicht worden, één parameter naar een objectgrafiek verwijst en een ander veld een tenantgebonden state handle bevat.

De veiligheidsparadox: wanneer de specificatie de dataset wordt, wordt zij ook een aanvalsvlak

Agent Seer behandelt toolbeschrijvingen en schema's als semantische input voor een taalmodel. Daarmee wordt een MCP-specificatie niet langer alleen machineleesbare metadata. Zij wordt indirect ook een instructiekanaal.

De officiële MCP-specificatie stelt dat toolannotaties als onbetrouwbaar moeten worden beschouwd wanneer zij niet van een vertrouwde server afkomstig zijn. Zij schrijft daarnaast invoervalidatie, toegangscontrole, rate limiting, outputvalidatie en menselijke bevestiging voor gevoelige handelingen voor.

Een aanvaller of gecompromitteerde MCP-server kan proberen:

Dreiging	Mogelijk effect	Vereiste beheersmaatregel
Promptinjectie in toolbeschrijvingen	Manipulatie van gegenereerde scenario's of evaluatiecriteria	Strikte scheiding tussen data en instructies, contentfilters, allowlists
Benchmark poisoning	Onveilige acties worden als normaal of correct gepresenteerd	Onafhankelijke policy-engine en menselijke validatie
Schema bomb	Uitputting van geheugen, rekentijd of validatorcapaciteit	Diepte-, omvang- en tijdslimieten, geen ongecontroleerde externe $ref
Oracle poisoning	Agent en synthetisch oracle delen dezelfde fout	Onafhankelijke state- en outcome-oracles
Autorisatiewitwassen	Correct toolpad, maar met verkeerde scope of identiteit	Scope-, audience-, subject- en tenantvalidatie
Privacy leakage	Mockdata bevat realistische maar gevoelige of herleidbare waarden	Volledig synthetische data, DLP-controles, geen productiecontext
Tool shadowing	Een gelijknamige kwaadaardige tool vervangt een vertrouwde tool	Namespacing, serveridentiteit, cryptografische provenance

Een bijzonder risico is benchmark laundering. Een kwaadaardige specificatie kan risicovol gedrag zo omschrijven dat de generator het als legitieme workflow opneemt. Wanneer de beoordelaar dezelfde specificatie als context gebruikt, kan het gedrag vervolgens een hoge score krijgen. De specificatie legitimeert dan haar eigen misbruik.

Ook autorisatie moet onderdeel zijn van de scenariosemantiek. Een toolcall is niet correct omdat naam en argumenten kloppen. De call moet worden uitgevoerd met het juiste subject, de juiste audience, minimale scopes, geldige toestemming, passende tenantbinding en een correct tokenstadium. MCP-securityrichtlijnen verbieden token passthrough waarbij tokens zonder juiste audiencevalidatie naar achterliggende diensten worden doorgestuurd.

Een zeslagige validiteitsarchitectuur

Agent Seer moet worden geplaatst in een bredere validiteitsstack:

Laag	Centrale vraag	Dekking door Agent Seer
1. Syntactische validiteit	Voldoen calls en argumenten aan het schema?	Redelijk sterk
2. Semantische validiteit	Passen tools en waarden bij de gebruikersintentie?	Gedeeltelijk, via LLM-beoordeling
3. Toestandsvaliditeit	Kloppen afhankelijkheden, IDs en eindtoestanden?	Zwak
4. Policyvaliditeit	Zijn identiteit, scope, toestemming en functiescheiding correct?	Niet aangetoond
5. Outcomevaliditeit	Is het bedrijfsdoel werkelijk en veilig bereikt?	Niet aangetoond
6. Ecologische validiteit	Vertegenwoordigen scenario's reëel gebruik, risico en drift?	Niet aangetoond

De paper levert vooral een bijdrage aan laag 1 en een eerste benadering van laag 2. Productie-assurance vereist alle zes lagen.

Een hoge gemiddelde score mag daarbij niet compenseren voor een kritieke fout. De besluitlogica moet conjunctief en fail-closed zijn:

GO = C_schema ∧ C_state ∧ C_policy ∧ C_outcome ∧ C_human

Een agent die 99% correct scoort maar in 1% van de gevallen een cross-tenantactie uitvoert, is niet "gemiddeld goed". Hij faalt een harde veiligheidsvoorwaarde.

Van Agent Seer naar een enterprise-grade benchmarkfabriek

De juiste implementatie is geen enkelvoudige generator, maar een meerlagige assuranceketen.

Gate 0: vertrouwde specificatie-inname

Iedere specificatie krijgt:

• een cryptografische hash;
• server- en uitgeversidentiteit;
• versienummer;
• herkomstregistratie;
• goedgekeurde registry-status;
• statische analyse van beschrijvingen en schema's;
• detectie van promptinjectie;
• begrensde $ref-resolutie;
• een wijzigingsdiff ten opzichte van de vorige versie.

Gate 1: genereren van testkandidaten

Een Agent Seer-achtige generator produceert:

• positieve scenario's;
• negatieve scenario's;
• grenswaarden;
• fout- en recoveryscenario's;
• eenvoudige en complexe workflows;
• security- en autorisatiescenario's;
• scenario's gericht op gewijzigde schemadelen.

Gebruik meerdere seeds en bij voorkeur meerdere generatorfamilies. Hiermee wordt generatorbias meetbaar.

Gate 2: deterministische schemavalidatie

Een klassieke validator controleert:

• toolnamen;
• verplichte velden;
• types;
• formaten;
• enums;
• conditions;
• referenties;
• onbekende velden;
• grenswaarden.

Waar deterministische validatie mogelijk is, hoort geen LLM als oracle te fungeren.

Gate 3: stateful simulatie

Een simulator of digital twin beheert:

• objectidentiteiten;
• versie- en tenantcontext;
• state handles;
• tussenresultaten;
• fouttoestanden;
• transacties;
• side effects;
• compensatieacties.

Alle vervolgargumenten moeten herleidbaar zijn naar gebruikersinput, configuratie of eerdere tooloutput. Dit is parameterprovenance.

Gate 4: policy- en autorisatievalidatie

Een onafhankelijke policy-engine bepaalt:

• welke identiteit mag handelen;
• welke scope nodig is;
• welke acties expliciete toestemming vereisen;
• welke gegevensgrenzen gelden;
• wanneer een human-in-the-loop verplicht is;
• welke acties nooit mogen worden uitgevoerd.

Het generatieve model mag dit beleid niet zelf interpreteren en vervolgens zijn eigen interpretatie goedkeuren.

Gate 5: onafhankelijke menselijke kalibratie

Domeinexperts beoordelen een gestratificeerde steekproef op:

• realisme;
• frequentie;
• bedrijfswaarde;
• risico;
• volledigheid;
• alternatieve geldige workflows;
• ongewenste normatieve aannames.

LLM-scores worden vervolgens gekalibreerd tegen deze menselijke labels.

Gate 6: sandboxexecutie

Agenten worden getest tegen:

• geïsoleerde MCP-servers;
• tijdelijke tenants;
• synthetische datasets;
• geblokkeerde externe netwerktoegang;
• minimale credentials;
• korte tokenlevensduur;
• volledige auditlogging;
• gecontroleerde foutinjectie.

De beoordeling richt zich niet alleen op het traject, maar ook op de uiteindelijke toestand.

Gate 7: release- en driftcontrole

Bij iedere specificatiewijziging worden:

• gewijzigde tools geïdentificeerd;
• afhankelijke scenario's opnieuw gegenereerd;
• bestaande gold tests behouden;
• nieuwe scenario's tegen historische agentversies uitgevoerd;
• onverwachte benchmarkchurn onderzocht;
• kritieke verschillen door experts beoordeeld.

Hierdoor ontstaat een combinatie van stabiliteit en actualiteit.

Het juiste benchmarkmodel: dynamisch, gevalideerd en operationeel

Een volwassen organisatie heeft drie complementaire testverzamelingen nodig.

1. Dynamische spec-set

Automatisch gegenereerd uit de actuele specificatie.

Doel:

• snelle coverage;
• detectie van API-drift;
• genereren van nieuwe testkandidaten;
• regressiedetectie bij gewijzigde schema's.

2. Gevalideerde assurance-set

Scenario's die deterministisch, stateful en beleidsmatig zijn gevalideerd.

Doel:

• CI/CD- en CT-gates;
• betrouwbare regressietests;
• gecontroleerde vergelijking van modellen en prompts.

3. Operationele gold set

Door experts gevalideerde of uit representatieve operaties afgeleide scenario's.

Doel:

• criteriumvaliditeit;
• hoogrisicobesluiten;
• releaseautorisatie;
• periodieke herkalibratie van de synthetische generator.

Agent Seer vult vooral de eerste categorie. De fout zou zijn om die categorie te verwarren met de derde.

Een falsificatieprogramma voor de centrale claims

De wetenschappelijke waarde van Agent Seer kan substantieel worden verhoogd met de volgende experimenten:

Hypothese	Vereist experiment	Falsificatiecriterium
De specificatie bevat voldoende informatie	Vergelijk bekende API's met volledig fictieve API's en willekeurig hernoemde tools	Kwaliteit stort in zonder vooraf aangeleerde domeinkennis
Schemacomplexiteit veroorzaakt kwaliteitsverlies	Gebruik gecontroleerde schemamutaties bij inhoudelijk identieke tools	Geen monotone of reproduceerbare kwaliteitsdaling
LLM-scores voorspellen echte agentkwaliteit	Vergelijk benchmarkranglijsten met taakuitkomsten op operationele servers	Lage correlatie of andere modelrangorde
Multi-turnscenario's zijn state-consistent	Voer scenario's uit tegen een stateful simulator met provenancecontrole	IDs, waarden of toestanden kunnen niet worden gereconstrueerd
Dynamische generatie volgt API-drift	Replay historische specificatieversies en breaking changes	Belangrijke wijzigingen leveren geen passende testwijzigingen op
Het systeem is veilig tegen vijandige specs	Red-team toolbeschrijvingen, annotaties en schema's	Injecties veranderen scenario's, policies of beoordeling
Synthetische coverage reduceert false greens	Injecteer bekende agentfouten en meet detectie	Fouten blijven ongedetecteerd ondanks hoge gemiddelde score

De belangrijkste afhankelijke variabele zou niet langer alleen gemiddelde tool-calling-score moeten zijn. Voor enterprise assurance zijn belangrijker:

• false-green rate;
• false-negative rate;
• menselijke overeenstemming;
• outcome agreement;
• mutation detection rate;
• state-integrity failure rate;
• policy violation escape rate;
• benchmark drift rate;
• inter-generator disagreement;
• inter-judge disagreement.

Implicaties voor het DjimIT-ecosysteem

Binnen een ecosysteem zoals DjimIT past Agent Seer logisch aan het begin van een Evidence-Native SDLC, niet aan het einde.

De gewenste positie is:

MCP Registry → Spec Analyzer → Scenario Candidate Generator → Epistemic Assurance → Stateful Canary → Release Gate

Concreet betekent dit:

DjimIT-component	Verantwoordelijkheid
Capability Registry	Vertrouwde MCP-snapshot, versie, hash en provenance
Agent Seer-achtige generator	Dynamische scenario- en testkandidaatproductie
Onafhankelijke assurance-agent, bijvoorbeeld EVE-V	Contradicties, ontbrekende onderbouwing en false-greenrisico detecteren
Stateful simulator	IDs, afhankelijkheden, eindtoestanden en foutpaden controleren
Federation canary	Routing, worker identity, approvals en lifecycle valideren
Security policy gate	Scopes, tenantgrenzen en forbidden fallbacks afdwingen
Release controller	Fail-closed GO, HOLD of REJECT bepalen

Een door Agent Seer gegenereerde hoge score mag binnen deze architectuur nooit zelfstandig een GO-besluit veroorzaken. De score is evidence, geen autoriteit.

De meest waardevolle toepassing is automatische MCP-differentiële testing:

• sla iedere goedgekeurde specificatieversie immutable op;
• bereken een semantische spec-diff;
• genereer scenario's voor gewijzigde tools en afhankelijke workflows;
• voeg adversarial mutations toe;
• voer scenario's uit in een geïsoleerde federatie;
• valideer state, identity, provenance en policy;
• promoveer alleen scenario's die onafhankelijke assurance doorstaan.

Conclusie

Agent Seer is een betekenisvolle bijdrage aan de industrialisering van agent-evaluatie. De paper laat overtuigend zien dat MCP-specificaties voldoende structuur bevatten om zonder handmatige annotatie grote aantallen plausibele evaluatieartefacten te produceren. De vierfasenarchitectuur, schema-gevalideerde tussenproducten en backend-onafhankelijke harnesses zijn praktisch waardevol. Het onderzoek lokaliseert bovendien overtuigend dat argumentwaarden, niet toolnamen, de dominante foutbron vormen.

Maar de specificatie is niet de werkelijkheid.

Een specificatie beschrijft mogelijke interfaces. Zij beschrijft niet automatisch werkelijke gebruikersintenties, toegestane handelingen, operationele toestanden, foutdistributies, risico's of succesvolle bedrijfsuitkomsten. De gegenereerde scenario's zijn daarom hypothesen over gebruik, geen observaties van gebruik.

De juiste conclusie luidt:

Agent Seer bewijst dat specificaties bruikbare testkandidaten kunnen genereren. Het bewijst niet dat specificaties zelfstandig geldige ground truth kunnen produceren.

Daarom is het strategische advies:

Besluit	Toepassing
GO	Pilot als dynamische benchmark- en scenariogenerator
GO WITH CONSTRAINTS	Gebruik in CI/CD na deterministische, stateful en onafhankelijke validatie
HOLD	Gebruik als geautomatiseerde release gate zonder menselijke kalibratie
REJECT	Gebruik als zelfstandige assurance-oracle voor productieagents

De paper moet dus niet worden gelezen als het einde van handmatige evaluatie. Zij biedt een schaalbare manier om menselijke expertise, stateful simulatie en operationele validatie veel gerichter in te zetten.

Primaire en aanvullende bronnen

De analyse is gebaseerd op de oorspronkelijke Agent Seer-paper, de officiële Apple Research-publicatie en de DAIR.AI-curatorsamenvatting.

Voor de vergelijking met outcome-, state- en provenancegerichte evaluatie zijn MCP-AgentBench, FuncBenchGen, ToolWeave en EigenData betrokken.

Voor de actuele technische en beveiligingscontext is de MCP-specificatie van 28 juli 2026 gebruikt.