AWS vil gøre agent‑evaluering rammeværksuafhængig
AWS skriver i et blogindlæg, at Amazon Bedrock AgentCore Evaluations kan evaluere AI‑agenter på tværs af rammeværker ved at læse deres telemetri via OpenTelemetry. Ifølge bloggen vokser mangfoldigheden af agent‑frameworks, mens evalueringsværktøjer ikke følger med. Citatet herfra er: “the diversity of agent frameworks keeps growing, but evaluation tooling has not kept pace.” AWS peger samtidig på, at mange eksisterende systemer antager en bestemt SDK, LLM‑klient eller tracemønster og derfor bryder, når man går uden for disse antagelser.
Blogindlægget nævner konkrete byggesten, teams bruger i dag: LangGraph til orkestrering, LlamaIndex til retrieval, OpenAI Agents SDK hvor organisationer standardiserer på GPT, Google ADK til multi‑agent, Claude Agent SDK for Anthropic‑integration og Strands Agents for hurtigt at få en agent kørende på AgentCore. AWS anfører også, at mange kører oven på AgentCore‑runtime, som håndterer hosting, skalering, hukommelse og observability. I AWS’ fremstilling kobles evalueringen fri af frameworkvalget, fordi den læser den samme telemetri.
Fragmenteringen der bremsede evaluering
AWS beskriver problemet eksplicit: “Most evaluation systems assume you built your agent in a specific way: a specific SDK, a specific large language model (LLM) client, a specific tracing pattern. The moment you step outside that narrow compatibility zone, the evaluation pipeline breaks.” Den formulering sætter scenen for, hvorfor et telemetribaseret lag er centralt i deres løsning.
I blogindlægget positioneres AgentCore Evaluations som et svar på den flaskehals ved at standardisere læsningen af sporingsdata. Denne positionering er AWS’ egen, og indlægget leverer ikke uafhængige feltmålinger på tværs af forskellige stakke.
Sådan vil AWS binde det sammen
Ifølge AWS er kernen OpenTelemetry. OpenTelemetry standardiserer, hvordan distribuerede systemer udsender traces, metrics og logs. En trace er et træ af spans, og hver span repræsenterer et trin i en anmodning med navn, tidsstempler, typede attributter og eventuelle span‑events. Spans eksporteres over OpenTelemetry Protocol (OTLP) og samles af en telemetribackend. På AgentCore‑runtime er den backend AWS Distro for OpenTelemetry (ADOT), fremgår det af blogindlægget.
AWS’ gennemgang handler om, hvad tjenesten læser i spans, og hvilke attributter der bærer evalueringsdata. Pointen i kilden er, at evalueringen lægger sig oven på det sporingslag, udviklere i forvejen kan instrumentere med OTel.
Hvilke spans der faktisk tæller
Blogindlægget fremhæver tre roller, som evalueringen især bruger til at rekonstruere et agentforløb: en invoke_agent‑span for forløbet fra prompt til svar, inference‑spans for de enkelte modelkald med historik og output, og execute_tool‑spans for værktøjskald med navn, input og resultat. Med disse kan evalueringen ifølge AWS score på tværs, forudsat at telemetrien indeholder de nødvendige felter.
AWS beskriver disse som de tilsigtede roller i spans. Implementeringsdetaljer og konkrete attributnavne kan variere og bør derfor valideres i de anvendte instrumenteringsbiblioteker og versioner.
Hvor bred er OpenTelemetry‑dækningen
AWS skriver, at “every major framework supports OpenTelemetry, either natively or through a community instrumentation library”, og at evaluering derfor kan ske uanset SDK, hvis telemetri udsendes via OpenTelemetry. Blogindlægget indeholder dog ikke en versionsmatrix eller en testet kompatibilitetsliste på tværs af frameworks og versioner. Læsere bør derfor bekræfte i deres egen stack, at den konkrete version udsender de nødvendige spans og attributter, før en evalueringspipeline baseres på det.
Praktisk betyder det at inspicere eksempler på traces i eget miljø og sikre, at invoke_agent, inference og execute_tool fremgår med de attributter, evalueringen forventer. Det er en verifikationsopgave, ikke en automatisk garanti, sådan som blogindlægget også lægger op til.
Telemetri, eksport og drift
Ifølge AWS’ beskrivelse eksporteres spans via OTLP og opsamles af ADOT på AgentCore‑runtime. Det forbinder applikationsinstrumentering med en central backend. Hvilken throughput og hvilke omkostninger det giver i praksis, afhænger af belastning og miljø; blogindlægget præsenterer ikke uafhængige feltmålinger. Det bør derfor afklares med egne tests.
Et teknisk opmærksomhedspunkt følger af modellen: hvis nødvendige spans ikke udsendes eller går tabt, kan evalueringen ikke rekonstruere forløbet. Det er en direkte implikation af den telemetribaserede tilgang, som også afspejles i AWS’ fremstilling.
Sikkerhedsvirkeligheden i agentmiljøer
VentureBeat refererer Tenet Securitys “GhostJacking”, demonstreret på DEF CON, hvor en agent læste en Cloudflare‑log, tolkede en angribers prompt‑injektion som instruktion og ændrede DNS med legitime credentials. Ifølge artiklen fulgte Claude Code på Sonnet 4.6 den plantede instruktion i 9 ud af 10 forsøg under den viste konfiguration.
Implikationen for et telemetribåret evalueringslag er, at logs og sporingsdata kan indeholde angriberkontrolleret tekst. Den rapporterede 9/10‑rate gjaldt ifølge VentureBeat den beskrevne konfiguration; resultater kan afvige i andre opsætninger og bør derfor testes i kontrollerede miljøer.
Hvad kilderne dækker og ikke dækker
AWS‑blogindlægget dokumenterer idéen og mekanikken: evaluering læser OTel‑traces, bruger navngivne span‑roller (invoke_agent, inference, execute_tool), eksporterer via OTLP og samler på ADOT på AgentCore‑runtime. Det fremgår direkte af kilden.
Hvad der ikke er i kilderne: en versionsmatrix for frameworks og deres OTel‑support, uafhængige tredjepartsbenchmarks af AgentCore Evaluations i heterogene opsætninger samt målinger af ydeevne og omkostninger ved høj volumen. Blogindlægget bør derfor læses som en design‑ og implementeringsretning, der kræver egen validering.
Hvad teams kan gøre nu med kildedækning
Verificér i eget miljø, at trace‑data indeholder de tre nævnte span‑roller med de forventede attributter, før der bygges en pipeline ovenpå. Hvis AgentCore‑runtime anvendes, bekræft at OTLP‑eksport og ADOT‑opsamling virker end‑to‑end under normal belastning.
Reproducer sikkerhedsscenarier, der ligner GhostJacking, i et kontrolleret testmiljø. Tag ikke den rapporterede 9/10‑rate for givet i en anden konfiguration, men brug den som pejlemærke for et muligt udfald, sådan som VentureBeat beskriver det.
Den korte konklusion
AgentCore Evaluations bygger ifølge AWS på et telemetribaseret design: læs OTel‑traces og score agenter uanset underliggende SDK, når de nødvendige spans og attributter er til stede. Det adresserer de kompatibilitetsbrud, som AWS beskriver, når evalueringsværktøjer er låst til bestemte stacks.
Blogindlægget leverer imidlertid ikke en versionsmatrix eller uafhængige benchmarks. Den praktiske gevinst afhænger derfor af instrumentering og verifikation i det enkelte miljø. Start med at bekræfte, at jeres rammeværk udsender de krævede spans, og at telemetristien via OTLP/ADOT fungerer ved den ønskede belastning.
