AWS gjør agenttesting til del av kodearbeidet

Agentene må testes på mer enn svaret

AWS har lansert Agent-EvalKit, et Apache 2.0-verktøy for systematisk evaluering av AI-agenter. Verktøyet er laget for team som bygger agenter som velger verktøy, kaller API-er og utfører flere steg før de gir et svar.

Poenget er viktig: En agent kan gi et godt formulert svar og likevel ha gjort feil underveis. Den kan ha brukt feil verktøy, hoppet over kontrollsteg, funnet på fakta etter tomme søkeresultater eller kommet til riktig konklusjon på en måte som ikke kan forsvares i produksjon. Tradisjonell output-testing fanger ikke dette godt nok.

AWS beskriver Agent-EvalKit som evaluering inne i utviklingsmiljøet, ikke som et eget dashboard etterpå. Verktøyet kan brukes sammen med AI-kodeassistenter som Claude Code, Kiro CLI og Kilo Code. Utvikleren gir kommandoer i naturlig språk, og verktøyet bygger testopplegg, testdata, tracing, kjøringer, målinger og en rapport med konkrete kodeforslag.

Det er ikke den mest glamorøse AI-nyheten denne uken. Men den treffer et av de mest praktiske problemene for CIO-er og CTO-er: Hvordan vet du at en agent er trygg nok til å slippe inn i arbeidsflyten?

Seks faser fra magefølelse til sporbarhet

Agent-EvalKit organiserer arbeidet i seks faser. Først analyserer verktøyet agentens kode, systemprompt, verktøydefinisjoner og rammeverk. Deretter lager det en evalueringsplan med relevante målinger. Så genereres testcaser, agenten instrumenteres med OpenTelemetry-kompatibel tracing, testene kjøres, og resultatene evalueres. Til slutt produseres en rapport med prioriterte anbefalinger knyttet til konkrete steder i kodebasen.

Dette høres teknisk ut, men lederpoenget er enkelt: Agentkvalitet må måles i hele kjeden. Det holder ikke å spørre om svaret ser riktig ut. Man må se hvilke verktøy agenten brukte, hvilke data verktøyene returnerte, om agenten respekterte tomme eller svake datakilder, og om konklusjonen faktisk bygger på sporene i kjøringen.

AWS bruker en reiseagent som eksempel. Agenten ga gode og nyttige svar, men målingene viste et helt annet risikobilde. Response Quality lå på 83,9 prosent. Tool Parameter Accuracy lå på 64,5 prosent. Faithfulness, altså om svaret var forankret i dataene verktøyene faktisk returnerte, lå på bare 32,3 prosent. Agenten fant blant annet på valutakurser, temperaturer og detaljer om attraksjoner når websøket ga tomme eller ufullstendige resultater.

Det er akkurat denne typen feil som gjør agentprosjekter farlige i produksjon. Sluttbrukeren ser et ryddig svar. Utvikleren ser kanskje en grønn test. Men sporene viser at agenten har gjettet.

Fra pilot til internkontroll

Agent-EvalKit er også et signal om hvor markedet er på vei. AI-agenter går fra pilot og produktdemo til systemer som skal inngå i vanlig utvikling, drift og kontroll. Da må de inn i samme styringsløp som annen programvare: testdata, observability, måleparametere, rapportering og forbedringsforslag som kan følges opp.

Forskjellen er at agenter ikke bare kjører deterministisk kode. De planlegger, velger verktøy og endrer løp underveis. Derfor blir testingen mer som revisjon av adferd enn bare validering av funksjon. Det er en annen disiplin enn mange IT-organisasjoner er satt opp for.

For CIO betyr dette at agentprogrammet trenger en evalueringsstandard før det skaleres. For CISO betyr det at verktøybruk, datakilder og handlinger må kunne spores. For CTO betyr det at agenttesting bør flyttes nærmere kodebasen og CI/CD-løpet, ikke ligge som manuell QA etter en demo.

AWS retter verktøyet mot utviklere, men problemet er organisatorisk. Hvis virksomheten ikke kan dokumentere hvordan agenten kom frem til et svar, blir det vanskelig å forklare feil beslutninger, brudd på policy eller lekkasje av sensitiv informasjon.

Hva norske virksomheter bør ta med seg

Det viktigste er ikke om alle skal bruke Agent-EvalKit. Det viktigste er at AWS normaliserer en ny minimumsstandard for agentarbeid. Agenten må ha testcaser. Den må ha tracing. Den må måles på faktagrunnlag, ikke bare språk. Og rapporten må ende i konkrete endringer i koden, prompten eller verktøylaget.

Norske virksomheter som bygger agenter for kundeservice, saksbehandling, drift, analyse eller utvikling bør stille tre krav til leverandører og interne team.

For det første: Vis sporene. Hvilke verktøy ble kalt, med hvilke parametere, og hvilke data kom tilbake?

For det andre: Skill mellom et godt svar og et riktig grunnlag. En agent som skriver overbevisende norsk kan fortsatt være uegnet til beslutningsstøtte hvis den glatter over tomme datakilder.

For det tredje: Gjør evalueringsløpet repeterbart. Hvis agenten endres, modellen byttes, eller nye verktøy kobles på, må testen kunne kjøres på nytt uten et lite konsulentprosjekt hver gang.

Agentmarkedet har brukt mye tid på hva agenter kan gjøre. AWS-nyheten peker på det neste spørsmålet: Hvordan beviser du at de gjorde det riktig?

Kilder og medier

Kilde: AWS Machine Learning Blog, «Evaluate AI agents systematically with Agent-EvalKit», https://aws.amazon.com/blogs/machine-learning/evaluate-ai-agents-systematically-with-agent-evalkit/

Bakgrunn: awslabs/Agent-EvalKit på GitHub, https://github.com/awslabs/Agent-EvalKit

Thumbnail: OpenAI Image 2 / hogby.ai