Google Cloud lægger ifølge MarkTechPost en ny retning for agent‑hukommelse. I Googles generative‑AI‑repo findes nu et referenceeksempel, Always‑On Memory Agent, der behandler hukommelse som en løbende proces frem for ad‑hoc retrieval. Den er bygget med Google ADK, kører på Gemini 3.1 Flash‑Lite og bruger SQLite som lagring. Ifølge MarkTechPost indgår hverken vektorstore eller embeddings; i stedet skriver modellen strukturerede poster direkte til databasen.
Hvad er nyt i agenten
Ifølge MarkTechPost er Always‑On Memory Agent en letvægts baggrundsagent, der kører kontinuerligt. Arkitekturen består af tre specialiserede underagenter plus en orkestrator: IngestAgent, ConsolidateAgent og QueryAgent. Flowet er: ingest, periodisk konsolidering og forespørgsler med kildehenvisning. Simpelt at forklare, mere krævende at drifte.
Sådan arbejder de tre underagenter
Ifølge MarkTechPost håndterer IngestAgent indkommende indhold og bruger Geminis multimodale evner til at udtrække en kort opsummering, entiteter, emner og en vigtighedsscore. Output er en struktureret post i en memories‑tabel i SQLite. Det er kuraterede noter frem for rå tekst, hvilket gør efterfølgende konsolidering mere målrettet.
ConsolidateAgent kører ifølge MarkTechPost på interval — udgangspunktet er hver 30. minut — og gennemgår ukonsoliderede minder, finder koblinger og skriver synteser, nøgleindsigter og relationer tilbage i databasen. Tænk det som en planlagt vedligeholdelsescyklus. Intervallet styrer både omkostning og hvor længe støj forbliver ukorrigeret.
Forespørgsler med kildeangivelse
QueryAgent læser ifølge MarkTechPost både minder og konsoliderede indsigter for at besvare spørgsmål og returnerer svar med henvisning til de memory‑ID’er, der er anvendt. Det gør det muligt at spore udsagn og auditere eller slette på tværs af spor ved behov.
Her mærkes fravalget af et vektorlager. Uden semantisk nearest‑neighbor‑søgning kan læseomfanget vokse. Arkitekturen antager, at konsolideringen gør materialet tilpas kondenseret til, at bredere læsning er rimelig. Hvor godt det holder, afhænger af datamængden.
Hvorfor designvalget er radikalt
Fravalget af embeddings og vektordatabase flytter ansvaret: LLM’en modellerer hukommelse løbende, ikke kun ved svartid. Fordelen er færre komponenter og en enklere mental model. Ulempen er risiko for, at fejl cementeres i hukommelsen, hvis konsolidering og kvalitetssikring ikke er skarpt defineret.
Ydelse og omkostninger
Tradeoffs er tydelige. Periodisk konsolidering giver stabil, kontinuerlig modeltrafik. Budgetter bør derfor flyttes fra spidsbelastning til grundlast. Cost‑monitorering og styring af intervallet bliver styrende greb: for lavt interval øger udgifter, for højt gør hukommelsen træg og mindre præcis.
Drift, synkronisering og konsistens
Retention og indeksering bliver centrale. Hvilke felter indekseres, hvordan ryddes forældede minder, og hvornår merges poster for at undgå duplikater? Backup/restore skal være beskrevet og testet; hvis hukommelsen er en del af produktets kerne, er genopretning ikke en bagatel.
Sikkerhed, privatliv og compliance
En voksende hukommelse øger både værdi og risiko. Hvis agenten gemmer entiteter, emner og indsigter, kræves adgangsstyring, audit‑logs, kryptering i hvile og i transit samt klare retention‑politikker. GDPR betyder ret til sletning og formålsbegrænsning. Roller, scopes og logging bør defineres før pilot, og anonymisering eller pseudonymisering bør ske tidligt i IngestAgent, så PII ikke spredes ind i synteser.
Ifølge de tilgængelige kilder findes der ingen detaljeret sikkerhedsarkitektur i referenceeksemplet, hvilket efterlader et hul, som virksomheder selv må dække.
Sammenligning med etablerede patterns
AWS beskriver i et blogindlæg, at enterprise‑vidensbaser for agenter typisk kræver mange trin: connectors, parsere, vektorlager eller grafer, retrieval‑logik, observabilitet og adgangskontrol. Kompleksiteten er en del af årsagen til, at Amazon Bedrock tilbyder Managed Knowledge Base som en fuldt administreret løsning med skalering, retrieval‑nøjagtighed og dokumentadgang samlet.
Sammenlignet med Always‑On‑tilgangen er Bedrock‑modellen klassisk RAG, men driftsbyrden løftes af en managed service. Fordelen er modenhed og skalerbarhed; ulemper kan være omkostninger, lock‑in og mindre indsigt i, hvordan hukommelsen formes over tid. Ifølge MarkTechPost peger Googles eksempel på et alternativ, hvor embeddings droppes, og en billigere baggrundsmodel løbende dyrker et sæt noter, som agenten kan arbejde ud fra.
Hvornår giver Always‑On mening
Scenarier med moderat datamængde, tydelig struktur og behov for vedvarende kontekst er oplagte: interne assistenter, on‑call‑opsummeringer, sagsforløb over tid eller læringsagenter, der kobler hændelser. Ved højere throughput eller behov for semantisk søgning over store korpora kan vektorlager fortsat være det rigtige valg.
UX‑implikationer følger med. Vedvarende hukommelse ændrer forventninger til sessioner, profilniveauer og muligheden for at “glemme”. Der bør være tydelige kontroller til at rydde spor og klare forklaringer på, hvad der lagres.
Implementering: spørgsmål, der bør afklares
Før pilot: Hvad lagres præcist fra IngestAgent — og hvor længe? Hvilke felter styrer konsolidering, og hvordan evalueres kvalitet (menneske‑i‑loop, stikprøver, automatiske guardrails)? Hvilket konsolideringsinterval matcher budget og SLA, og hvilke alarmtærskler sættes for tokenforbrug?
Planlæg også migreringsvej fra SQLite, miljø‑isolation og rollback ved dårlige konsolideringer. Det sidste kræver versionering eller markering af ugyldiggjorte synteser. Test for drift over tid er nødvendig for at opdage gradvist afvigende modeladfærd.
Begrænsninger og åbne spørgsmål
Der er ingen benchmarks for latenstid, pris per time eller tokens per minut for Gemini 3.1 Flash‑Lite i Always‑On‑opsætning i de angivne kilder. Skaleringsstrategier for SQLite — fx låsning ved concurrent read/write, sharding eller replikering — er ubeskrevne. Og håndtering af akkumuleret modeldrift og hallucinationer over tid er uklar uden evalueringsmetoder og menneske‑i‑loop‑punkter.
Praktiske verifikationspunkter
Før proof‑of‑concept: Find link til det præcise repo, et referencearkitekturdiagram og modelspecifikationer for Gemini 3.1 Flash‑Lite (rate limits, pris, latency). Derudover: mål en cost‑profil for et 30‑min konsolideringsinterval under realistisk load. Ifølge de nævnte kilder mangler disse oplysninger stadig.
På sikkerhedssiden: Kryptering ved hvile og i transit, rollebaseret adgang med mindst mulige rettigheder, audit‑trails for skriv/slet samt politikker for retention og dataportabilitet. Sletning skal virke både på rå minder og konsoliderede indsigter.
Konsekvenser for arkitekturvalg
Hvis Always‑On‑mønsteret viser sig robust, kan det være et reelt alternativ til RAG i systemer med vedvarende kontekst og moderat datestørrelse. Man bytter søgeindeks og embeddings ud med struktureret lagring og løbende konsolidering. Det kan reducere kompleksitet og licensafhængighed, men kræver disciplin i kvalitetssikring og governance.
I større miljøer er en hybrid sandsynlig: embeddings og vektorlager til brede dokumentmængder; Always‑On‑hukommelse til agentens tilstand, præferencer og arbejdsnoter. Som at kombinere biblioteket med noteshæftet i baglommen.
Bundlinjen
Always‑On Memory Agent, som beskrevet af MarkTechPost, flytter hukommelse fra retrieval til en vedvarende proces med en hurtig, billig model i baggrunden og en simpel database. Der mangler stadig officiel dokumentation, benchmarks og driftsmønstre for skala. Retningen er dog tilstrækkelig interessant til at berettige et kontrolleret eksperiment.
Tre næste skridt: vælg use cases med moderat datestørrelse og klare compliance‑krav, sæt cost‑overvågning på konsolideringsintervallet fra dag ét, og etabler en revisionsmekanisme for hukommelsesændringer. Resten kræver praktisk afprøvning.
