Agenter er stærke. De er også uforudsigelige. AWS’ nye AgentOps‑ramme beskriver det nøgternt (AWS’ blog): uden styr på governance, versioner og observabilitet ender man i cost spirals og fejl, der er svære at genskabe. AgentCore på Bedrock er referenceimplementeringen i blogindlægget og viser en vej, men ikke hele vejen. Den operationelle byrde er stadig jeres.
Vi oplevede det for nylig: en prototypeagent tog en omvej, ingen havde forudset. Fire minutter og et par hundrede API‑kald senere blinkede tallene i vores cost‑dashboard. Som en vaskemaskine i selvsving. Vi fik den stoppet — fordi telemetrien var på plads (Snilld erfaring).
Hvad er agentisk AI
AWS beskriver agentiske systemer som løsninger, der kan ræsonnere, tilpasse sig og træffe autonome valg — ikke bare følge en fast opskrift (AWS). Det er mere end klassisk workflow‑automation. Der er en indre beslutningskæde, vi ikke kan gøre helt deterministisk. Det giver fleksibilitet, men gør drift vanskeligere på kendte måder.
Konsekvensen for arbejdet er klar i AWS’ ordvalg: DevOps skal udvides. AgentOps er den disciplin, der får agenter sikkert i produktion og forbedrer dem løbende (AWS). Den ramme er nyttig. Jeg tænkte faktisk, vi gerne havde haft dele af den, før vores første pilot.
Problemet i praksis
Agenter vælger nogle gange en anden vej end forventet. Det kan være genialt. Eller en løkke. Eller et forkert værktøj. AWS peger direkte på uforudsigelige beslutninger, cost spirals og non‑deterministiske fejl (AWS). Vi har set det i små glimt: en agent gentog en forespørgsel, fordi en mellemtilstand blev misforstået. Svært at debugge, når hvert forløb varierer en smule (Snilld erfaring).
Omkostningerne er den stille dræber. Små skævheder i beslutningslogikken kan udløse flere tokens, ekstra værktøjskald og flere RAG‑hop. I en anonymiseret finansiel test pingede en agent et scoring‑API igen og igen for at være sikker. Ikke ondt ment. Bare dyrt (Snilld erfaring). Et simpelt regneeksempel til planlægning: hvis én session uventet laver N værktøjskald og T model‑interaktioner, så er cost per session ≈ cost(tool) × N + cost(model) × T. Brug jeres faktiske model‑ og API‑priser i stedet for antagelser — vi gør det altid i en pre‑mortem, før vi skruer op for trafikken.
AgentOps som ramme
AWS samler disciplinen i fire søjler: Governance og sikkerhed, Build og drift, Evaluering samt Observability og overvågning (AWS). Det er praktisk tænkt: proces, teknologi og mennesker bindes sammen.
For teams bliver det til fire konkrete hjørner: Hvem agenten er, og hvad den ikke må. Hvordan alt — ikke kun kode — bygges og versioneres. Hvordan kvalitet måles på flere niveauer. Og hvordan man får indblik i agentens beslutninger i realtid for at fange fejl og prisudsving, før de sætter sig fast.
Governance og sikkerhed i dybden
Multi‑account er et standardråd hos AWS og giver mening her: isolér udvikling, test og produktion. Isolér også værktøjer med høj risiko (AWS whitepaper om multi‑account). Det skærper rettigheder, revisionsspor og oprydning. Men kompleksiteten stiger. Vi har set miljøer, hvor for mange konti skabte adgangsfriktion og uofficielle smutveje (Snilld erfaring).
Vores kompromis i praksis: start enkelt, men med klar adskillelse mellem mindst tre miljøer og de farligste værktøjer i eget account‑hegn. Kombinér deterministiske kontroller (tilladelseslister, loop‑grænser) med reasoning‑kontroller (sikkerhedsregler i prompts, sandboxes uden sideeffekt). Og brug human‑in‑the‑loop på handlinger, der ikke kan fortrydes. Ét ekstra klik dér er okay (AWS + Snilld praksis).
Build og drift gjort konkret
AWS anbefaler at behandle hver agent, hvert værktøj og hver memory‑konfiguration som et versioneret artefakt med egen pipeline (AWS). Det betyder nye mapper i repoet, nye artefaktyper i jeres registry og mere granuleret release‑styring. Ikke bare v1.2 af hele systemet, men agent v1.2.7, tool‑fx v0.9.3, memory‑profile v3.0.
En simpel CI/CD‑stepliste, som vi ofte bruger i piloter (Snilld praksis):
- Commit af agentmanifest valideres mod schema og policy‑regler.
- Statiske tjek af prompts og rollespil i sandbox (hurtige, deterministiske tests).
- Unit‑tests af værktøjsbindinger og fejlscenarier.
- Replay af 50–200 syntetiske samtaler med faste seeds og edge‑cases.
- Automatisk måling af turn‑success, cost per turn og loop‑detektering.
- Canary‑release til 5–10 procent trafik i 24–48 timer.
- Automatisk rollback, hvis kvalitet eller pris afviger fra baseline ud over en aftalt tærskel.
Et mini‑workflow fra en nylig kundepilot: commit af agentmanifest udløser build; de faste samtaler kører; vi måler turn‑success og cost per turn; canary får 5 procent trafik i et døgn; rollback, hvis kvalitet eller pris stikker 15 procent fra baseline (Snilld erfaring).
Evaluering på fire niveauer
AWS opdeler evaluering i tool, conversation turn, session outcome og system (AWS). Det er en brugbar stige. Tool‑niveauet fanger, om værktøjet gør det lovede. Turn‑niveauet måler, om et svar eller kald er rimeligt i konteksten. Session‑niveauet: blev målet nået. System‑niveauet: samlet oplevelse og drift.
I praksis kører vi to spor (Snilld praksis): offline tests i udvikling og løbende målinger i produktion. Offline bruger vi syntetiske samtaler og håndplukkede edge‑cases (fejlende API‑svar, manglende dokumenter, timeouts). I produktion måler vi on‑the‑fly: turn‑success rate, loop‑detektering, tool‑fejl, cost per interaction og tid til eskalering til menneske.
Observability og overvågning
Telemetri er limen i AgentOps. AWS’ anbefaling er at instrumentere på flere lag for at spore beslutninger, opdage kvalitetstab og tracke cost per interaction (AWS). Vores praksis er at instrumentere: ind og ud af modellen, hvert værktøjskald, prompt‑versioner, hukommelsesopslag og billing‑events. Det gør det muligt at afspille hele forløb ved en hændelse.
Sampling af logs: Vi anbefaler ofte 10–20 procent sampling i almindelige flows for at balancere lagringsomkostninger mod reproducerbarhed. Tradeoff: lav sampling sænker udgifterne, men kan skjule sjældne fejl; høj sampling hjælper fejlfinding, men koster. For højrisiko‑flows vælger vi fuld logging over kortere perioder eller målrettet sampling på specifikke fejlkoder (Snilld praksis). Vores vigtigste dashboards: kvalitetsindeks per agent, cost per interaction/session, top fejlende værktøjer og et heatmap over loop‑mistanker.
AgentCore på Bedrock i brug
AgentCore er AWS’ komponentpakke til at bygge og drifte agenter. Bloggen bruger AgentCore i implementeringseksempler og referencearkitektur, mens principperne præsenteres som generelle (AWS). Vores oplevelse: AgentCore samler nyttige byggeklodser — værktøjsregistrering, orkestrering og integrationsmønstre til øvrige AWS‑tjenester. Det mindsker limkode, især hvis I allerede er dybt i AWS‑stakken (Snilld vurdering).
Begrænsningerne er velkendte: risiko for vendor‑lock og behov for at få eksisterende CI/CD, observability og cost‑styring til at spille sammen. AgentCore fjerner ikke governancearbejdet. Og blogindlægget dokumenterer ikke fuldt prisscenarier for komplekse produktioner. Byg derfor med løse koblinger: hold agentlogik og værktøjer så portérbare som muligt, så I kan flytte jer senere, hvis det bliver nødvendigt (Snilld anbefaling).
Sikkerhed og adoption
Der er også en social vinkel. VentureBeat argumenterer for, at kompleks sikkerhed får folk til at omgå kontroller. Det ser vi også. Hvis den sikre vej er besværlig, opstår hurtigt en genvej via en testbot i et privat miljø. Så er governance væk, før I er i gang (VentureBeat + Snilld erfaring).
Gør derfor den sikre vej lettest: single sign‑on, pre‑approved værktøjer, gode default‑prompts og hurtige review‑flows. Efterlevelsen stiger, når appen føles hurtig og klar. Små ting hjælper: tydelige fejlmeddelelser og næste‑trin‑forslag.
Vejkort for implementering
Start med en kontrolleret pilot. Otte uger er nok til at se mønstre uden at brænde kalenderen af. Sæt telemetri op fra dag ét, og skru cost‑guardrails på, før I sender trafik. Brug en sandbox‑simulator med replay, så fejl kan genskabes. Hav human‑in‑the‑loop på handlinger, I ikke kan refundere (Snilld praksis).
En P0‑tjekliste, der virker for os (Snilld intern manual, kondenseret):
- Afgrænset problem og tre succeskriterier, der kan måles.
- Versionskontrol af agent, værktøj og memory som separate artefakter.
- Syntetisk testpakke med edge‑cases og faste seeds.
- Produktionsdashboard for kvalitet og pris, inkl. alarmtærskler.
- Budgetalarmer per agent og rate limits pr. værktøj.
- Canary‑release med klar rollback‑plan.
- Ugentlig review‑rytme med agent‑owner, sikkerhed og drift i samme rum.
Konsekvenser for organisering
AgentOps kræver nye hatte i teamet: en agent‑owner med ansvar for mål og roadmap; en observability‑ingeniør, der bygger sporbarhed ind i hver beslutning; en sikkerhedsreviewer med mandat til at sige stop; og en SRE eller CI‑ingeniør, der får pipelines, canaries og rollback til at spille — også når prompten ændrer sig (AWS’ søjler + Snilld praksis).
Driftsindsatsen undervurderes ofte. Vores erfaring: tid til overvågning, små rettelser og reviews er reel kapacitet, der skal planlægges. Ellers ender varme kartofler på gulvet en fredag eftermiddag.
Omkostningsstyring uden drama
For at undgå cost spirals bruger vi tre førstevalg (AWS’ problemformulering + Snilld praksis): budgetalarmer og rate limits per agent; attributtering af omkostning per værktøj og per session; samt sampling af logs og prompts. Vi parrer det med kvalitetsmål — pris og kvalitet følges ofte ad. En agent, der mister målet, bruger typisk også flere kald.
Teknisk kort: giv hvert request et korrelations‑id; log tool‑calls med latency og status; fang modelnavn og prompt‑hash; gem et udsnit af hele samtaler til replay. Indlæs billing‑events i jeres metrics‑lager, så cost per interaction kan ses side om side med kvalitet. Ikke smukt. Effektivt.
Risici og tradeoffs
Tre klassikere: 1) priseksplosioner ved logikløkken — håndteres med loop‑grænser, backoff og alerts; 2) forkert trust‑model, hvor agenten får for brede rettigheder — minimer rettigheder og brug human‑gating på højrisiko‑handlinger; 3) for meget eller for lidt human‑in‑the‑loop — for meget sænker tempoet, for lidt koster troværdighed og sikkerhed (AWS + Snilld praksis).
Og så brugervenlighed. Hvis governance føles som en håndbremse, fjerner folk den. Gør sikre valg hurtige. UX er ikke hele svaret, men det hjælper mere, end man tror (VentureBeat + Snilld erfaring).
Hvor AgentCore hjælper og hvor I selv skal trække
AgentCore kan forkorte vejen til en referencearkitektur, fordi orkestrering, tool‑binding og integration med AWS‑tjenester følger med i mønstrene, som blogindlægget viser. Det gør især en forskel i teams, der allerede lever i AWS med Security Hub, CloudWatch og IAM i værktøjskassen (AWS + Snilld vurdering).
Men I skal selv gøre tre ting: træffe governance‑beslutningerne, etablere versionering og CI/CD som artefakter og bygge observability, der matcher jeres risikoprofil. Det kan ikke købes. Og husk migrationsspørgsmålet: hold prompts, tools og tests så åbne, at I kan flytte dem, hvis fremtiden kræver det (Snilld anbefaling).
Hvad vi stadig ikke ved
Der mangler åbne benchmarks for, hvor meget omkostninger kan afvige per agenttype. Vi savner også fulde eksempelskemaer for telemetri fra AWS’ side — helt ned til feltnavne. Og prisbilledet for AgentCore i kompleks produktion er ikke krystalklart i offentlig dokumentation. Indtil da: konservative guardrails og løse koblinger (kildegrundlag: AWS‑bloggen + Snilld praksis).
Vi kunne også bruge uafhængige vurderinger af lock‑in kontra open source‑frameworks målt på migreringstid og driftsbyrde. Indtil da er vores pragmatik enkel: byg med eksplicitte kontrakter for værktøjer og portérbare tests.
Konklusion
AgentOps er ikke et buzzord hos AWS — det adresserer reelle smertepunkter. AgentCore er en brugbar reference i AWS‑land, men ikke en tryllestav. For danske virksomheder er nøglen små piloter, stram telemetri, tydelig governance og disciplin i CI/CD. Man opdager først forskellen, når man sidder med det i hænderne.
