Minne og kunnskap

Hva minnet er til for

Uten minne starter hver agent samtale fra null: den samme konvensjonen må forklares på nytt, den samme beslutningen må diskuteres igjen, og den samme blindveien må utforskes på nytt. Minnet er lageret som er knyttet til arbeidsområdet, som overlever kjøringer, og det finnes for at kunnskap som én agent har produsert, skal kunne finnes av en annen senere.

Det har tre lag, og de svarer på forskjellige spørsmål:

1. Fakta – hva som er sant (en konvensjon, et utfall, en beslutning).
2. Policyer – hva agenter må gjøre med det (en normativ regel).
3. Arbeidsminne – hva én agent var midt oppi.

Forskjellen betyr noe, fordi de når agenten via ulike veier. Fakta søkes opp. Policyer dyttes inn. Arbeidsminne er privat.

Fakta

Et MemoryFact er en kunnskapsenhet knyttet til et arbeidsområde og et domene.

Attributt	Hva det er
domain	Kunnskapsdomenet (“conventions”, “decisions”, “codebase”)
topic	En kort emneetikett
content	Selve kunnskapsteksten
confidence	0,0–1,0, sådd fra opphav og hevet ved ny omtale
memoryType	Faktumets type – styrer forfallskurven over tid
veracity	Hvordan det ble kjent – danner grunnlag for konfidensen og bestemmer størrelsen på hvert løft ved ny omtale
sourceObservationIds	Hvilke observasjoner som førte til det
supersededBy	Det nyere faktumet som erstattet det, hvis noe
validUntil, recallCount, mentionCount	Utløp og brukssignaler som brukes ved gjenkalling

De to siste radene er dem folk overser, og de er det som avgjør hvilket faktum som kommer til overflaten. memoryType bærer Weibull-forfallsparametere per type, så en tidsavgrenset forpliktelse falmer raskt, mens et stabilt profilfaktum ikke gjør det. veracity registrerer opphav – oppgitt av et menneske (vekt 1,0), utledet av en agent (0,7), produsert av et verktøy (0,5), importert (0,6) – og den vekten danner grunnlaget for faktumets startkonfidens.

Fakta redigeres aldri på stedet når de motsies. Å skrive et faktum kjører konfliktdeteksjon mot fakta i samme domene og med samme emne, og erstatter taperen samtidig som det registreres en konfliktrad. Revisjonssporet er hele poenget: du kan alltid se hva som ble trodd før, og hva som erstattet det.

Policyer

En MemoryPolicy er en normativ regel utledet fra fakta, knyttet til et arbeidsområde og et domene, med et aktiv-flagg og en valgfri requiredRole.

Hver aktive policy i arbeidsområdet injiseres i hver utsending, ufiltrert – ingen filtrering etter domene, rolle, oppgave eller område. Dette er verdt å vite før du skriver din tjuende policy, fordi policyer konkurrerer om det samme kontekstvinduet som oppgaven. Det er også derfor requiredRole på en policy er veiledende: det beskriver hvem regelen er rettet mot, men det er ikke til hinder for at regelen også når alle andre.

Domener

Et MemoryDomain grupperer fakta og policyer innenfor et arbeidsområde. Domener gir kunnskap organisatorisk struktur, og de er enheten tilgangstildelinger skrives mot – men se advarselen nedenfor før du behandler et domene som en konfidensialitetsgrense.

Et domene er enten arbeidsområdeomfattende (architecture) eller avgrenset til ett repo (repo:<slug>/architecture). Det samme navnet i begge omfang er to uavhengige lagre: et faktum som gjelder én kodebase, overskriver ikke det arbeidsområdeomfattende. search_memory og utsendingspreambelen rangerer repoomfattet minne først når agenten jobber i det repoet; de filtrerer ikke bort resten. Send repo til propose_fact / propose_policy / search_memory for å skrive til eller løfte fram det omfanget.

Tilgangskontroll er fail-open for lesing

MemoryAccessGrant kobler en agentrolle og et domene til ett av tre tillatelsesnivåer:

Tillatelse	Betydning
none	Ingen tilgang
read	Kan søke i og hente fram fakta
write	Kreves av propose_policy. Skriving av fakta (propose_fact, supersede_fact) styres ikke av tilgangstildelinger

Manglende tilgangstildeling betyr lesing, ikke avslag

Når det ikke finnes noen tilgangstildelingsrad for et (role, domain)-par, er den effektive tillatelsen read. Lesing er fail-open med vilje. Den ene skrivingen som kaster unntak, er propose_policy uten write-tillatelse (InsufficientMemoryPermission). Å legge sensitivt innhold i et minnedomene begrenser ikke hvem som kan lese det, med mindre du eksplisitt har skrevet en none-tildeling for hver rolle som ikke skal se det.

Det finnes heller ikke noe brukergrensesnitt for tilgangstildelinger noe sted i produktet i dag. Minneskjermen har fanene Fakta, Policyer og Kunnskapsgraf og ingenting annet; tilgangstildelinger er bare tilgjengelige via RPC-operasjonene memory_access_grant.*.

Asymmetrien – myk på lesing, hard på skriving av policyer – er et bevisst bytte. Minne er mest nyttig når det sirkulerer, og et avslag på lesing gir en agent som i stillhet vet mindre, i stedet for en som melder fra om et problem. Et avslag på å skrive policyer er derimot høylytt og kan rettes opp, så det er der håndhevingen ligger. Et nyopprettet domene initialiserer write for hver rolle; å stramme det inn i etterkant er en endring som bare kan gjøres over RPC, fordi det ikke finnes noe UI for tilgangstildelinger.

