Bedrock AgentCore generelt tilgængelig

Kernen er en runtime der starter en isoleret session for hver agentopgave. Man kalder CreateHarness for at oprette agenten og InvokeHarness for at køre den, og resten, skalering, isolation og ressourcestyring, klarer tjenesten. Ingen containere man selv skal bygge, ingen orkestreringskode.

Jeg vil ikke lade som om det ikke er noget. At få en agent til at håndtere mere end én bruger ad gangen, uden at et team først bygger kø, skalering og isolation, er præcis den kedelige del der får de fleste proof-of-concepts til at strande. Hvis to kald reelt fjerner den, flytter det tiden fra prototype til noget kolleger kan bruge fra uger til timer. Det er den slags jeg selv bruger dage på at bygge for kunder, så jeg kan godt se hvad det er værd.

Hver session kører i sit eget isolerede miljø med et filsystem og en shell. Det lyder som en detalje. Det er det ikke. En agent der kun kan svare i tekst er en rådgiver. En agent der kan læse og skrive filer, køre scripts og navigere et filsystem kan udføre arbejde: generere en rapport, behandle et dokument, køre en analyse der kræver mellemtrin.

Isolationen betyder at én brugers session ikke kan røre en andens. Det er ikke valgfrit når man sætter agenter i produktion over for eksterne brugere. Men her ligger også den første grænse jeg altid tjekker: hvad må agenten røre inde i det miljø, og hvad sker der når den tager fejl med selvtillid. Sandkassen giver dig muren. Den skriver ikke reglerne for dig.

AgentCore giver vedvarende hukommelse, så en agent kan huske kontekst fra tidligere sessioner i stedet for at starte forfra hver gang. Det er forskellen på en chatbot der glemmer alt efter hver samtale og en agent der husker præferencer og tidligere beslutninger. Dertil kommer webadgang, så den kan hente opdateret information i stedet for kun at læne sig på træningsdata.

For mine europæiske kunder stopper jeg altid op her. Vedvarende hukommelse betyder persondata der bliver liggende, og webadgang betyder en agent der henter og sender data ud af huset. Det er ikke en showstopper, men det er et GDPR-spørgsmål man skal have svar på før lancering, ikke efter. Hvor ligger hukommelsen, hvem kan læse den, og kan jeg slette den på forlangende.

AgentCore taler Model Context Protocol, som er ved at blive de facto-standarden for hvordan agenter kobler sig til værktøjer og datakilder. Det betyder at man ikke skal bygge integrationer fra bunden for hvert værktøj, men kan trække på et voksende økosystem af MCP-kompatible værktøjer. Det er reelt nyttigt, og det er den slags standardisering jeg har savnet.

Man kan også skifte modeludbyder midt i en samtale uden at konteksten går tabt. Det løsner dig fra at være låst til én sprogmodel, og det åbner for at bruge en hurtig, billig model til de simple forespørgsler og en tungere model når opgaven kræver dybere ræsonnement. Ironisk nok er det den ene form for lock-in tjenesten gør noget ved, mens den bygger en ny et lag længere nede.

Den del af agent-udvikling, der oftest bliver overset i planlægningsfasen, er overvågning: hvordan ved man, hvad agenten gjorde, hvorfor den traf en given beslutning, og hvor den fejlede. AgentCore leverer automatisk sporing til CloudWatch, så hvert trin i en agents beslutningsproces logges uden at udvikleren selv skal bygge det logging-lag.

Det er den slags infrastruktur, der ofte ender med at tage lige så lang tid at bygge som selve agenten, og som let bliver nedprioriteret, indtil noget går galt i produktion. Manglende overvågning kan efterlade et organisatorisk kontrolgab, når agenter først er i drift. Ved at gøre det til en indbygget del af platformen fjerner AWS en byrde, der ellers falder på det team, der skal drifte agenten efter lancering.

Samlet set peger AgentCore på en retning, hvor infrastrukturen omkring AI-agenter bliver en forudsætning, man abonnerer på, snarere end noget, man bygger selv. For virksomheder, der har ventet med at sætte agenter i produktion, fordi driftsdelen virkede uoverskuelig, fjerner det en væsentlig del af den bekymring.