AWS har gjort Amazon Bedrock AgentCore harness generelt tilgængelig efter en preview i april. Løftet er klart: definer en produktionsklar agent med to API‑kald og kør den i et isoleret miljø, uden at bygge al orkestreringen fra bunden. Lad os være ærlige: det er netop der, mange projekter går i stå.
Behovet har været tydeligt længe. Ikke fordi agent‑loopet er svært, men fordi alt omkring det er det: infrastruktur, sikkerhed, netværk, observability. Det er forskellen mellem demo og drift.
Hvad AgentCore er — kort, konkret
AgentCore beskrives som et sæt primitives, der tilsammen dækker skelettet til en produktionsagent. Ifølge AWS’ blog er der seks navngivne byggeklodser: Runtime, Memory, Gateway, Browser, Identity og Observability. I stedet for at teams trækker alle kabler selv, leverer AgentCore en managed kobling mellem komponenterne, som man konfigurerer.
Pointen er, at harnesset pakker kompleksiteten væk uden at fjerne kontrollen. Du styrer stadig modelvalg, værktøjer og instruktioner — du slipper bare for at genopfinde sandbox, shell, filsystem, tråde, state og sporbarhed hver gang.
Primitives i praksis
Runtime er eksekveringsmiljøet. Her kører agenten med shell og filsystem, så den kan læse filer, køre kommandoer og skrive kode i en isoleret kontekst. Memory håndterer samtale‑ og brugerkontekst på tværs af sessioner. Gateway er døren ud til værktøjer og MCP‑servere, mens Browser er webadgang. Identity styrer hvem der er hvem, og Observability leverer streaming af agentens skridt samt tracing ind i CloudWatch.
Det lyder banalt på papir — det er det ikke i drift. En standardiseret måde at binde delene sammen på sparer tid og reducerer risiko, men den fjerner ikke alle valg.
Hvordan du kommer i gang: Create
Harness og InvokeHarness
Kernen er de to kald, AWS fremhæver: CreateHarness til at beskrive agenten og InvokeHarness til at køre den. CreateHarness accepterer en JSON‑beskrivelse, hvor man blandt andet angiver hvilke værktøjer agenten må bruge. Dokumentationen nævner støtte for glob‑mønstre, for eksempel * til alle værktøjer, @builtin for indbyggede værktøjer og @serverName\/toolName for specifikke MCP‑værktøjer.
CreateHarness understøtter også idempotency‑token til sikker kørsel i CI, samt felter til miljø‑ og netværksopsætning og et miljø‑artifact — typisk et container‑image med afhængigheder. Det gør det oplagt at versionere harness‑definitioner i git og teste dem som kode. InvokeHarness er det operationelle kald, der starter en kørsel; bloggen beskriver det, men de fulde request\/response‑detaljer for kaldet var ikke tilgængelige i det fremlagte API‑materiale. Det hul bør lukkes før hård produktion.
Sandbox, sikkerhed og isolation
Agenten kører i et isoleret miljø med eget filsystem og shell. Det betyder, at værktøjer og kodekørsler ikke lander på delte noder uden rammer. Isoleringen giver en forudsigelig måde at håndtere læse‑ og skriveadgang til filer og en base for at begrænse netværksadgang — hvis det konfigureres korrekt.
Men der opstår straks spørgsmål, som ikke er fuldt besvaret i den offentlige dokumentation: hvor præcist kan man definere egress‑regler, hvordan spiller det sammen med VPC og firewalls, og hvornår kræver det eget image med strammere politikker. CreateHarness peger på konfigurationssporene, men teams må regne med sikkerhedsreview og test.
Orkestration vs. agent‑loop: Hvor ligger værdien?
AWS’ blog rammer en pointe: agent‑loopet er ikke det svære. Orkestrering og infrastruktur er. Teams bruger tiden på framework‑valg, forsvarlig værktøjsforbindelse, provisioning af sandboxet compute, secrets, netværk, lagring og observability — og det skalerer yderligere, når brugere, isolation, identiteter og kapacitet kommer på. Det matcher også Snillds fortolkning af, hvor arbejdet reelt ligger.
AgentCore forsøger at gøre alt det til konfiguration fremfor specialkode. Det er værdien. Og grænsen. For man skal stadig beslutte, hvilke værktøjer agenten må bruge, hvordan de autoriseres, og hvad der sker, når noget fejler halvvejs inde i et loop.
Observability, tracing og drift
Et stærkt kort er, at alle skridt fra agenten kan streames i realtid og automatisk traces i CloudWatch. Det er guld, når man fejlsøger et værktøjskald, eller når revisionen beder om dokumentation for, hvad der skete hvornår.
Det løser dog ikke alt. Alarmer, retention‑politikker, SLI\/SLO for agentrespons og særskilt logning af værktøjskald er stadig kundens opgave. Spørgsmål om vendor‑lock‑in og dataresidency står også åbne: hvor gemmes memory‑state og traces, hvor længe, og kan man flytte dem. Bloggen og de tilgængelige dokumenter giver ikke fuld klarhed her — noter det til compliance‑gennemgang.
Konkrete implementeringskonsekvenser
Der er fire praktiske konsekvenser, man mærker hurtigt. Først modelswapping: man kan vælge model ved CreateHarness og, ifølge AWS’ beskrivelse, overstyre ved InvokeHarness. Det åbner for pris\/ydelse‑tests og skift ved regressioner. Fint — men det kræver en cost‑model og audit på tværs af leverandører.
Dernæst tool‑authorization: gateway‑ og MCP‑koblinger gør det let at tilføje værktøjer, men øger også risikoen, hvis autorisationen er for bred. Indfør mindst ét eksternt godkendelseslag, før nye værktøjer bliver tilgængelige for en agent i produktion.
Tredje punkt er test og staging: når harness‑definitioner er JSON, kan de indgå i CI som kode. Det gør rollback og blå\/grøn‑mønstre realistiske. Men uden klar idempotency og test‑suite risikerer man driftssjusk i stor skala.
Sidst skaleringsmønstre og omkostninger: isolering og concurrency‑primitives hjælper, men hyppigheden af InvokeHarness‑kald og modelvalg driver regningen. Rate‑limiter, kvoter og fornuftig batching bliver nødvendige, ikke bare pæne ord.
Hvad AgentCore ikke automatiserer
Det automatiserer ikke governance. Der skal stadig defineres politikker for, hvem der må koble hvilke værktøjer på hvilke agenter, og hvordan secrets udstedes, roteres og tilbagekaldes. Det automatiserer heller ikke performance‑tuning af modeller eller datasanitering før prompts.
Det leverer heller ikke en færdig CI\/CD‑praksis. Teams skal selv bygge pipelines til at validere og versionere harness‑definitioner, køre sikkerhedstests på miljø‑artifacts og sikre reproducerbare builds. Og det adresserer ikke overvågning uden for CloudWatch, hvis man bruger en eksisterende observability‑stack — integration skal planlægges.
Hvem det giver mest mening for — og hvem bør vente
Startups med få systemer og høj eksperimenthastighed vil sandsynligvis få stor glæde nu: en agent i luften hurtigt og mulighed for retning uden at rive fundamentet op. Etablerede virksomheder med DevOps‑disciplin og et klart tool‑inventory kan også høste gevinster, især hvor gentagne agentmønstre ellers ville blive kopieret.
Sikkerheds‑ og compliance‑tunge brancher bør tempo‑styre. Ikke fordi værktøjet er svagt, men fordi uafklarede detaljer om dataresidency, netværksgrænser og retention kræver afklaring. Start i en stramt afgrænset pilot med aggressive guardrails.
Praktisk tjekliste før pilot
- Lav et inventory over værktøjer og MCP‑servere og marker hvilke der må bruges i første omgang. Smalt er godt.
- Udarbejd en enkel threat‑model for agenten: hvor kan den gøre skade, hvis et værktøj misbruges.
- Sæt idempotency‑politikker og læg harness‑definitioner i git med PR‑krav. Ingen manuelle ændringer i konsollen.
- Definér en observability‑baseline: hvilke events skal traces, hvor længe, og hvem får alarmer.
- Skriv 10 konkrete testcases for værktøjskald, netværksadgang og fejlscenarier. Kør dem i CI.
- Etabler cost‑guardrails: kvoter, rate‑limiter og alarmer pr. model og pr. agent.
- Afklar dataresidency‑krav for memory og logs. Dokumentér hvor data bor.
- Planlæg rollback: versionér miljø‑artifacts, og hav en kendt sidste‑gode build at falde tilbage på.
Uafklarede felter
Der mangler i det offentlige materiale en fuld reference for InvokeHarness’ request\/response og detaljer om netværksgrænser, herunder VPC‑peering og egress‑kontrol. Der er heller ikke klare beskrivelser af hvilke identity‑providers der støttes direkte via Identity‑primitiven, eller hvordan nøgler og secrets rulles i drift.
Endelig er der behov for officielle anvisninger på retention‑konfiguration for memory og tracing, samt anbefalinger til versionering og opgradering af miljø‑artifacts. Indtil da: dokumentér jeres egne standarder, og test dem hårdt.
Afslutning: Kort, ærlig anbefaling
AgentCore som GA er et fornuftigt skridt mod at gøre agenter kedeligt driftsbare. To API‑kald, standardiserede primitives og et isoleret runtime adresserer netop det lag, der plejer at være tungt. Værdien er reel, især hvor man ellers ville genopføre den samme orkestrering igen og igen.
Det ændrer ikke på, at arkitekter stadig skal træffe de svære valg om autorisation, netværk, observability og omkostninger — og at nogle compliance‑spørgsmål stadig kræver flere svar fra AWS. Anbefalingen: byg en stram pilot, mål på drift og omkostning, og behold evnen til at rulle tilbage. Forskellen mærkes først, når man sidder med det i hænderne.
