Senior AI-productmanager van Google Shubham Saboo heeft een van de lastigste problemen bij het ontwerpen van agenten omgezet in een open-source engineeringoefening: persistent geheugen.
Deze week publiceerde hij een open-source “Always On Memory Agent” op het officiële Google Cloud Platform Github pagina onder een toegestane MIT-licentie, die commercieel gebruik mogelijk maakt.
Het is gebouwd met De Agent Development Kit van Google, oftewel ADK 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 kostenefficiënte model uit 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 is de release minder belangrijk als productlancering dan als signaal over waar de agentinfrastructuur naartoe gaat.
Het repo biedt een visie op langdurige autonomie die steeds aantrekkelijker wordt voor ondersteunende systemen, onderzoeksassistenten, interne copiloten en workflowautomatisering. Het brengt ook bestuursvragen scherper in beeld zodra het geheugen niet langer sessiegebonden is.
Wat de repo lijkt te doen – en wat het 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 aangeleverde 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 systemen met meerdere agenten, maar deze specifieke repository kan het best worden omschreven als een altijd ingeschakelde geheugenagent of geheugenlaag, gebouwd met gespecialiseerde subagenten en permanente opslag.
Zelfs op dit beperktere niveau wordt een kernprobleem van de infrastructuur aangepakt 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.”
Die ontwerpkeuze zal waarschijnlijk de aandacht trekken van ontwikkelaars die de kosten en operationele complexiteit beheren. Traditionele ophaalstacks vereisen vaak afzonderlijke inbeddingspijplijnen, vectoropslag, indexeringslogica en synchronisatiewerk.
Het voorbeeld van Saboo leunt in plaats daarvan op het model om het geheugen rechtstreeks te organiseren en bij te werken. In de praktijk kan dit prototypes vereenvoudigen en de wildgroei van de infrastructuur verminderen, vooral voor kleinere agenten of agenten met een middelgroot geheugen. Het verschuift ook de prestatievraag van overhead voor vectorzoekopdrachten naar latentie van modellen, logica voor geheugenverdichting en gedragsstabiliteit op de lange termijn.
Flash-Lite geeft het Always-On-model een zekere economische logica
Dat is waar Gemini 3.1 Flash-Lite het verhaal binnenkomt.
Google zegt dat het model is gebouwd voor grootschalige ontwikkelaarsworkloads 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 plaatst het model een Elo-score van 1432 op Arena.ai, 86,9% op GPQA Diamond en 76,8% op MMMU Pro. Google positioneert deze kenmerken als geschikt voor hoogfrequente taken zoals vertaling, moderatie, UI-generatie en simulatie.
Deze cijfers helpen verklaren waarom Flash-Lite wordt gecombineerd met een achtergrondgeheugenagent. Een 24/7 service die periodiek geheugen opnieuw leest, consolideert en bedient, heeft een voorspelbare latentie en voldoende lage inferentiekosten nodig om te voorkomen dat ‘altijd aan’ onbetaalbaar wordt.
De ADK-documentatie van Google versterkt het bredere verhaal. Het raamwerk wordt gepresenteerd als model-agnostisch en implementatie-agnostisch, met ondersteuning voor workflow-agents, multi-agent-systemen, tools, evaluatie- en implementatiedoelen, waaronder Cloud Run en Vertex AI Agent Engine. Door die combinatie voelt de geheugenagent zich minder als een eenmalige demo en meer als een referentiepunt voor een bredere agent-runtimestrategie.
Het ondernemingsdebat gaat over governance, niet alleen over capaciteiten
Publieke reacties laten zien waarom de adoptie van persistent geheugen door bedrijven niet alleen afhangt van snelheid of tokenprijzen.
Verschillende reacties op X hebben precies de zorgen benadrukt die ondernemingsarchitecten waarschijnlijk zullen uiten. Franck 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’.
ELED maakte een gerelateerd punt, met het argument dat de belangrijkste kosten van permanente agenten niet uit tokens bestaan, maar uit ‘drift en loops’.
Deze kritiek heeft rechtstreeks betrekking op de operationele last van persistente systemen: wie kan geheugen schrijven, wat wordt samengevoegd, hoe retentie werkt, wanneer herinneringen worden verwijderd en hoe teams controleren wat de agent in de loop van de tijd heeft geleerd?
Nog een reactie, van Twijfeldaagde de ‘no embeddings’-framing van de repo uit, met het argument dat het systeem nog steeds gestructureerd geheugen moet segmenteren, indexeren en ophalen, en dat het misschien goed werkt voor agenten met een kleine context, maar kapot gaat zodra de geheugenopslag veel groter wordt.
Die kritiek is technisch belangrijk. Als u een vectordatabase verwijdert, wordt het ophaalontwerp niet verwijderd; het verandert waar de complexiteit leeft.
Voor ontwikkelaars heeft de afweging minder te maken met ideologie dan met fitheid. Een lichtere stack kan aantrekkelijk zijn voor goedkope agents met beperkt geheugen, terwijl implementaties op grotere schaal 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 ontwikkelaars. Eén vroeg om de ADK-repository en -documentatie en wilde weten of de runtime serverloos of langlopend is, en of tool-calling en evaluatie-hooks kant-en-klaar beschikbaar zijn.
Op basis van de geleverde materialen is het antwoord feitelijk beide: het voorbeeld van de geheugenagent zelf is gestructureerd als een langlopende service, terwijl ADK breder meerdere implementatiepatronen ondersteunt en tools en evaluatiemogelijkheden bevat.
De ‘altijd aan’-geheugenagent is op zichzelf al 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 kader 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 niet heeft laten zien, is net zo belangrijk als wat hij heeft gepubliceerd.
De geleverde materialen bevatten geen directe Flash-Lite versus Anthropic Claude Haiku-benchmark voor agentloops in productiegebruik.
Ze voorzien ook niet in nalevingscontroles op bedrijfsniveau die specifiek zijn voor deze geheugenagent, zoals: deterministische beleidsgrenzen, retentiegaranties, scheidingsregels of formele auditworkflows.
En hoewel de repository intern meerdere gespecialiseerde agenten lijkt te gebruiken, bewijzen de materialen niet duidelijk een grotere claim over persistent geheugen dat wordt gedeeld door meerdere onafhankelijke agenten.
Voorlopig leest de repository eerder als een aantrekkelijk technisch sjabloon dan als een compleet 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 die volgende infrastructuurlaag, en Flash-Lite geeft de economie enige geloofwaardigheid.
Maar de sterkste conclusie uit de reactie rond de lancering is dat het continue geheugen evenzeer op bestuurlijk vlak als op bekwaamheid zal worden beoordeeld.
Dat is de echte ondernemingsvraag achter Saboo’s demo: niet of een agent zich kan herinneren, maar of hij zich kan herinneren op een manier die begrensd, inspecteerbaar en veilig genoeg blijft om te vertrouwen in de productie.
