Dette researchoverblik er samlet og skrevet af AI ud fra ugens udvalgte kilder. Det er ikke en personlig afprøvning eller en fagfællebedømmelse fra Evgeny Karpov.
Ugens kilder: 02.11.2026–08.11.2026.
Dette AI-skrevne ugentlige overblik peger på én fælles driftserfaring: Når agents får hukommelse, retrieval og flere værktøjer, ligger risikoen ikke kun i modelsvaret. Den ligger i de systemer, der fastholder kontekst, udleder konsekvenser og måler, om resultatet var korrekt.
Et benchmark er også en produktionstjeneste
Benchmarks as Software: Terminal-Bench and the Case for Continuous Benchmarks og Silent Instrument Errors Reorder Agent Leaderboards behandler evaluering som softwaredrift, ikke som en engangsmåling. Førstnævnte artikel beskriver, hvordan opgaver, verifiers og runtime-rammer kan blive forældede, når modeller finder gyldige løsningsveje, som testene ikke accepterer. Den rapporterer også, at reparationer ændrede scores og nogle placeringer. Pointen for backend- og platformteams er, at en benchmark-score altid afhænger af den konkrete harness, version og ressourcepolitik bag tallet.
Den anden artikel skærper problemet: dens forfattere fandt i offentlige artefakter fejl, der påvirkede gradering, omkostningsopgørelse og provenance i trajectories. Det er ikke bevis for, at alle leaderboards er upålidelige, men det viser, hvorfor et plausibelt tal ikke er nok. Evaluering bør have samme observability som en kritisk workflow: andelen af faktisk graderede runs, versionslåste evaluators, sporbarhed for agent- kontra graderhandlinger og tydelige ændringsdiffs ved re-grading. Begge resultater er preprints og abstracts, ikke uafhængigt reproducerede undersøgelser.
Kilder: Benchmarks as Software: Terminal-Bench and the Case for Continuous Benchmarks; Silent Instrument Errors Reorder Agent Leaderboards.
Vedvarende state kræver konsekvensstyring
A State Change Is Local, Its Consequences Are Not flytter fokus fra at rette en forkert memory-post til at finde det, som posten fortsat understøtter. Artiklen foreslår StateGraph, hvor afhængigheder mellem facts, planer og handlinger rekonstrueres og testes kontrafaktisk: Ville den afledte state stadig holde, hvis præmissen forsvandt? For et platformteam svarer det til forskellen mellem at opdatere en service-katalogpost og at finde deployment-regler, routing eller runbooks, der blev baseret på den.
MemHarmBench viser den sikkerhedsmæssige bagside af samme mekanisme. Forfatterne rapporterer, at ondsindede instruktioner kan blive i agenthukommelse og påvirke en senere legitim opgave, selv når den oprindelige tekst er fjernet. At opgaven ellers gennemføres normalt, gør almindelig task-success til et svagt alarmsignal. Resultaterne understøtter derfor en praktisk skelnen mellem data, instruktioner og afledte beslutninger i persistent memory. StateGraph bygger dog delvist på en lille, forfatterkonstrueret benchmark, og MemHarmBench-abstractet fastslår ikke repræsentativitet for konkrete produktionsagenter.
Kilder: A State Change Is Local, Its Consequences Are Not: Dependency-Aware State Revision for Long-Term Agent Memory; MemHarmBench: Evaluating Cross-Session Prompt Injection in Memory-Persistent AI Agents.
Retrieval kan gøre en gyldig policy forkert
IAMRAGBENCH undersøger en konkret højrisiko-variant af retrieval: en model kan generere en AWS IAM-policy, som er syntaktisk og provider-mæssigt gyldig, men som giver mere adgang end den betroede opgave kræver. Forfatterne beskriver både forgiftet retrieval-kontekst og svækkelser præsenteret som en sikkerhedsundtagelse. I deres test kunne sådanne input føre til nye, forbudte autorisationer. Det afgørende er, at policyen kan se operationelt brugbar ud, mens dens faktiske effekt er forkert.
Det peger på en klar ansvarsgrænse i platformens workflow: retrieval og modellen må formulere et forslag, men må ikke være sidste instans for authorization. Policy-as-code, request-level checks hvor de findes, og en eksplicit sammenligning mod en tilladt permission envelope er mere robuste kontrolpunkter end sproglig plausibilitet. Benchmarken er afgrænset til dens AWS IAM-cases og testede endpoints, så den siger ikke alene, hvor ofte dette sker i en given organisation. Den giver alligevel et præcist designprincip: verificér den konkrete adgangsdifference før deployment.
Hvad er værd at tage med?
Et afgrænset næste skridt er at lade CI blokere enhver AI-foreslået AWS IAM-policy, der udvider en godkendt authorization envelope, og sende uafklarede differencer til menneskelig review. Det gør policy-output til en verificerbar deployment-artefakt i stedet for en tekst, der accepteres på tillid, og følger direkte den kontrolretning IAMRAGBENCH afprøver.
Overblikket bygger på de linkede kilders abstracts eller artikeluddrag. Resultaterne er forfatternes egne rapporter; forslag til praksis er overblikkets fortolkning. Kildeudvalget dækker ikke al ugens forskning.