Friday lagrer agentens hukommelse i en Neo4j-graf du hoster selv

Hver gang du åpner en ny tråd i Cursor, Claude Code eller Copilot, starter assistenten uten å vite hva dere ble enige om sist. Den vanlige løsningen er å skrive det ned i en AGENTS.md eller et sett med promptmaler, og la agenten lese hele fila på nytt ved hvert spørsmål. Det koster tokens på hver eneste forespørsel. Og de små avgjørelsene underveis, den valgte avhengighetsversjonen, en justering i skjemaet, begrunnelsen bak en feilretting, forsvinner uansett når økta nullstilles.

Friday angriper det med en selvhostet MCP-server i stedet for et dokument. Serveren eksponerer fire verktøy over stdio: add_memory, add_fact, memory_search og get_context. Bak dem ligger tre lag. Mem0 tar seg av det semantiske minnet på tvers av økter, ChromaDB henter ut bare de bitene som er relevante for spørsmålet, og Neo4j bygger en kunnskapsgraf der entiteter og relasjoner trekkes ut i bakgrunnen for hver nye hukommelse. En innebygd nettvisning kalt Neural Studio lar deg inspisere og spørre grafen mens den vokser, med filtre og full redigering.

Oppsettet er Docker Compose, og prosjektet oppgir Python 3.11 eller nyere, FastAPI 0.115 og Neo4j 5.15. Lisensen er MIT, og alt kjører på egen maskin. Det er hele poenget for den som ikke vil sende arkitekturbeslutninger til en skytjeneste bare for å slippe å gjenta dem.

Vær tålmodig med modenheten. Repoet ble lagt ut på GitHub 16. september 2026, og påstanden om 90 prosent færre tokens gjennom målrettet henting står i README uten en målemetode bak seg. Grafen bygges dessuten av en språkmodell som trekker ut entiteter fra hver hukommelse, så kvaliteten på minnet avhenger av modellen du peker den mot. Feil uttrekk i bunnen blir feil kontekst i toppen.

Hva bør du gjøre?

1. Kjør det mot ett prosjekt først, ikke hele maskinen. get_context er lett å teste: legg inn tre beslutninger manuelt og se hva agenten faktisk får tilbake.
2. Mål tokenbruken din selv før og etter. Tallet i README er ikke etterprøvd, og din egen måling er den eneste som gjelder for din kodebase.
3. Sjekk hvilken modell som gjør entitetsuttrekket før du lar grafen vokse seg stor. Det er billigere å bytte den nå enn å rydde i grafen senere.