Senior AI-productmanager van Google Shubham Saboo heeft een van de moeilijkste problemen bij het ontwerpen van agenten omgezet in een open source-engineeringoefening: persistent geheugen.
Deze week bracht hij een open source uit “Always On Memory Agent” op het officiële Google Cloud Platform Github pagina onder een tolerante MIT-licentie die commercieel gebruik toestaat.
Het is gebouwd met De Agent Development Kit of ADK van Google afgelopen voorjaar in 2025 geïntroduceerd, en Gemini 3.1 Flash-Lite, een goedkoop model dat Google op 3 maart 2026 introduceerde als het snelste en meest kosteneffectieve model in de Gemini 3-serie.
Het project dient als een praktische referentie-implementatie voor iets dat veel AI-teams willen, maar slechts weinigen netjes hebben geproduceerd: een agentsysteem dat voortdurend informatie kan opnemen, op de achtergrond kan consolideren en later kan ophalen zonder afhankelijk te zijn van een conventionele vectordatabase.
Voor zakelijke ontwikkelaars betekent de release niet zozeer een productlancering als wel een signaal van waar de agentinfrastructuur naartoe gaat.
Het repo biedt een visie op autonomie op lange termijn die steeds aantrekkelijker wordt voor ondersteunende systemen, onderzoeksassistenten, interne co-piloten en workflowautomatisering. Het brengt ook managementkwesties scherper in beeld zodra het geheugen niet langer sessiegebonden is.
Wat de repository lijkt te doen – en wat deze niet duidelijk beweert
De repository lijkt ook een interne architectuur met meerdere agenten te gebruiken, met gespecialiseerde componenten die de opname, consolidatie en query’s afhandelen.
Maar de verstrekte materialen onderbouwen niet duidelijk een bredere bewering dat dit een gedeeld geheugenraamwerk is voor meerdere onafhankelijke agenten.
Dat onderscheid is van belang. ADK ondersteunt als raamwerk multi-agentsystemen, maar deze specifieke repository kan het best worden omschreven als een altijd actieve geheugenagent of geheugenlaag, gebouwd met gespecialiseerde onderagenten en permanente opslag.
Zelfs op dit beperktere niveau lost het een kerninfrastructuurprobleem op waar veel teams actief aan werken.
De architectuur geeft de voorkeur aan eenvoud boven een traditionele ophaalstapel
Volgens de repository is de agent continu actief, neemt hij bestanden of API-invoer op, slaat hij gestructureerde herinneringen op in SQLite en voert hij standaard elke 30 minuten een geplande geheugenconsolidatie uit.
Een lokale HTTP API en een Streamlit-dashboard zijn inbegrepen, en het systeem ondersteunt de opname van tekst, afbeeldingen, audio, video en PDF. De repo omlijst het ontwerp met een opzettelijk provocerende claim: “Geen vectordatabase. Geen inbedding. Gewoon een LLM die gestructureerd geheugen leest, denkt en schrijft.”
Deze ontwerpkeuze zal waarschijnlijk de aandacht trekken van ontwikkelaars die de kosten en operationele complexiteit beheersen. Traditionele ophaalstacks vereisen vaak afzonderlijke inbeddingspijplijnen, vectoropslag, indexeringslogica en synchronisatiewerk.
Het voorbeeld van Saboo leunt in plaats daarvan op het model van het rechtstreeks organiseren en bijwerken van het geheugen. In de praktijk kan het het maken van prototypen vereenvoudigen en de wildgroei van de infrastructuur verminderen, vooral voor agenten met een klein of middelgroot geheugen. Het verschuift ook het prestatieprobleem van overhead voor vectorzoekopdrachten naar latentie van modellen, logica voor geheugencompressie en gedragsstabiliteit op de lange termijn.
Flash-Lite geeft het Always-On-model een bepaalde economische logica
Dit is waar Gemini 3.1 Flash-Lite in het verhaal komt.
Google zegt dat het model is gebouwd voor grootschalige workloads van ontwikkelaars en een prijs heeft van $0,25 per 1 miljoen inputtokens en $1,50 per 1 miljoen outputtokens.
Het bedrijf zegt ook dat Flash-Lite 2,5 keer sneller is dan Gemini 2.5 Flash in de tijd tot de eerste token en een toename van 45% in de uitvoersnelheid oplevert met behoud van een vergelijkbare of betere kwaliteit.
Op de door Google gepubliceerde benchmarks scoort het model een Elo-score van 1432 op Arena.ai, 86,9% op GPQA Diamond en 76,8% op MMMU Pro. Google positioneert deze eigenschappen als geschikt voor hoogfrequente taken zoals vertaling, moderatie, UI-generatie en simulatie.
Deze cijfers helpen verklaren waarom Flash-Lite is gekoppeld aan een achtergrondgeheugenagent. Een 24/7 service die periodiek geheugen herlaadt, consolideert en onderhoudt, heeft een voorspelbare latentie en voldoende lage beëindigingsoverhead nodig om te voorkomen dat “altijd aan” onbetaalbaar wordt.
De ADK-documentatie van Google versterkt het bredere verhaal. Het raamwerk wordt gepresenteerd als model- en implementatie-agnostisch met ondersteuning voor workflow-agents, multi-agent-systemen, tools, evaluatie- en implementatiedoelen, waaronder Cloud Run en Vertex AI Agent Engine. Door deze combinatie voelt de geheugenagent zich minder als een eenmalige demo en meer als een referentiepunt voor een bredere agent-runtimestrategie.
Het debat in het bedrijfsleven gaat over leiderschap, niet alleen over capaciteit
Publieke reacties laten zien waarom de adoptie van persistent geheugen door het bedrijf niet alleen afhankelijk is van snelheid of tokenprijzen.
Verschillende reacties op X hebben precies de zorgen benadrukt die ondernemingsarchitecten waarschijnlijk zullen uiten. Frank Abe noemde Google ADK en 24/7 geheugenconsolidatie “briljante sprongen voor continue autonomie van agenten”, maar waarschuwde dat een agent die “droomt” en herinneringen op de achtergrond kruisbestuift zonder deterministische grenzen “een compliance-nachtmerrie” wordt.
LED maakte een gerelateerd punt, met het argument dat de belangrijkste kosten van permanente agenten niet uit tokens bestaan, maar uit ‘operaties en lussen’.
Deze kritiek heeft rechtstreeks betrekking op de operationele last van persistente systemen: wie kan geheugen schrijven, wat wordt samengevoegd, hoe werkt retentie wanneer herinneringen worden gewist, en hoe controleren teams wat de agent in de loop van de tijd heeft geleerd?
Nog een reactie, van Twijfelbetwistte de “no embeds”-framing van de repository, met het argument dat het systeem nog steeds gestructureerd geheugen moet segmenteren, indexeren en ophalen, en dat het goed kan werken voor kleine contextagenten, maar kapot gaat wanneer de geheugenopslag veel groter wordt.
Die kritiek is technisch belangrijk. Als u een vectordatabase verwijdert, worden de ophaalontwerpen niet verwijderd; het verandert waar de complexiteit zich bevindt.
Voor ontwikkelaars gaat de afweging minder over ideologie dan over fitheid. Een lichtere stack kan aantrekkelijk zijn voor goedkope agents met een beperkt geheugen, terwijl grotere implementaties mogelijk nog steeds strengere ophaalcontroles, explicietere indexeringsstrategieën en sterkere levenscyclustools vereisen.
ADK breidt het verhaal verder uit dan een enkele demo
Andere commentatoren concentreerden zich op de workflow van de ontwikkelaar. Eén vroeg om de ADK-opslagplaats en -documentatie en wilde weten of de runtime serverloos of langlopend is, en of toolaanroepen en evaluatiehooks kant-en-klaar beschikbaar zijn.
Op basis van het verstrekte materiaal is het antwoord feitelijk beide: het voorbeeld van de geheugenagent zelf is gestructureerd als een langlopende service, terwijl de ADK breder meerdere implementatiepatronen ondersteunt en tools en evaluatiemogelijkheden omvat.
De altijd-aan-geheugenagent is op zichzelf interessant, maar de grotere boodschap is dat Saboo probeert agenten het gevoel te geven dat ze inzetbare softwaresystemen zijn in plaats van geïsoleerde aanwijzingen. In dat raamwerk wordt geheugen onderdeel van de runtime-laag, en niet alleen maar een add-on-functie.
Wat Saboo heeft laten zien – en wat hij niet heeft laten zien
Wat Saboo nog moet laten zien, is net zo belangrijk als wat hij heeft uitgebracht.
De geleverde materialen bevatten geen directe Flash-Lite versus antropische Claude Haiku-benchmark voor agentloops in productiegebruik.
Ze stellen ook geen nalevingscontroles op bedrijfsniveau vast die specifiek zijn voor deze geheugenagent, zoals: deterministische beleidslimieten, retentiegaranties, scheidingsregels of formele auditworkflows.
En hoewel de repository intern meerdere gespecialiseerde agenten lijkt te gebruiken, bewijzen de materialen niet duidelijk een grotere claim van een persistent geheugen dat wordt gedeeld door meerdere onafhankelijke agenten.
Tot nu toe klinkt de repository eerder als een aantrekkelijk technisch sjabloon dan als een volledig bedrijfsgeheugenplatform.
Waarom dit nu belangrijk is
Toch komt de release op het juiste moment. Enterprise AI-teams gaan verder dan single-turn-assistenten en gaan over op systemen waarvan wordt verwacht dat ze voorkeuren onthouden, de projectcontext behouden en over een langere horizon opereren.
Saboo’s open source geheugenagent biedt een concreet startpunt voor de volgende infrastructuurlaag, en Flash-Lite verleent enige geloofwaardigheid aan de economie.
Maar de sterkste conclusie uit de reactie rond de lancering is dat het continue geheugen zowel op controle als op capaciteit zal worden beoordeeld.
Dat is de echte zakelijke vraag achter de demo van Saboo: niet of een agent zich kan herinneren, maar of hij zich kan herinneren op een manier die beperkt, inspecteerbaar en veilig genoeg blijft om tijdens de productie te worden vertrouwd.
