Timen er velvalgt. Agent‑rammeværker er blevet mere modne, og Bedrock AgentCore lover at tage sig af det rutineprægede: session‑isolering, sikkerhed, skalerbarhed og observability, se 2277. Eksemplet binder værktøjer sammen via MCP med en Amplify‑frontend. Det er tiltalende – og tvinger de vigtige spørgsmål på bordet: IAM, auditering, datalivscyklus og hvor langt man går med automatisering uden menneske i løkken.
Hvad AWS egentlig viser
Guiden bygger en Support Companion som en Bedrock‑agent, orkestreret af Strands Agents, hvor adgang til AWS‑tjenester går gennem Model Context Protocol (MCP), se 2277. Agenten er en Python‑app i en Docker‑container, der kører på AgentCore Runtime, se 2277. Den taler med en foundation model – i bloggen Amazon Nova Pro via Bedrock – og du kan skifte til andre understøttede modeller uden at ændre agentkode, se 2277. Det mindsker model‑lock‑in, om end platformen stadig er AWS‑centreret.
MCP er nøglen: Tre MCP‑servere åbner for AWS‑dokumentation, Support‑API’er og AWS‑service‑API’er, se 2277. AgentCore Gateway samler værktøjer bag sikre endepunkter – re:Post nås via et Lambda‑mål med Cognito JWT‑autentificering, se 2277. Én samtale, flere værktøjer under motorhjelmen. Bedrock Guardrails filtrerer skadeligt indhold, redigerer PII (fx nøgler, kreditkort) og holder agenten til emnet AWS‑support, se 2277.
Hvor problemet stammer fra
Ved incidents starter mange i AWS Management Console, hopper til CloudWatch, søger dokumentation, scanner re:Post og ender med en Support‑sag, se 2277. Hvert hop koster fokus. Bloggen angiver eksplicit 30–45 minutters ekstra overhead pr. undersøgelse, se 2277. Det matcher oplevelsen en sen aften med for mange faner og for lidt tråd.
Det spejler en bredere tendens: cloud‑drift er blevet for manuel og fragmenteret. Gentagne skift, søgninger og kontekstkopiering spilder tid, se 2278. Mikrofriktion, der sjældent når et direktionsslide, men langsomt hæver MTTR – også når årsagen er triviel.
Sådan virker agenten i praksis
Flowet er ligetil. Man starter samtalen og beskriver hændelsen. Agenten henter logs og metrikker fra CloudWatch, leder efter mønstre og foreslår næste skridt, se 2277. Mangler den baggrund, søger den i AWS‑dokumentation eller kigger re:Post – uden at forlade chatten, se 2277. Er sagen uklar eller alvorlig, kan agenten klargøre og oprette en Support‑sag med kontekst og evidens, se 2277. Det sidste sparer ofte “forklaringsskriveri”.
Teknisk sker det via MCP‑servere og AgentCore Gateway, mens AgentCore Memory holder korttidshukommelsen i samtalen, så man ikke gentager sig ved hvert værktøjskald, se 2277. Frontenden er en Amplify‑hostet React‑app med Cognito til sign‑up og sign‑in. API Gateway (Cognito‑autorisering, WAF‑rate‑limiting, request‑validering) frontes mod en Lambda, der taler med AgentCore Runtime, se 2277. En reference‑stak, mange allerede kender.
Fra guide til drift
Eksemplet udrulles med én CloudFormation‑skabelon, der opretter IAM‑roller, Cognito user pools, KMS‑nøgler, Secrets Manager‑hemmeligheder og SSM‑parametre, se 2277. Forudsætninger: Python 3.11+, Docker med buildx til ARM64, en AWS‑konto med adgang til Bedrock, IAM og CloudFormation samt modeladgang (fx Nova Pro) i valgt region, se 2277. “One‑script” til demo er fint – produktion kræver CI\/CD, miljøseparation, rollback, versionsstyring af prompts og tests af værktøjsbindinger.
Agenten kører som Docker‑container i AgentCore Runtime, hvilket passer platformsteams, se 2277. Den reelle opgave er observability og omkostningsstyring: API‑latens pr. værktøjskald, tokenforbrug pr. prompt, fejlrate i automatiserede handlinger – og dokumenteret gevinst i reducerede kontekstskift. Ud over 30–45 minutter‑påstanden er bloggen tavs på tal; markér det som et målegab til pilot, se 2277.
Sikkerhed og adgang
IAM er den følsomme del. For at læse CloudWatch‑logs, slå op i docs via MCP, spørge re:Post og oprette Support‑sager behøver agenten specifikke tilladelser. Bloggen giver ingen færdig policy‑pakke – et hul, der skal lukkes før produktion, se 2277. Start konservativt: read‑only til navngivne loggrupper og namespaces, strammet adgang til re:Post via Gateway, og menneskelig godkendelse før indsendelse af Support‑sager. Adskil roller som “analysér logs” og “opret sag”.
Risikoen ved sagsoprettelse er håndterbar – hvis alt er auditerbart. Brug CloudTrail på API‑kald, AgentCore‑observability og API Gateway‑logs som samlet revisionsspor. Guardrails hjælper med PII‑redigering og emneafgrænsning, se 2277, men retter ikke fejlklassifikationer eller for brede tilladelser. Dertil kommer uafklarede spørgsmål om datalokalitet og retention for MCP‑servere og AgentCore Memory: hvor gemmes midlertidig kontekst, og hvor længe, se 2277. Det kræver en compliance‑afklaring, ikke kun en pull request.
Fejlkilder og begrænsninger
Hvor kan det skride. Ét: modelsvaret bygger på for lidt eller forældet kontekst. To: community‑viden fra re:Post er misvisende. Bloggen viser ingen mekanisme til evidens‑validering, kilde‑scoring eller verifiable links ud over almindelige henvisninger, se 2277. Og der er ingen benchmarks for latenstid eller pris under last. Uden dem risikerer man at flytte ventetid fra mennesket til agenten – uden MTTR‑gevinst.
Modstridende signaler er en klassiker: CloudWatch peger ét sted, dokumentation et andet. Hvem afgør retningen. Audit‑loggen bør vise, hvorfor agenten valgte spor A frem for B, men bloggen demonstrerer ikke et forklaringslag, se 2277. I drift betyder det playbooks, hvor agentens forslag kan afprøves i read‑only eller staging, før noget irreversibelt. Menneske i løkken på kritiske trin.
Governance og sporbarhed
Her skilles demo og drift. Kravene er velkendte: playbooks, tydelige ejere, audits og et klart “spor” af, hvad agenten foretog sig – hvornår, med hvilke input, via hvilke værktøjer, og med hvilket resultat. AgentCore lover observability og session‑isolering, se 2277. Det er nyttigt. Men uden systematisk review og debrief bliver observability endnu et dashboard, ingen bruger.
Et lille, praktisk greb: begræns sessionslevetid og kontekstens omfang, så hukommelse ikke blandes på tværs af sager. Log værktøjsopkald med korrelation‑ID fra incident‑systemet, så efterforskningen bevarer tråden. Ikke glamourøst – men det er det, der gør, at man tør tænde automation igen dagen efter.
Praktiske skridt for teams
Start i to trin. 1) Prototype med snævert scope: én applikationsservice, read‑only til udvalgte CloudWatch‑loggrupper (seneste 30 dage), og skrivende handlinger slået fra – især sagsoprettelse – indtil der er et godkendelsesworkflow. Indsaml basismålinger: tid til første plausible årsag, antal kontekstskift elimineret, svarnøjagtighed vurderet af en SRE, og model‑tokenforbrug pr. sag. AWS leverer ikke disse feltmålinger i bloggen, se 2277.
2) Governance: rollebaserede tilladelser, menneskelig godkendelse på risikofyldte handlinger og en ugentlig audit af sager og agentbeslutninger. Sæt thresholds for auto‑handlinger (kun lavrisiko playbooks). Definér klare rollback‑strategier: slå “auto‑case‑creation” fra, fald tilbage til read‑only eller throttling via API Gateway, hvis kvaliteten dykker. Banalt – og effektivt.
Lock‑in, modeller og fremtidig drift
AgentCore gør det muligt at skifte mellem understøttede Bedrock‑modeller uden at ændre agentkode, se 2277. Det er et plus for modelstyring og prisstyring. Men værktøjsintegrationer, gateway og guardrails er AWS‑native, så platformslåsning består. Mit råd er pragmatisk: hold værktøjs‑interfaces og prompts modulære, så alternative backends i det mindste er mulige senere. Skift er ikke gratis – men fastlåsning er dyrere.
Modeller opdateres. Når Nova Pro eller en anden FM skifter version, kan svargeneratoren ændre “stil”. Planlæg regressionstests med faste scenarier og kendte logs for at fange afvigelser tidligt. Bloggen giver ingen procedurer eller benchmarks her, se 2277. Guiden er stærk som start – ikke som driftshåndbog.
Marked og alternativer
Det er rimeligt at forvente lignende mønstre hos Microsoft\/Azure og Google. AWS’ særkende her er koblingen til Bedrock AgentCore med MCP‑servere mod AWS‑universet og en samlet CloudFormation‑udrulning, se 2277. Om det giver hurtigere vej til produktion afhænger af lokale krav til sikkerhed, compliance og værktøjslandskab. Ingen én‑størrelse‑passer‑alle.
Konkurrenter vil fremhæve deres egne observability‑stakke og copilots. Fair. Er man allerede dybt i AWS, er pointen, at agenten samler CloudWatch, docs, re:Post og Support i ét flow, et tungt argument, se 2277. Spørgsmålet er ikke, om det kan køre – men hvordan det skal køre hos jer uden nye blinde vinkler.
Hvad der stadig mangler dokumenteret
Reporting‑gaps: ingen konkrete IAM‑policyeksempler, ingen tal for latenstid og pris under last, ingen detaljer om datalokalitet og retention for MCP‑servere og AgentCore Memory, ingen mekanik til konflikthåndtering mellem kilder eller teknisk validering af FM‑svar, se 2277. Og ingen feltdata for faktisk MTTR‑reduktion efter implementering. Påstanden om 30–45 minutters sparet kontekstskift er central, men kræver lokal verifikation, se 2277.
Det praktiske bundtræk
Ressourceprofilen er ligefrem: platform‑ingeniør til runtime og CI\/CD, sikkerheds\/IAM‑specialist til tilladelser og audit, SRE\/ops til playbooks og kvalitet samt en data‑ eller prompt‑ingeniør til værktøjsgrænser og samtalekontekst. Fire hatte – nogle gange tre, hvis én bærer to. Juridisk\/compliance bør med, hvis logs kan indeholde PII – guardrails hjælper, men dokumenterer ikke efterlevelse, se 2277.
Instrumentering er lavthængende frugt: mål API‑latens, tokenforbrug, succesrate for automatiserede handlinger, antal manuelle kontekstskift fjernet pr. sag og tid til første plausible årsag. Læg det ved siden af jeres MTTR. Først dér kan man regne ROI. Ikke på slide 1 – men efter to‑tre uger med rigtige hændelser.
Konklusion
AWS‑guiden er et brugbart startpunkt til en AI‑assistent, der samler de første skridt i incident‑undersøgelser i én samtalegrænseflade, se 2277. Det er praktisk og kan spare tid – hvis man investerer i IAM‑stramninger, auditerbarhed, playbooks og en målbar pilot. Dokumentationshullerne (policies, performance, datalivscyklus) skal lukkes lokalt, før udrulning i bredde.
