Migrer agentiske workloads til AgentCore

Mønstret går igen i næsten alle agentprojekter, jeg støder på. En agent bygget i LangGraph fungerer glimrende lokalt, men rammer en mur, når den skal ud at leve i produktion. Der mangler en runtime, der kan skalere. Der mangler en gateway, der styrer adgangen til værktøjer. Der mangler en hukommelse, der husker samtaler på tværs af sessioner, uden at nogen selv bygger en database til formålet. Jeg har stået i præcis den situation hos Agent Enterprise, og jeg har set den samme mur hos en global virksomhed jeg har rådgivet, hvor et helt team brugte måneder på at bygge det lag selv, før agenten overhovedet kom i nærheden af rigtige kunder.

Det er den kløft, AgentCore er designet til at lukke. I stedet for at bede udviklerne om at omskrive agenten fra bunden, lader AWS koden fra LangGraph blive stående og flytter de operationelle dele ud til en administreret platform. Det er pragmatisk, og det betyder noget for enhver virksomhed, der har eksperimenteret sig frem til en fungerende agent og nu står med spørgsmålet: hvordan får vi den i drift uden at ansætte et helt infrastrukturteam?

Det første trin handler ikke om at ændre agentens logik, men om at give den et sted at bo. AgentCore Runtime overtager afviklingen, så agenten kan skalere med belastningen uden manuel konfiguration af containere eller overvågning af serverkapacitet. AgentCore Gateway styrer, hvilke værktøjer agenten må kalde, og fungerer som et governeret lag mellem agenten og de systemer, den rører ved, i stedet for at værktøjsadgangen ligger spredt ud over kode, som ingen længere har overblik over.

Den tredje del er hukommelsen. En kundeserviceagent, der glemmer alt mellem hver samtale, er ikke særlig nyttig i praksis. AgentCore Memory giver agenten en persistent hukommelse på tværs af sessioner, uden at teamet selv skal bygge og vedligeholde det lag. Tilsammen betyder de tre komponenter, at agenten går fra at være et script på en bærbar til en tjeneste med de egenskaber, jeg forventer af noget, der skal stå til rådighed for rigtige kunder.

Når infrastrukturen er på plads, kommer det andet trin, som er mere interessant rent teknisk. Selve agentens beslutningslogik flyttes fra LangGraph til Strands Agents, AWS' eget framework til agentisk adfærd. Det er ikke en udskiftning for udskiftningens skyld. Strands Agents er bygget til at spille sammen med resten af AgentCore-stakken. Det betyder, at planlægning, værktøjskald og hukommelsesopslag foregår inden for samme ramme i stedet for at være limet sammen på tværs af to økosystemer.

Det er her, mange migreringer går i stå, fordi teamet forsøger at bevare LangGraph-logikken uændret og bygge bro til den nye infrastruktur i stedet for at lade platformen håndtere det, den er bedst til. Ved at lade Strands Agents tage over for selve planlægningsdelen undgår man den bro og får en agent, hvor hele kæden, fra beslutning til hukommelse til værktøjskald, er tænkt sammen af samme platform.

Den reelle gevinst ved det her mønster er ikke, at koden bliver kortere. Det er, at teamet holder op med at være systemadministratorer for deres egen agent. Skalering, adgangsstyring og hukommelseshåndtering er opgaver, der kræver løbende drift, overvågning og fejlretning, uanset hvor godt de er bygget i første omgang. Når AgentCore overtager de dele, kan udviklingsteamet bruge tiden på det, der faktisk skaber værdi: at forbedre agentens svar, udvide dens værktøjer og teste den mod nye scenarier. Se en reference til Amazon Bedrock AgentCore-runtime for mere om den administrerede infrastruktur.

Det er også en påmindelse om, at agentisk AI ikke kun handler om, hvilken model der driver beslutningerne. Det handler mindst lige så meget om det lag, der holder agenten kørende, sikker og forudsigelig, når den rammer virkelige brugere.

Jeg oplever gentagne gange virksomheder, der har bygget en solid agentprototype internt, men venter med at sætte den i drift, fordi de operationelle spørgsmål virker uoverskuelige: hvem overvåger den, hvem skalerer den, hvem sikrer at hukommelsen ikke vokser sig ukontrollabel. To-trinsmønstret fra AgentCore er et konkret svar på den bekymring, og princippet gælder uanset om agenten er bygget i LangGraph eller et andet framework: skil agentlogikken fra driftsansvaret.

For danske og nordiske virksomheder vil jeg tilføje et forbehold mere, ud over spørgsmålet om ejerskab. Når data og hukommelse flyttes over på en amerikansk cloud-platform, er GDPR ikke en eftertanke, det er et krav, der skal afklares før migreringen, ikke efter. Det er en af grundene til, at jeg selv insisterer på lokal, GDPR-sikker infrastruktur, hvor det giver mening for kunden. AgentCore kan sagtens være det rigtige valg for et team uden kapacitet til at drive infrastrukturen selv. Men vælg det, fordi I har vejet kontrol, omkostning og compliance op mod hinanden, ikke fordi det var den letteste vej ud af notebooken.