AgentCore hukommelse: lifecycle-politikker

En agent, der husker alt, den nogensinde har set, bliver langsomt dårligere, ikke bedre. Hver session lægger nye erindringer oven i de gamle, og uden en mekanisme til at luge ud vokser hukommelsen sig så stor, at søgninger bliver langsommere, og modstridende oplysninger begynder at konkurrere om agentens opmærksomhed. En kundeserviceagent, der for seks måneder siden lærte, at en kunde havde et bestemt problem, kan sagtens trække den forældede information frem igen, selv om problemet er løst for længst.

Det er den slags drift, der gør langtidskørende agenter upålidelige i praksis. Jo længere en agent har kørt, jo større er risikoen for, at dens svar bygger på noget, der ikke længere er sandt. Uden en systematisk måde at skelne relevant fra forældet hukommelse på ender man med at skulle nulstille agenten helt, hvilket smider al den værdifulde kontekst ud sammen med skidtet.

AgentCore Memory's lifecycle-politikker kører som et natligt gennemløb, der behandler hukommelsen i tre trin. Først scores hver erindring efter relevans og alder, dernæst konsolideres beslægtede erindringer, så de ikke optræder som fragmenterede, modstridende brudstykker, og til sidst udrenses det, der scorer under en given tærskel.

Det, der gør tilgangen brugbar i praksis, er at den arbejder automatisk uden at kræve, at udviklere skriver deres egen ryddelogik for hver enkelt agent. I stedet definerer man en politik, der beskriver, hvor længe en given type hukommelse skal leve, og hvornår den skal konsolideres frem for slettes helt. Det betyder, at en agent, der arbejder med hurtigt skiftende data, som lagerstatus eller prisinformation, kan få en kort levetid på sin hukommelse, mens en agent, der bygger på stabil domæneviden, kan beholde sin hukommelse længere.

Konsolideringstrinnet er særligt værdifuldt, fordi det ikke bare sletter, men samler flere delvise erindringer til én sammenhængende. Det reducerer støj i det, agenten trækker frem ved en forespørgsel, uden at man mister den underliggende kontekst.

Lifecycle-pipelinen er bygget op omkring AWS Step Functions, som orkestrerer de tre trin, og leveres som en deploybar CDK-stack. Det betyder, at teams, der allerede arbejder med infrastructure as code i deres AWS-miljø, kan sætte lifecycle-rensning op ved siden af deres eksisterende AgentCore-opsætning uden at bygge det fra bunden.

Det praktiske ved den tilgang er, at rensningen bliver en del af den samme driftsdisciplin, man i forvejen har for resten af infrastrukturen. Man kan versionsstyre politikkerne, teste ændringer i et staging-miljø, og rulle dem tilbage, hvis en justering af scoringslogikken viser sig at rense for aggressivt. Det er en markant anden tilgang end at lade forældet data samle sig op, indtil nogen opdager problemet ved et uheld.

Jeg kører selv Agent Enterprises agenter i produktion, og for et par måneder siden så jeg netop den fejl: en supportagent begyndte at citere en returpolitik, der var seks uger gammel, til en kunde, der spurgte om den aktuelle. Ingen havde ryddet i hukommelsen, så den gamle version lå og konkurrerede med den nye, og agenten valgte forkert. Det er præcis den slags vedligehold, man tidligere måtte bygge selv fra bunden, før det blev en indbygget politik i AgentCore.

For virksomheder, der driver AI-agenter i sektorer med dokumentationskrav, som finans, sundhed eller offentlig forvaltning, er automatisk rensning af forældet hukommelse ikke kun en teknisk detalje. Det er en compliance-mekanisme. Hvis en agent kan blive ved med at referere til en forældet politik eller et forkert prisniveau, fordi ingen har ryddet op i dens hukommelse, opstår der en dokumenteret risiko for, at agenten giver kunder eller medarbejdere forkert information.

Det betyder også, at man kan bygge agent-løsninger, der er beregnet til at køre i årevis, uden at kvaliteten af svarene forringes gradvist. En agent, der løbende renser sin egen hukommelse for det, der ikke længere er relevant, holder sig skarpere og mere til at stole på, end en, der samler alt op uden at skelne.

For danske virksomheder, der overvejer at sætte AI-agenter i drift på tværs af kundeservice, drift eller intern rådgivning, er det her et af de tekniske valg, der afgør, om projektet holder efter det første halve år, eller om det ender med at kræve konstant manuel efterkontrol.