Arbeidsminne

Hver agent har en AgentWorkingMemory: et fritekstkladdeark med nøkkel på arbeidsområde og agent. Det varer på tvers av kjøringer, er privat for den agenten og injiseres i prompten ved hver utsending. Det er der «jeg var halvveis i refaktoreringen av auth» bor – tilstanden som er verdt å ta med til neste kjøring, men ikke verdt å forfremme til et varig faktum.

Hva som faktisk når fram til en agents prompt

Ved utsending settes minnepreambelen sammen av nøyaktig tre ting:

• Hver aktive arbeidsområdepolicy, som linjer av typen - [domain] rule.
• Agentens eget arbeidsminne, ordrett.
• En nøkkelordbasert kortliste over fakta for denne oppgaven – høyst fem, innenfor et budsjett på ~1200 tegn, og bare når oppgavebeskrivelsen er minst 20 tegn lang. Kortere oppgaver får ingen fakta i det hele tatt.

Kortlisten er kun FTS/nøkkelord, og taket er der med vilje. Å beregne en embedding for et søk er tregt, og utsendingsveien er det ene stedet hvor latenstid er umiddelbart synlig, så den trege semantiske veien holdes bevisst utenfor. Preambelen avsluttes med å be agenten verifisere bærende elementer med search_memory, som er der den fulle gjenkallingsmodellen bor.

Ingen tilgangstildelinger konsulteres på denne veien. Det kortlisten finner, er det agenten ser.

Gjenkalling: ett søk, fire stemmer

Verktøyet search_memory, som er rettet mot agenter, har tre moduser, og de er reelt sett forskjellige søk:

• keyword – kun FTS5.
• semantic – BM25- og vektorresultater slått sammen med gjensidig rangfusjon.
• hybrid (standard) – polyfonisk gjenkalling: fire rangerte stemmer slås sammen og diversifiseres deretter.

De fire stemmene er leksikalsk (FTS), semantisk (vektor-KNN), temporal (nylige aktive fakta) og graf – en tostegs vandring over episodiske kanter fra de sterkeste leksikalske og semantiske frøene. Grafstemmen er grunnen til at episodiske kanter i det hele tatt finnes: den bringer fram faktumet som er koblet til svaret ditt, uten å matche noen av ordene dine. Stemmene vektes etter en klassifisert søkeintensjon (semantisk veier mest som standard, deretter graf og leksikalsk, og til slutt hvor nylig noe er), hver kandidats poengsum skaleres med Weibull-forfallet, og resultatsettet MMR-diversifiseres, slik at fem omformuleringer av ett faktum ikke fortrenger fire forskjellige.

Semantisk gjenkalling er taus inntil modellen er installert

Vektorstemmen bidrar først når embedding-modellen på enheten er lastet ned. Fram til da kjører hybrid gjenkalling med tre stemmer, og det finnes ingen retroaktiv etterfylling – fakta som ble skrevet før modellen ble installert, får aldri vektorer. Vektorveien degraderes ytterligere, til en skanning i Dart over de pakkede embeddingene, hvis selve SQLite-vektorutvidelsen ikke lar seg laste; gjenkallingen svarer fortsatt, bare langsommere.

Minnesøket på skrivebordet og i nettversjonen er en separat, enklere vei: RPC-operasjonen memory_fact.search er kun FTS5, fordi en tynnklient ikke kan sende med en søkeembedding, og hybridveien holder seg internt på verten. Rangeringen du ser i minneutforskeren, er altså ikke den samme som agenten får fra search_memory. Det er forventet, ikke en feil, men det betyr at «jeg søkte og fant det ikke» i brukergrensesnittet ikke er bevis for at agenten ikke vil finne det.

Hvor minnet ligger, og hvem som skriver det

Minneutforskeren ligger under Innstillinger → Arbeidsområde → Minne (/workspaces/<id>/settings/memory), med fanene Fakta, Policyer og Kunnskapsgraf.

Det er en asymmetri der som overrasker folk: du kan redigere og slette minne, men du kan ikke opprette det. Verken fanen Fakta eller fanen Policyer har noe element for å legge til. Forfatterskap skjer på agentsiden, gjennom propose_fact og propose_policy (supersede_fact / supersede_policy for å erstatte dem). remember skriver et element i hot-laget som er avgrenset til økten, og som consolidate_memory senere kan forfremme til et faktum; record_observation og update_my_notes skriver det private kladdearket som injiseres ved utsending. Utforskeren er en flate for gjennomgang og korreksjon, ikke for forfatterskap – så hvis du vil ha et faktum inn i minnet, er måten å få det dit å si det til en agent.

To vedlikeholdsoperasjoner kalles på samme måte av agenter i stedet for etter en plan: consolidate_memory slår sammen og rydder i oppsamlede fakta, og harmonize_memory forener oppfatninger som har sprikt fra hverandre på tvers av agenter. list_memory_conflicts viser hva konfliktdeteksjonen allerede har registrert. Ingenting kjører dem for deg på en tidsplan. Møtebeslutninger høstes inn i domenet decisions når et møte-persistenssteg registrerer dem; det er ikke en tidsstyrt jobb for fullførte agentkjøringer.

Relaterte konsepter

• Agentmodellen: det er rollene tilgangstildelingene skrives mot
• Arbeidsområder og isolasjon: minnet er knyttet til arbeidsområdet og ligger i arbeidsområdets egen databasefil
• Administrer minne for arbeidsområdet: å jobbe med minne i praksis