En AI-agent, der klarede sig fint i sidste uge, kan sagtens svare
En AI-agent, der klarede sig fint i sidste uge, kan sagtens svare forkert i dag, uden at en eneste linje kode er ændret. Prompten er justeret, et værktøjskald er byttet ud, eller den underliggende model er opdateret et sted i kæden. AWS viser nu, hvordan Amazon Bedrock AgentCore Evaluations kan køres direkte i GitHub Actions, så den slags regression bliver fanget, før koden når produktion, ikke bagefter i en supportkø.
For virksomheder, der selv bygger og drifter agentiske systemer, er det en af de mest konkrete forbedringer i AgentCore-stakken i lang tid. Vi har fulgt AgentCore tæt gennem det seneste år, og mønsteret er tydeligt: governance og observability er ved at blive lige så indbygget i agent-udvikling, som test og linting længe har været i almindelig softwareudvikling.
CI/CD
Sådan tester GitHub Actions en agent, før koden når produktion
Setup'et er enkelt at forstå, selvom det løser et svært problem. Hver gang en udvikler åbner en pull request mod agent-koden, trigger en GitHub Actions-workflow en testkørsel mod agenten i et isoleret AgentCore-runtime miljø. Agenten stilles over for et fast sæt scenarier, og dens svar sammenlignes automatisk med en forventet baseline.
Det, der gør tilgangen brugbar i praksis frem for blot en teoretisk mulighed, er at den kører på samme sted som resten af CI/CD-pipelinen. Udviklere behøver ikke skifte værktøj eller huske at teste manuelt et par gange om ugen. Testen sidder i den samme pull request-proces, som allerede kører build og enhedstest, og det er præcis det, der afgør, om noget faktisk bliver brugt konsekvent i en travl udviklingshverdag.
MCP
AgentCore runtime kører en OAuth-sikret MCP-server til hver test
For at teste realistisk skal agenten have adgang til de samme værktøjer, den ville bruge i produktion, men uden at røre rigtige systemer eller data. Løsningen er en midlertidig MCP-server, der spinnes op i AgentCore runtime for hver testkørsel og beskyttes med OAuth. Serveren eksponerer de værktøjer, agenten skal kalde, men i et sandkassemiljø, der lukkes ned igen, når testen er færdig.
Det betyder, at man kan teste agentens fulde beslutningskæde, inklusive hvordan den vælger værktøjer og fortolker deres output, uden at skulle stille produktionsintegrationer til rådighed for hver eneste pull request. For virksomheder med agenter, der rører følsomme systemer, som kundedata, betalinger eller interne dokumenter, er den adskillelse ikke bare bekvem. Den er en forudsætning for overhovedet at turde automatisere testen.
Scoring
Automatisk scoring stopper pull requests ved regression
Den del, der gør workflowet til andet end endnu en logfil, er scoringen. AgentCore Evaluations sammenligner agentens svar mod de forventede resultater og genererer en score for hvert scenarie. Falder scoren under en fastsat tærskel, markeres pull requesten som fejlet, og den kan ikke merges, før problemet er rettet.
Det flytter ansvaret for agent-kvalitet fra en person, der skal huske at teste, til pipelinen selv. En udvikler, der ændrer en systemprompt for at løse ét problem, får med det samme at vide, hvis ændringen ødelægger noget andet, agenten plejede at kunne. Det er den samme logik, som har gjort automatiseret test til standard i almindelig softwareudvikling i årtier, nu anvendt på et lag, hvor output er sprogligt og ikke deterministisk på samme måde som traditionel kode.
En udvikler, der ændrer en systemprompt for at løse ét problem, får med det samme at vide, hvis ændringen ødelægger noget andet, agenten plejede at kunne.
Skalering
Fra lejlighedsvis manuel test til fast del af udviklingsflowet
Det, vi ser i denne opsætning, er et skifte i, hvordan agent-teams arbejder. Manuel test af en agents svar, gerne udført af en enkelt person, der kører nogle stikprøver før en release, bliver erstattet af en fast, automatiseret gate, som alle bidragydere er underlagt på samme vilkår.
Det kræver naturligvis, at man investerer tid i at bygge et solidt sæt testscenarier og en fornuftig baseline at måle imod. Den investering betaler sig hurtigt tilbage, fordi den fjerner den usikkerhed, der ellers opstår, når flere udviklere justerer på samme agent parallelt. For virksomheder, der er på vej fra et enkelt agent-eksperiment til flere agenter i produktion samtidig, er det præcis den slags infrastruktur, der afgør, om skaleringen bliver kontrolleret eller kaotisk. Vi har set samme mønster hos virksomheder, der går fra ét pilotprojekt til drift af flere agenter parallelt: uden en automatiseret kvalitetsgate bliver hver ny agent en ny kilde til overraskelser, og uden den bliver skaleringen hurtigt ustyrlig.