Hvad skete der
AWS beskriver i et nyt teknisk indlæg, hvordan produktionstunge multi-agent systemer fejler på måder, som klassisk overvågning ikke fanger. Eksemplerne er konkrete: agenter der leverer tomme foundation-model svar uden 500-fejl, supervisor-agenter der ruter omkring 20 procent af anmodningerne til den forkerte specialist, og forløb hvor værktøjskald ser “grønne” ud, men slutopgaven alligevel ikke bliver løst. AWS kobler to lag sammen for at få øje på det, der ellers glider under radaren: AgentCore Evaluations til løbende kvalitetsvurdering af live-interaktioner og AWS DevOps Agent til undersøgelse af hændelser på tværs af services. Kilden er AWS’ eget blogindlæg (kilde 3393).
AWS rapporterer, at denne kombination blev anvendt i en produktionsopsætning for flyreservationer med flere specialiserede agenter. I deres eksempel fungerer Evaluations som barometer for, om agenten faktisk hjælper brugeren, mens DevOps Agent korrelerer CloudWatch-logs, IAM-politikker og traces for at finde årsagen, når noget går skævt (kilde 3393).
Hvorfor det betyder noget nu
Når PoC-perioden er ovre, er “stille” fejl det, der koster. Ikke fordi CPU’en brænder, men fordi kunderne får et ubrugeligt svar – eller slet intet. AWS peger på fejltyper, der opstår uden at udløse klassiske alarmer: manglende IAM-tilladelser, der forhindrer en agent i at kalde sin model, men kun resulterer i et tomt output; eller en supervisor, der driver væk fra sin oprindelige prompt-ramme og begynder at rute en betydelig del af trafikken skævt. Hverken latency- eller error-rate-grafer blinker nødvendigvis rødt her (kilde 3393).
Mange teams er netop nu ved at rulle agentbaserede funktioner ud mod rigtige brugere under produktfrister og compliance-krav. Hvis man kun måler infrastrukturens helbred, men ikke agenternes målopfyldelse, måler man ved siden af.
De konkrete fejlformer
AWS’ eksempler dokumenterer tre gennemgående failure modes i multi-agent drift (kilde 3393):
For det første tomme foundation-model svar. AWS beskriver, hvordan en agent kan miste evnen til at kalde sin model – fx på grund af manglende IAM-permission på agentens execution role – uden at det afføder en traditionel 500-fejl. Resultatet kan ligne tavshed, ikke crash.
For det andet routing-drift. En supervisor-agent med for løst afgrænset prompt begynder i deres eksempel at sende omkring 20 procent af anmodningerne til en forkert specialist-agent. Infrastrukturmålingerne ser stadig fine ud. Brugernes oplevelse gør ikke.
For det tredje “grønne” værktøjskald uden målopfyldelse. AWS beskriver cases, hvor logs viser succesfulde tool-invocations, men opgaven ender uforløst, fordi fejlen ligger flere kald nede i kæden og aldrig bliver til en exception.
Hvorfor infrastruktur-monitoring ikke er nok
Amazon CloudWatch og lignende værktøjer måler, om systemet kørte. Ikke om agenten forstod opgaven eller førte brugeren i mål. Den forskel er kernen i AWS’ adskillelse mellem “execution health” og “agent effectiveness” (kilde 3393). En agent kan kalde Amazon Bedrock korrekt, udføre værktøjer uden fejl og stadig levere et svar, der misser intentionen. Det er ikke en 500-fejl. Det er et kvalitetsfald.
Derfor kræves telemetri på tværs af lag: status for model-API-kald, dialog- og beslutningsspor i orkestreringen, supervisorens routing-statistik og – vigtigst – virksomhedsnære end-to-end checks, der afspejler, om målet faktisk blev nået (kilde 3393).
Hvad AgentCore Evaluations og DevOps Agent gør
AWS fremlægger et todelt design. AgentCore Evaluations scorer løbende kvaliteten af agent-interaktioner i produktion og kan ifølge AWS’ eksempel fange forkert værktøjsvalg, mislykkede opgaver og regressionsmønstre, som klassisk overvågning ikke ser. AWS beskriver formålet tydeligt, men går ikke i dybden med præcis metrikdefinition, thresholds eller stikprøvestørrelser, så her er der usikkerhed (kilde 3393).
Det andet lag er AWS DevOps Agent. AWS rapporterer, at den bruges til undersøgelse af hændelser ved at korrelere CloudWatch-logs, IAM-politikker, invocations og traces på tværs af services, så teams hurtigere kan nå frem til rodårsagen og få forslag til afhjælpning (kilde 3393). Kombinationen dækker både “fungerer agenten fagligt rigtigt” og “er infrastrukturen under den som den skal være”.
Teknisk opsætning i lag
Et praktisk design læner sig op ad fire lag, som AWS’ gennemgang understøtter (kilde 3393):
- Infra-telemetri: CloudWatch-metrics, logs og traces som baseline. OpenTelemetry-instrumentering giver standardiserede spor fra AgentCore runtime ud i CloudWatch.
- Model- og API-lag: eksplicit logning af FM-invocations og output-validering for at fange tomme svar og soft-failures, som ikke dukker op som exceptions.
- Agent-orkestrering: detaljerede traces af supervisorens beslutninger, værktøjskald og især routing-metrics pr. specialist.
- Business-level SLO’er: end-to-end checks der måler målrealisering – fx “reservation oprettet” frem for “værktøj kaldt”.
AWS fremhæver også, at AgentCore runtime kommer med indbygget OpenTelemetry, og at FAST-skabelonen (Fullstack AgentCore Solution Template) kan hjælpe teams med at rulle en sikker frontend og AgentCore-backend hurtigt ud (kilde 3393).
Teststrategier og kaos-scenarier
Hvis stille fejl er problemet, må testene spejle det. AWS’ eksempler peger på oplagte kaos-scenarier: fjern målrettet en IAM-tilladelse fra en agents execution role og se, om monitoreringen opfanger et tomt FM-svar; skru på rate limits eller indfør latency-spikes og mål, om agentens målopfyldelse falder, selvom værktøjskald ser succesfulde ud; og lav planlagte prompt-drift-tests for supervisoren for at se, om routing-andele driver over tid (kilde 3393).
Målet er ikke at trigge 500-fejl, men at sikre, at kvalitetsmålingerne og SLO’erne reagerer, når agentens adfærd ændrer sig. Hvis de ikke gør, er det monitoreringen, der halter.
Runbooks der virker i praksis
En brugbar incident-runbook for agenter starter med detektion: et drop i AgentCore Evaluations-score eller afvigende routing-metrics. Næste trin er korrelation: brug DevOps Agent til at samle IAM-politikker, invocations og traces i samme billede og pege på sandsynlig rodårsag (kilde 3393). Herfra kan man køre afhjælpning – for eksempel fallback-model, kontrollerede retries eller en enkel circuit breaker – og eskalere, hvis det ikke normaliserer.
Medtag også post-mortem: ikke kun “hvorfor fejlede det”, men “hvilken måling burde have reageret tidligere”. Hver hændelse er en chance for at skærpe signalet.
Hvorfor harnesset betyder alt
Flere uafhængige analyser peger på, at agenters præstation ikke kun afhænger af modelvægte, men også af den ramme, de kører i – harnesset: eksekveringsloop, værktøjer, kontekst, state, recovery og verifikation. En nyere gennemgang opsummerer, at benchmarks flytter sig, når harnesset ændres, selv med samme modelvægte (kilde 3395). Det betyder, at produktionsmålinger skal ses i lyset af den kode, der styrer agenten.
Tradeoffs og blinde vinkler
AWS’ fremstilling er nyttig, men der er åbne spørgsmål. For det første omkostninger og performance-overhead: Kontinuerlig live-evaluering og ekstra tracing kan påvirke både forbrug og latency. AWS’ indlæg skitserer ikke konkrete tal (kilde 3393). Det bør afklares i piloter, før man skalerer.
For det andet scoringens præcision: AWS beskriver formål og anvendelse, men ikke fulde metrikker, thresholds, annoteringsflows eller stikprøvestørrelser. Det gør risikoen for falske positiver/negativer sværere at vurdere. Teams må definere egne acceptkriterier pr. domæne (kilde 3393).
For det tredje integration i eksisterende stacks: AWS viser koblingen til CloudWatch, OpenTelemetry og AgentCore-runtime. Der er sparsomme oplysninger om out-of-the-box-integration til tredjepartsværktøjer og SIEM udover OTel-sporet (kilde 3393). Det kræver planlægning.
Hvad man bør måle nu
Et retvendt sæt nøgletal for agenter – med afsæt i AWS’ cases og anbefalinger (kilde 3393):
- FM-invocation health: andel af tomme/ugyldige outputs, modellatens over tid, throttling-frekvens.
- Routing-metrics: fordeling pr. specialist-agent, drift-rate pr. uge, outlier-detektion for supervisorbeslutninger.
- Task completion: målbare “goal achieved”-events pr. opgavetype, inkl. fejlklassifikation når målet ikke nås.
- Regressioner: ændring i AgentCore Evaluations-score efter deploys, korreleret med harness- eller prompt-version.
Hvis bare én af de fire kategorier mangler, er der et hul i signalet.
Test før produktion
En minimal testpakke kan være jordnær. I praksis giver det mening at indføre: 1) IAM-kaostests, hvor specifikke permissions fjernes på skift og Eval-scorer overvåges; 2) throttling- og latency-injektioner for modelkald; 3) supervisordrift-tests med variationer i input, så routing-andele måles over tid (kilde 3393). Hver test retter sig mod en fejlform, AWS eksplicit beskriver.
Det fanger den virkelighed, hvor intet nødvendigvis kaster en exception, når det går galt. Man ser det i adfærden.
Implikationer for drift og udvikling
For drift betyder det en udvidet SLO-portefølje: ikke kun infrastruktur-SLO’er, men også agent-effektivitet. Evaluations-scorer bør optræde i alarmer og dashboards sammen med 5xx-rate, og routing-metrics bør have grænser ligesom latency. For produktledelse betyder det, at “kvalitet” skal være målbart og koblet til udrulninger.
For udviklingsteamet betyder det, at ændringer i loop, værktøjer, verifikation eller recovery versioneres og behandles som produktfeatures med migrationsplaner og rollback-strategi.
Konkrete næste skridt
Hvis det skal omsættes i denne sprint – med udgangspunkt i AWS’ eksempler og stack (kilde 3393):
- Instrumentér model-API-laget: log FM-kald, fang tomme svar, og vis nøgletal side om side med infra-metrics.
- Tilføj routing-metrics: mål fordeling pr. specialist og flag drift over en valgt tærskel.
- Definér business-SLO’er: mål målopfyldelse pr. opgavetype i stedet for kun fejlrater.
- Integrér AgentCore Evaluations i en kontrolleret testfase før bred produktion.
- Planlæg kaostests for IAM, throttling og latency, og bind alarmer til Eval-scorer og task completion.
Afsluttende noter
AWS’ hovedpointe er klar: traditionel overvågning ser, om systemet kørte; agentovervågning ser, om brugeren fik løst sin opgave. De to ting er ikke det samme. AgentCore Evaluations og AWS DevOps Agent adresserer begge vinkler og giver en vej til at opdage stille fejl tidligt (kilde 3393). Der er åbne spørgsmål om omkostninger, scoringens præcision og integration ud over AWS’ egen stack. Det må testes i egne rammer.
