AWS har lagt en teknisk gennemgang ud om, hvordan man designer namespaces i AgentCore Memory i Amazon Bedrock. For teams der bygger stateful agenter, er timingen god. Vi ser rod i hukommelsen, fejlhentninger og små sikkerhedsbrud, der vokser ved audit. Forskellen ses i drift (AWS ML Blog).
Kernen: AgentCore Memory organiserer langtids-hukommelser med hierarkiske stier, som mappeveje, og det styrer både organisering, retrieval og adgangskontrol. Rammes stierne rigtigt, bliver svarene renere og billigere. Rammes de forkert, stiger kald, latenstid og støj. Vi har oplevet begge dele i felten.
Hvad AWS faktisk siger
Blogindlægget beskriver namespaces som hierarkiske stier, der kan hentes på flere niveauer, ikke kun på bladet. Eksemplerne er konkrete: en brugers præferencer under /actor/customer-123/preferences/ og en sessionsopsummering under /actor/customer-123/session/session-789/summary/ (kilde).
AgentCore understøtter namespace-templates med tre variabler: {actorId}, {sessionId} og {memoryStrategyId}. De udfyldes, når events processeres, så strategier skriver til forudsigelige stier. AWS viser strategier til fakta per bruger og opsummeringer per session, der efterfølgende kan hentes hierarkisk eller med eksakt match (kilde, docs).
Hvorfor det her betyder noget i drift
Organiseret hukommelse reducerer støj, latenstid og token-forbrug. Fejlhentninger koster. AWS understreger, at korrekt design af hierarki og retrieval-mønstre er afgørende for en effektiv memory-løsning, og det matcher vores erfaring (kilde).
Sikkerhed fylder også. Navngivning og isolation er første værn i multi-tenant. Ligger personlige præferencer for bredt, bløder de ud mellem brugere. Det har vi set i praksis hos kunder, anonymiserede observationer fra Snilld, og det ender hurtigt som et audit-find.
Fra partition keys til hierarkier
Den nyttige mentale model fra AWS: Tænk i partition keys og S3-mapper, med et tvist. Her understøttes både hierarkisk retrieval og eksakt match. Planlæg retrieval-mønstre, før du fryser strukturen. Omvendt rækkefølge er dyr i migrationer (kilde).
Et simpelt valg: præferencer hentes ofte hierarkisk, fx /actor/{actorId}/preferences/. Sessionspecifik analyse hentes normalt med eksakt match, fx /actor/{actorId}/session/{sessionId}/summary/. Småt i design, stort i drift.
Kort ordliste
Actor er entiteten (typisk en slutbruger) som data tilhører. Session er et sammenhængende samtaleforløb. Strategy er identifikator for en langtids-hukommelsesstrategi. De tre begreber afspejles i namespace-templates og bruges til isolation og hentning (docs).
Templates og resolution uden dikkedarer
Du definerer namespace-templates pr. memory-strategi. Når events lander, udfylder AgentCore {actorId}, {sessionId} og evt. {memoryStrategyId}, så der opstår entydige stier per strategi, bruger og session (docs). Strategy-id gør det muligt at køre parallelle langtids-hukommelser for samme bruger. Stærkt, men kræver en klar navngivningskonvention.
Vi ramte engang et anonymiseret tilfælde, hvor strategy-id ikke var med i stien. Resultater blev blandet ved retrieval. Ikke en platform-bug, en designfejl. Vi brugte en halv dag på at finde den. Det gør man kun én gang.
Adgangskontrol og governance
AWS beskriver integration med IAM, så rettigheder kan styres på namespace-niveau. Isolation-boundaries bliver både logiske og håndhævede. Politikker bør spejle stierne: adgang til /actor/{actorId}/ er ikke det samme som adgang til hele /actor/ (kilde).
Eksempel på pseudo-IAM (intentionen, ikke fuld policy):
{
"Effect": "Allow",
"Action": ["bedrock:ReadMemory", "bedrock:WriteMemory"],
"Resource": ["arn:aws:bedrock:...:memory/CustomerSupportMemory"],
"Condition": {
"StringLike": {"agentcore:Namespace": "/actor/${aws:userid}/*"}
}
}
Og en enkel CI-test-idé i pseudo, der fanger for brede wildcards:
assert_no_policy(
where Action includes ReadMemory and
Condition.StringLike["agentcore:Namespace"] matches "/actor/*"
)
Dokumentationen beskriver IAM-integration, men går ikke i dybden med revisions-egnede logformater og retention. Tag det som en opgave: få sat sporbarhed op, der kan tåle et audit.
Designmønstre der virker – og klassiske anti-mønstre
Tre mønstre, vi anbefaler, i tråd med AWS’ ramme:
- Actor-scoped:
/actor/{actorId}/preferences/for stabil, tvær-session viden. Enkel rettighedsstyring. - Session-scoped:
/actor/{actorId}/session/{sessionId}/summary/til kortlivede, præcise opsummeringer. - Strategy-id isolering:
/actor/{actorId}/{memoryStrategyId}/facts/ved parallelle langtids-strategier.
Tre typiske fejl, og hvad de koster:
- For brede namespaces:
/actor/all-customers/preferences/. Konsekvens: blandede præferencer og muligt persondata-issue. Vi har set præcis dén ende med en rød markering ved audit (Snilld, anonymiseret). - Kolliderende hierarkier: to strategier gemmer lignende data under forskellige stier. Retrieval bliver hul. Løs: central naming-standard og PR-review.
- Manglende access scoping: læseadgang gives på
/actor/i stedet for/actor/{actorId}/. Ét wildcard for meget, og roller ser for meget.
Konsekvenser for drift og arkitektur
Navnerum påvirker logning, backup og migration. Vi lægger namespaces i infrastructure-as-code. Ikke som runtime-justering. Det gør ændringer forudsigelige.
- CI/CD for memory-resources: namespace-templates i Terraform eller CloudFormation med PR-review og plan-diffs.
- Migrationsscripts: når en sti ændres, flyttes historik kontrolleret og idempotent. Test i et miljø først.
- Retention/TTL: giv session-summaries udløb. Ellers vokser omkostning og støj.
Migrering uden nedetid
Kort pseudoproces til at omdøbe stier:
# 0) Freeze writes til gammel sti (kort vindue)
# 1) Export: list long-term records under /actor/{actorId}/old/...
# 2) Transform: map til /actor/{actorId}/new/... (inkl. {memoryStrategyId} hvis relevant)
# 3) Upsert til ny sti (idempotent write; bevar originale tidsstempler hvis muligt)
# 4) Dual-read periode: retrieval kigger i ny først, ellers gammel
# 5) Backfill jobs gentages til hit-rate på ny sti er >= X%
# 6) Cutover: slå gammel sti fra i retrieval
# 7) Retention-sletning af gammel sti efter karens
# Rollback: behold eksport-snapshot og peg retrieval tilbage til gammel sti
Faldgruber: bland ikke strategy-ids, og sørg for at tests dækker både hierarkisk og eksakt match.
Hvad vi har set hos kunder
Tre korte cases, anonymiseret fra Snilld:
- Support-agenten blev for uformel: Uden skarp actor-scoping trak agenten tone-præferencer på tværs. Vi indførte
/actor/{actorId}/preferences/og en enkel IAM-regel. Stabilt på et døgn. - Sessionsarkiv for dyrt: Alle summaries blev gemt for evigt. Retrieval blev langsom. En 30-dages TTL og en pinned summary pr. kvartal halverede omkostningen og hævede relevansen.
- Strategi-kollision: To strategier skrev næsten samme sted. Halvdelen af facts forsvandt i retrieval. Et eksplicit
{memoryStrategyId}i stien og review-krav løste det.
Testplan og målepunkter
Byg en enkel staging-protokol over to uger:
- Hit-rate pr. prefix: andel retrievals der returnerer ikke-tomme, relevante træf.
- Gns. retrieval-latenstid pr. mønster: hierarkisk vs. eksakt match.
- Token-forbrug pr. retrieval og pr. svar.
- Omkostning pr. 1000 retrievals og pr. 1000 svar.
- Fejlrate ved adgangsafslag: hvor ofte blokerer IAM på forsøg uden for scope.
Sæt tærskler, og brug data til at justere dybden på hierarkiet. Ingen mavefornemmelser.
Desktop-native agenter og usynlig viden
VentureBeat beskriver, at AWS Quick som desktop-native agent kan bygge en personlig knowledge graph fra lokale filer, kalender, mail og SaaS, ofte uden for et centralt kontrolplanes synsfelt (VentureBeat). Oversat til arkitektur: Ikke al state bor i AgentCore Memory. Sørg for synkronisering eller bevidst isolation, så der ikke opstår spøgelser i svarene.
Hvad namespaces ikke løser
Namespaces organiserer og afgrænser adgang. De løser ikke semantisk søgning, vektor-dimensioner eller deduplikering. Vil du have semantisk match, må du supplere med en vector store eller en semantisk strategi, stadig under en god sti (kilde).
Der er huller i det offentlige materiale: ingen åbne benchmarks for latenstid eller omkostning vs. hierarki-dybde, sparsom vejledning om audit-logging og intet om race conditions ved samtidige writes. Vores anbefaling er enkel: konservativt design, idempotente writes og mål selv.
Gør hullerne operationelle
Tre konkrete TODOs til jeres backlog:
- Kør 14 dages måling i staging på hit-rate, latenstid, token-forbrug og omkostning pr. 1000 retrievals og del rapporten i teamet.
- Definér et revisionsspor pr. namespace-prefix, der kan vises ved audit, hvem læste hvad og hvornår.
- Lav en write-conflict test: to strategier skriver samtidig til samme sti. Dokumentér forventet adfærd, og bekræft idempotens.
En kort tjekliste der faktisk virker
- Definér retrieval-scenarier først, per session, per actor, per strategi.
- Design namespace-templates, der afspejler de scenarier. Inkludér
{memoryStrategyId}ved parallel læring. - Læg templates i IaC. Ingen manuelle ændringer i prod.
- Sæt IAM på prefix-niveau. Test i CI, at nye stier ikke udvider adgang utilsigtet.
- Etabler retention/TTL for session-scoped hukommelser. Pin kun varig værdi.
- Byg retrieval-tests for både hierarki og eksakt match, inkl. negative tests.
- Planlæg migration og rollback. Idempotente writes.
- Overvåg hit-rate, latenstid, tokens og omkostning pr. 1000 retrievals.
Vores vurdering
Hvis vi startede et enterprise-projekt i morgen, gjorde vi tre ting fra dag ét: 1) Fastlagde retrieval-scenarier og skrev namespace-templates i IaC. 2) Lagde IAM på prefix-niveau med tests. 3) Indførte TTL for sessioner og en pinned summary-mekanik. Kedelige skridt, ja. De giver ro i maskinen.
To åbne spørgsmål, vi vil svare på i drift: Hvad er den faktiske latenstidsforskel mellem dybe og flade hierarkier ved høj belastning. Og hvordan ser en revisionsklar access-log pr. namespace mest praktisk ud. Svarene bor i jeres målinger.
Kilder og videre læsning
- AWS ML Blog: Organizing Agents’ memory at scale – Namespace design patterns in AgentCore Memory
- AgentCore Memory Organization Documentation
- VentureBeat: AWS Quick’s personal knowledge graph…
