Problem
En agent fejler, og postmortem begynder med et ubekvemt spørgsmål: hvad gjorde den helt præcist.
Svaret passer sjældent i en prompt- og output-log. Fejlen kan ligge i retrieval, tilladelser, tool selection, parametre, retry, hallucination, timeout, validering eller i en ekstern handling, der så ud til at være vellykket, men ikke var det.
Hvis der ikke findes en undersøgelsesmetode, bliver hver hændelse til arkæologi.
Tese
Agent Incident Response skal blive en operationel disciplin.
Det er ikke nok at have generisk observabilitet. Agenter har brug for deres egen fejltaxonomi og en tidslinje, der forbinder intention, kontekst, beslutning, værktøj og effekt.
Målet er ikke at bebrejde modellen. Det er at finde ud af, hvilket lag der fejlede, og hvilken kontrol der manglede.
Rammeværk
En agentisk hændelse skal rekonstrueres i syv lag:
- Intent: hvilken opgave modtog agenten.
- Context: hvilken information hentede den eller ikke hentede.
- Policy: hvilke regler og tilladelser var gældende.
- Plan: hvilken rute valgte den.
- Tools: hvilke kald foretog den, og med hvilke argumenter.
- Outcome: hvad ændrede sig i det eksterne system.
- Verification: hvordan blev resultatet kontrolleret.
Mini-case: en agent sender en forkert e-mail til en kunde. Problemet kan være prompt, forældet CRM, forkert skabelon, manglende menneskelig godkendelse, værktøj uden validering eller manglende verifikation. Uden tidslinje diskuterer teamet meninger. Med tidslinje korrigerer det systemet.
Målbart signal: procentdel af agentiske hændelser med rodårsag tildelt et konkret lag.
Holdning: automatiser ikke det, du ikke kan undersøge.
Hvorfor det er vigtigt nu
OpenTelemetry definerer allerede konventioner for GenAI-systemer, herunder spans, hændelser, undtagelser og metrik relateret til modeller, agenter og værktøjer. OpenAI anbefaler lagdelte safeguards og validering af outputs i agenter. MCP dokumenterer trusler som tool poisoning, confused deputy og autorisationsrisici.
Infrastrukturen findes til at komme i gang. Det, der mangler i mange virksomheder, er praksis: runbooks, etiketter, owners og feedback til evalueringer.
Anti-eksempel
“Modellen tog fejl.”
Det er en doven forklaring. Den kan være sand, men den er ikke handlingsorienteret. En alvorlig hændelse skal sige, hvor kæden blev brudt: kontekst, instruktion, værktøj, tilladelse, verifikation eller supervision.
Protokol (3 trin)
- Opret en fejltaxonomi. Model, kontekst, værktøj, tilladelse, integration, kriterium, supervision, verifikation.
- Kræv tidslinje. Hver hændelse skal have en sekvens af hændelser og tool calls.
- Omdan årsager til evals. Hver vigtig fejl skal ende som permanent testcase.
| Lag | Spørgsmål | Korrigerende handling |
|---|---|---|
| kontekst | hvad vidste den | forbedre retrieval |
| værktøj | hvad kaldte den | validere argumenter |
| tilladelse | hvad kunne den gøre | reducere scope |
| outcome | hvad ændrede sig | verificere tilstand |
| eval | ville det ske igen | oprette test |
Relateret
- AI Traces: det lag der gør agenter til auditerbare systemer
- Output Verification Layer: den usynlige forsikring for agenter i produktion
- Agent Reliability Score: hvordan man ved, om en agent fortjener autonomi
Konsulterede kilder
- OpenTelemetry: Semantic conventions for generative AI systems
- OpenAI: A practical guide to building agents
- MCP Security Best Practices
Næste skridt
Genåbn den seneste AI-fejl, du havde. Klassificer den ikke som “hallucination”, før du har kortlagt intent, kontekst, policy, tool, outcome og verifikation.
Oversat fra den spanske original med AI-hjælp og gennemset for nøjagtighed. Læs originalen på spansk.