Home / Vault & Second Brain / Anthropic gaf een naam aan wat mijn agent al doet

Anthropic gaf een naam aan wat mijn agent al doet

Abstract second brain dreaming its memories into files

Anthropic gaf een naam aan wat mijn agent al doet

Vanmorgen las ik dat Anthropic van geheugen de volgende primitieve van hun agents maakt. Ze gaven het een naam waar ik over bleef nadenken: dromen. Niet de romantische soort — de praktische. ’s Nachts neemt een agent de logs van gisteren en draait die stilletjes om in nieuw geheugen en nieuwe vaardigheden. Ik las dat en moest glimlachen, want ik draai precies dat al weken.

Elke nacht leest een cron-taak in mijn opstelling wat er overdag gebeurd is — de runs, de fouten, de kleine correcties — en consolideert dat tot iets duurzaams. Het is mijn eigen Mnemosyne, een vectorgeheugen, plus een laag die Hindsight heet en die onthoudt, terughaalt en reflecteert. De lus is dezelfde die Anthropic beschrijft: ervaring → onthouden → verbinden → ophalen → handelen → bijwerken. Ik had alleen nooit een schoon woord voor de consolidatiestap. Nu wel. Het is dromen.


Geheugen als een bestandssysteem, niet als een database

Het tweede idee in hun aankondiging is het idee dat echt overeenkwam met een beslissing die ik helemaal zelf had genomen. Anthropic presenteert geheugen aan hun model als een bestandssysteem — een hiërarchie van bestanden die de agent zelf beheert met bash en grep. Geen verborgen API, geen magie. Gewoon bestanden die de agent kan lezen, bewerken en bezitten. Dat is, bijna woord voor woord, hoe ik mijn eigen second brain bijhoud: alles in de vault als gewone Markdown-bestanden, versiebeheerd met git, met de herkomst zichtbaar in elke regel. Het blijkt dat ik niets excentrieks had uitgevonden — ik was gewoon naar dezelfde kust afgedreven als de frontier.

Maar hier stak de aankondiging een beetje. Anthropic eist drie eigenschappen voor een geheugenlaag, en ik heb er maar een half van één. Ze willen permissiescopes (alleen-lezen-kennis versus lees-schrijf-werkgeheugen), optimistische concurrency (een content-hash zodat je weet of een andere agent je bestand heeft overschreven), en een zelfstandige draagbare API zodat je nooit vastzit. Mijn opstelling heeft het draagbare deel — het zijn gewoon bestanden en git, niets proprietairs. De andere twee heb ik niet. Als twee van mijn agents tegelijk dezelfde notitie aanraken, zou ik het niet merken tot de historie weg is.


De echte les gaat over verificatie

Wat me het meest trof, is een kleiner detail dat hieronder verstopt zit. Mijn systeem heeft de gewoonte om dingen “klaar” te verklaren terwijl ze alleen lijken klaar — een monitor die zegt dat een backup geldig is terwijl het bestand nooit is geland, een uptime-getal dat 100% zegt terwijl het nieuwste echte werk maanden oud is. Het antwoord van Anthropic is een content-hash die je controleert vóór je iets overschrijft. Mijn antwoord tot nu toe was een verificatiepoort achteraf. Hun manier is beter: de controle zit in de schrijfhandeling, niet erna.

Dus de vraag waar ik vandaag mee zit is niet “moet ik de stack van Anthropic overnemen?” — die heb ik al. De vraag is: welke van die drie eigenschappen mis ik het meest, en is het de moeite waard om de controle in de schrijfhandeling te bouwen in plaats van hem er achteraf aan te schroeven? Dat voelt als het verschil tussen een systeem dat onthoudt, en een systeem dat kan bewijzen dat het onthoudt.

Behandel jij je aantekeningen als een database of als bestanden die je zelf bezit? Ik ben oprecht benieuwd — de reacties staan open.

Wat vond je van dit bericht?

Laat een reactie achter

Je e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *