AgentCore Observability: sådan holdes

AgentCore Observability sender spans, traces og metrics direkte til CloudWatch, så en agents adfærd bliver synlig i samme værktøj, jeg allerede bruger til resten af min AWS-infrastruktur. Jeg skal ikke bygge mit eget logging-lag oven på agenten for at forstå, hvad den foretager sig. Hvert trin i en agents beslutningskæde, fra det første LLM-kald til det sidste værktøjssvar, bliver fanget som et span med tidsstempler og metadata. Det gør det muligt at følge en enkelt agent-session fra start til slut og se præcis, hvilke trin der tog tid, og hvilke der fejlede.

Den store fordel er, at jeg slipper for at gætte. Uden observability er fejlfinding i en agent typisk et spørgsmål om at genskabe scenariet lokalt og håbe på, at jeg rammer den samme fejl. Med spans i CloudWatch går jeg i stedet direkte til den konkrete session, der gik galt, og ser nøjagtigt, hvilket værktøjskald eller hvilket LLM-svar der var årsagen.

Den typiske flaskehals i en produktionsagent sidder sjældent, hvor jeg forventer det. Det er ofte ikke selve LLM-kaldet, der er langsomt, men gentagne værktøjskald, ineffektiv hentning af kontekst eller unødvendige runder i agentens indre løkke, før den når frem til et svar. AgentCore Observability gør det muligt at bryde en agents udførelse ned i enkeltdele og se, hvor tiden reelt går.

I praksis betyder det, at jeg kan sammenligne latency på tværs af sessioner og finde mønstrene: bestemte værktøjer, der konsekvent er langsomme, eller bestemte typer forespørgsler, der udløser forsinkelsen. Med de data i hånden bliver optimering en målrettet øvelse frem for gætværk. Jeg retter det, der faktisk koster tid, i stedet for at optimere det, jeg tilfældigvis lægger mærke til.

Agenter, der kører over længere sessioner, med samtaler, der strækker sig over mange runder, eller opgaver, der løber i baggrunden, støder ofte ind i et andet problem: hukommelsesforbruget vokser ukontrolleret. Det kan skyldes, at kontekstvinduet akkumulerer historik uden at blive ryddet effektivt, eller at agenten holder fast i data, den ikke længere har brug for.

Observability-laget gør det muligt at følge hukommelsesforbrug over tid og se, hvornår og hvorfor det stiger. Det er en anden type fejlfinding end klassisk performance-optimering, for problemet viser sig ofte først efter lang tids drift, ikke ved et enkelt kald. Her er værdien af kontinuerlig overvågning tydelig: et engangstjek ved deployment fanger ikke et hukommelsesproblem, der først opstår efter timer eller dage.

Der er en stor forskel på at bygge en agent til en demo og at drive den i produktion. I prototypefasen er det acceptabelt, at en agent er langsom eller bruger for meget hukommelse, fordi jeg selv styrer testscenarierne. I produktion møder agenten uforudsigelig trafik, varierede input og brugere, der ikke opfører sig som testcases.

Det skifte, fra prototype til drift, er der, hvor jeg oftest ser projekter støde på uventede problemer. En agent, der har kørt upåklageligt med et lille antal interne testere, kan opføre sig helt anderledes, når den rammer reel, samtidig trafik. Jeg har ikke et rent tal for, hvornår det typisk sker, det varierer for meget fra system til system, men mønstret går igen. Observability er ikke et nice-to-have i den overgang, det er den eneste måde at opdage problemerne, før de bliver til nedetid eller dårlige brugeroplevelser.

For virksomheder, der allerede har agenter kørende, eller som er på vej dertil, er pointen ligetil: observability skal være på plads, før agenten går i produktion, ikke som en eftertanke, når noget går galt. Det kræver ikke et stort ekstra system at bygge selv. Fordi AgentCore Observability integrerer direkte med CloudWatch, kan teams, der allerede driver infrastruktur på AWS, få det overblik uden at indføre et helt nyt værktøj i deres stak.

For virksomheder, der endnu ikke har tænkt på observability som en del af deres agent-arkitektur, er det værd at rykke det op på listen. Den agent, der virker upåklageligt i dag med lav belastning, er ikke nødvendigvis den samme agent, når trafikken vokser, eller når sessionerne bliver længere. Det billigste tidspunkt at opdage et performance- eller hukommelsesproblem er, før det rammer rigtige brugere, ikke efter.