Ifølge AWS er de modeller, der driver agenter i dag, meget kapable: de kan ræsonnere over komplekse problemer, planlægge flertrins-workflows og levere nuancerede svar. Alligevel præsterer mange agenter under niveau, fordi de mangler adgang til korrekt kontekst og systematisk feedback (AWS-bloggen). AWS præsenterer derfor nye AgentCore-funktioner, der skal forbinde agenter til mere viden, give indblik i drift og håndhæve kontroller, efterhånden som agenterne bliver mere kapable.
AWS beskriver tre videnlag til AgentCore, observability for at finde og rette fejl i produktion, samt governance-kontroller. Derudover introduceres en CLI, som kan oprette agentprojekter, deploye dem til AgentCore Runtime og invoke Python-agenter (AgentCore CLI-dokumentation). I det følgende angives tydeligt, hvor udsagn kommer fra AWS’ kilder, og hvor der refereres til Snillds operationelle anbefalinger fra manual briefen.
Hvad AWS konkret melder ud
AWS skriver, at AgentCore giver agenter “native access to three layers of knowledge,” som udvider hvad agenter kan nå og udføre. Det organisatoriske videnlag navngives som “Amazon Bedrock Managed Knowledge Base” (AWS-bloggen). Formålet er, at organisatorisk information, der typisk ligger spredt i SharePoint, Google Drive, Confluence, S3 og interne wikis, kan gøres tilgængelig uden at bygge egne ingestion-pipelines og vedligeholde data-freshness i hånden. AWS beskriver, at dette historisk ofte har taget måneder af engineering, før en agent kan svare på helt basale spørgsmål om virksomheden (AWS-bloggen).
Ud over det organisatoriske lag fremhæver AWS to andre lag: web-viden og betalt/licenseret viden. Ifølge AWS er idéen at lukke hullet mellem modelkapacitet og agentpræstation ved at give adgang til relevant kontekst samt feedback-sløjfer i drift. AWS formulerer det eksplicit: “The gap isn’t intelligence. It’s access to the right context and feedback” (AWS-bloggen).
Observability og governance ifølge AWS
På governance-siden beskriver AWS hensigten om kontroller, der kan skaleres. De åbne kilder her specificerer ikke granularitet på politikniveau, så praktiske spørgsmål om per-agent, per-miljø eller per-opgave politikker kræver supplerende dokumentation eller dialog med AWS.
CLI og runtime dokumenteret i AWS’ vejledning
AgentCore CLI’en fremgår eksplicit i dokumentationen som et værktøj, der kan oprette et agentprojekt, teste lokalt, aktivere observability, deploye til AgentCore Runtime, teste igen og invoke den kørende agent. Dokumentationen nævner også understøttelse af populære Python-agentrammer som Strands Agents, LangChain/LangGraph, Google ADK og OpenAI Agents (AgentCore CLI-dokumentation).
Ud fra de dokumenterede trin bliver arbejdsgangen mere standardiseret: opret projekt, test, slå observability til, deploy, test, invoke, opryd. Det er en relativt lige vej fra lokale eksperimenter til en runtime, som er beskrevet i AWS’ egen vejledning.
Relevans og begrænsninger, som kilderne peger på
Hvis agenter skal svare korrekt og opdateret, kræver det adgang til relevante kilder og feedback efter deployment. AWS’ blogindlæg fremhæver eksempler på, at mangel på adgang giver forkerte eller ufuldstændige svar: en kundeserviceagent uden adgang til refusionspolitik, en research-agent uden aktuel viden og en finansagent uden adgang til licenserede data (AWS-bloggen). AgentCore adresserer disse behov med de tre videnlag og de styrings- og driftselementer, AWS beskriver.
Samtidig efterlader de åbne kilder spørgsmål, som teams typisk vil skulle afklare: Hvilke observability-metrics følger med, hvor eksporteres de hen, og hvilken retention er standard? Hvilken granularitet kan governance-politikker udtrykke? Og hvilke forventninger kan man have til performance og driftsomkostninger i skala? Disse punkter er ikke dokumenteret med tal eller SLA’er i de henviste kilder.
Snillds operative anbefalinger fra manual brief
Snillds manual brief anbefaler tre praktiske skridt for at få værdi i en POC: kortlæg nøglekontekst, implementér kontrolleret adgang og introducér feedback/monitorering fra dag ét. Rådene er operationelle og skal læses som Snillds vurderinger baseret på kundecase-erfaringer, ikke som AWS-specifikationer (Manual brief).
Konkret indebærer det ifølge briefen at identificere de vigtigste kilder, der afgør rigtige svar i use casen, etablere sikker RAG og API-forbindelser til autoritative kilder og sørge for, at der fra start findes et målbart feedback-loop. Det stemmer overens med AWS’ pointe om, at adgang til korrekt kontekst og feedback er nøglen til at lukke kløften mellem model og agent i produktion.
Hvad man kan forvente, uden at overdrive
AWS skriver, at det historisk ofte har taget måneder at gøre organisatorisk information tilgængelig for agenter gennem skræddersyede ingestion-processer og vedligehold af data-freshness. AgentCores managed tilgang sigter på netop dette problemfelt. Det er rimeligt at forvente mindre friktion end ved håndrullede pipelines, men de offentlige kilder her giver ikke specifikke tids- eller ydelsesgarantier, som kan verificeres.
Observability-spørgsmål at afklare med AWS
Med udgangspunkt i AWS’ beskrivelse af observability som hjælp til at finde og rette fejl i produktion, vil følgende konkrete afklaringer være relevante for mange teams:
- Hvilke standardmålinger er tilgængelige for agentkald og værktøjsbrug (for eksempel latens og fejltyper)?
- Kan telemetri eksporteres til eksisterende platforme som CloudWatch eller tredjepartsværktøjer?
- Hvordan styres retention for spor og rå telemetri på tværs af miljøer?
Disse punkter fremgår ikke som færdige, talbaserede garantier i de åbne kilder her, men er vigtige at få på plads for at gøre en POC revisionsfast og skalerbar.
Governance-spørgsmål, før der skaleres
- Politikniveauer: per agent, per team eller per miljø.
- Logning og eventuel redaction af følsomme felter.
- Dataretention i vidensbaser og sletningsprocedurer.
- Muligheder for at eksportere driftsmålinger til SIEM/APM.
Alternative orkestreringsmønstre i debatten
VentureBeat refererer Stanford-arbejde om DeLM, der udfordrer antagelsen om en central “boss”-agent ved multi-agent-arbejde, og rapporterer om potentielt lavere omkostninger ved visse opgaver uden en central orkestrator (VentureBeat om DeLM). Det er en separat tilgang til koordinering, som relaterer til agent-arkitektur, men siger ikke noget om AgentCores datalag, observability eller governance.
For læsere er pointen blot, at orkestrering og adgang til viden er to spor: AWS’ AgentCore retter sig mod viden, drift og kontroller; forskningsarbejder som DeLM diskuterer, hvordan agenter koordinerer. Kilderne her understøtter den adskillelse.
Bundlinje med kilderne på plads
For tekniske teams giver det en sporbar ramme: brug AWS’ dokumenterede byggesten, men mål selv, dokumentér governance-valg og luk hullerne med konkrete spørgsmål til AWS, før I skalerer.
