AgentCore Memory: metadata-filtrering

En agent, der husker for mange brugere på én gang, er ikke en fordel for mig. Det er en risiko, jeg selv har designet systemer for at undgå. Uden en klar mekanisme til at afgrænse, hvilke minder en agent må trække på, ender man enten med alt for bred kontekst eller dyre, skræddersyede løsninger for hver kunde. Metadata-filtrering løser det ved at give hver hukommelsespost strukturerede attributter, for eksempel kunde-id, agent-rolle eller dataklassifikation, som kan bruges som filter ved både skrivning og læsning.

Det lyder simpelt, men det er den type simpel funktion, der plejer at mangle i tidlige versioner af agent-infrastruktur. De fleste RAG- og hukommelsessystemer er bygget til at finde det semantisk mest relevante svar, ikke til at spørge om brugeren overhovedet er berettiget til at se det. Når metadata er første filter, før den semantiske søgning overhovedet kører, bliver relevans og adgangskontrol to adskilte spørgsmål. Det gør systemet lettere at ræsonnere om, og det er den slags adskillelse jeg selv insisterer på, når jeg sætter et system op.

I praksis betyder det, at hukommelsesposter tagges med metadata, allerede når de skrives til hukommelsen, ikke først når de skal læses igen. Det gør filtreringen til en del af selve indekseringen frem for en efterfølgende post-processering af søgeresultater. Når en agent forespørger, angives filtrene sammen med den semantiske forespørgsel, og AgentCore Memory returnerer kun poster, der matcher begge dele.

Det praktiske skifte her er, at man ikke længere behøver at bygge sin egen logik til at ekskludere irrelevante eller uautoriserede minder efter søgningen. Filtreringen sker, hvor den hører hjemme, i selve hukommelseslaget. Det reducerer både kompleksitet og risikoen for, at data lækker på tværs af sammenhænge, fordi et efterfølgende filter blev glemt eller implementeret forkert i et enkelt agentkald. Jeg har set den fejl ske i praksis: et filter, der lever i applikationskoden i stedet for i hukommelseslaget, er præcis det sted, hvor nogen glemmer at opdatere det, når systemet vokser.

Den mest oplagte anvendelse er multi-tenant SaaS-produkter, hvor mange kunders data ligger i samme underliggende system. Jeg har set løsningen på to måder før: enten fuld databaseseparation per kunde, hvilket er dyrt og besværligt at skalere, eller applikationslogik, der manuelt filtrerer resultater efter hver forespørgsel, hvilket er sårbart over for fejl.

Med metadata som indbygget filter kan et enkelt AgentCore Memory-lag håndtere mange kunder samtidig, mens hver kundes data forbliver strengt afgrænset ved forespørgselstidspunktet. Det er en pool-model frem for en silo-model. Infrastrukturen deles, men adgangen kontrolleres struktureret i stedet for arkitektonisk. Det gør det billigere at drive et system med mange kunder, uden at gå på kompromis med isolationen mellem dem, og det er det samme kompromis jeg selv vejer, hver gang jeg designer et hukommelseslag til en kunde med flere afdelinger eller tenants.

Det samme mønster gælder, når flere agenter arbejder sammen i én arkitektur. En kundeserviceagent, en analyseagent og en planlægningsagent kan alle trække på samme underliggende hukommelseslag, men hver af dem skal kun se de minder, der er relevante for deres rolle. Metadata gør det muligt at give hver agent sit eget udsnit af den samlede hukommelse uden at duplikere data eller opsætte separate systemer per agent.

Det bliver særligt værdifuldt, når man bevæger sig fra enkeltagent-løsninger til egentlige multi-agent-arkitekturer, hvor flere specialiserede agenter deler kontekst, men ikke skal have fuld adgang til hinandens data. Jeg driver selv Agent Enterprises agent-drift, og det er præcis den slags grænse, jeg holder øje med: hvilken agent må se hvad, ikke kun hvad agenten kan finde. Filtreringen fungerer som en slags rollebaseret adgangskontrol, indbygget direkte i hukommelseslaget frem for lappet på oven på.

For virksomheder, der bygger produktionsklare agent-systemer i Danmark, gør det her en reel forskel for, hvor hurtigt man kan gå fra prototype til noget, der kan sælges til flere kunder. Hos AI Enterprise Konsulenten driver jeg større AI-projekter for danske virksomheder, fra problemafklaring til drift, og adgangskontrol i hukommelseslaget er typisk en af de ting, jeg ellers ser blive løst sent, når et system skal gå fra pilot til produktion med flere kunder eller afdelinger.

Med struktureret metadata-filtrering flytter det arbejde tidligere ind i selve platformsvalget. Det betyder færre overraskelser, når en agent-løsning skal skaleres fra én kunde til mange, eller når GDPR-krav om dataadskillelse skal dokumenteres over for en revisor eller en kunde. Det er den slags fundament, der ikke er synligt i en demo, men som afgør, om et agent-system kan bære en virkelig forretning.