de huidige discussie over "filesystem vs database" voor agentgeheugen aan het verteren: momenteel zie ik 2 kampen in hoe we agentgeheugen bouwen. aan de ene kant hebben we het kamp "bestandinterfaces zijn alles wat je nodig hebt". aan de andere kant hebben we het kamp "bestanden zijn gewoon slechte databases". "bestandinterfaces zijn alles wat je nodig hebt" kamp leiders zoals anthropic, letta, langchain & llamaindex neigen naar bestandinterfaces omdat "bestanden verrassend effectief zijn als agentgeheugen". • de geheugentool van anthropic behandelt geheugen als een set bestanden (de opslagimplementatie is aan de ontwikkelaar overgelaten) • de agentbouwer van langsmith vertegenwoordigt ook geheugen als een set bestanden (de gegevens worden opgeslagen in een DB en bestanden worden aan de agent blootgesteld als een bestandssysteem) • letta dat eenvoudige bestandssysteemtools zoals grep en ls beter presteerden dan gespecialiseerde geheugen- of ophaaltools in hun benchmarks • llamaindex stelt dat voor veel gebruikssituaties een goed georganiseerd bestandssysteem met semantische zoekopdrachten alles is wat je nodig hebt agents zijn goed in het gebruik van bestandssystemen omdat modellen zijn geoptimaliseerd voor coderingstaken (inclusief CLI-operaties) na de training. dat is waarom we een "virtueel bestandssysteem" patroon zien waarbij de agentinterface en de opslagimplementatie van elkaar zijn ontkoppeld. "bestanden zijn gewoon slechte databases" kamp maar dan heb je stemmen zoals dax van opencode die terecht opmerkt dat "een bestandssysteem gewoon de slechtste soort database is". swyx en collega's in de database-ruimte waarschuwen voor het per ongeluk opnieuw uitvinden van db's door het probleem van agentgeheugen op te lossen. Vermijd het schrijven van slechtere versies van: • zoekindexen, • transactie-logboeken, • vergrendelmechanismen, afwegingen...