Hjernen til agentene mine er et Git-repo

Dette får du med deg: Du får de sju reglene og den enkle strukturen i kunnskapshvelvet som gjør at jeg kan holde agentenes kunnskap lesbar, versjonerbar og uavhengig av verktøy.

For meg trenger ikke en KI-agent noen mystisk hukommelse. Den trenger filer jeg kan lese, kontrollere og bruke på nytt.

Derfor ligger hjernen til agentene mine i et privat Git-repositorium. Markdown er sannhetskilden der. Git dokumenterer når noe er endret. Obsidian gir meg et praktisk grensesnitt for søk, lenker og oversikt, men er ingen forutsetning for å få tilgang til innholdet.

Hvis Obsidian ikke er tilgjengelig, åpner jeg filene i tekstredigereren. Hvis et agentverktøy forsvinner, peker adapteren til samme mappe. Hvis en ekstra hukommelsesmotor kommer til, kan den indeksere innholdet, men ikke erstatte det.

Det høres enkelt ut. For at det ikke igjen skal bli en uoversiktlig samling filer i det daglige, gjelder sju ufravikelige regler.

Regel 1: Markdown er sannhetskilden

Personaer, arbeidsregler og kuratert kunnskap ligger i Markdown-filer. Semantisk søk, en vektorindeks eller en hukommelsesmotor kan gjøre det raskere å få tilgang til dette innholdet. Men den avledede versjonen er aldri den eneste som finnes.

Dette beskytter ikke bare mot å bli bundet til et verktøy. Det gjør også rettelser etterprøvbare. I en diff kan jeg se hvilken setning som er endret, i stedet for å stole på at en usynlig hukommelsesprosess har lagret det riktige.

Regel 2: En persona har nøyaktig én hjerne

Den samme agenten skal ikke få en litt annerledes versjon av identiteten sin i hvert verktøy. Claude, Codex, Gemini og Hermes skal ha tilgang til de samme autoritative filene.

Ellers begynner personaene å avvike fra hverandre: I ett verktøy gjelder en ny godkjenningsregel, mens den gamle fortsatt gjelder i et annet. Eller en rettelse havner bare i én systemprompt og går tapt neste gang agenten bytter kropp.

Én kilde hindrer slike stille forgreninger.

Tillegg: Listen over verktøy har vokst. Repositoriet dokumenterer nå seks adapterfamilier: I tillegg til Claude Code, Codex, Gemini og Hermes har Kimi Code og Grok Build kommet til. Det endrer ikke regelen. Begge de nye kroppene er koblet direkte til de samme autoritative filene, uten egne kopier.

Regel 3: Adaptere skal være tynne

Et «harness» er verktøyet en agent arbeider i. Hvert system trenger derfor en passende forbindelse: en konfigurasjonsfil, en prosjektbeskrivelse eller en systemprompt.

Disse adapterne skal bare gjøre tre ting: finne riktig agentmappe, angi leserekkefølgen og kreve tilbakeskriving til hukommelsen. Persona, fagkunnskap og styringsregler kopieres ikke inn i adapteren.

Jo tynnere forbindelsen er, desto enklere er den å bytte ut.

Regel 4: Felles kunnskap henvises til

Flere agenter trenger samme merkevarestemme, de samme typografireglene eller de samme sikkerhetskonvensjonene. Slikt innhold ligger i et felles område og lastes derfra.

Jeg kopierer det ikke inn i hver agentmappe. En rettelse i den felles kilden skal nå alle berørte roller. Kopier ville begynt å avvike fra hverandre allerede etter den første endringen.

Denne regelen er lite spektakulær. Nettopp derfor er den viktig. Infrastruktur er usexy. Men den varer lenger enn funksjoner.

Regel 5: Ved slutten av arbeidsøkten skal det skrives

Et filsystem husker bare det som faktisk blir skrevet til filer. Derfor hører en oppføring i dagsloggen med når en agent avslutter en arbeidsøkt.

Hele samtalen skal ikke stå der. Det som tas vare på, er beslutninger, fullførte steg, viktige funn og åpne hull. Senere overføres dagens kunnskap til kuratert langtidskunnskap eller et varig læringsnotat.

Uten denne rutinen ville repositoriet bare vært en statisk samling prompter.

Regel 6: Krav om godkjenning er uttrykkelige

Hver agent som er i aktiv bruk, dokumenterer hva den kan gjøre på egen hånd, og hvor et menneske må bestemme. For Sol gjelder for eksempel dette: Hun kan lage utkast, men ikke publisere noe. En annen agent kan endre kode, men ikke starte utrulling i produksjon uten godkjenning.

Disse grensene er dokumentert hos agenten, ikke bare i et grensesnitt. Dermed følger de med når verktøyet byttes ut.

Regel 7: Brain er ikke et lager for hemmelige nøkler og påloggingsinformasjon

Et privat repositorium er ikke automatisk riktig sted for alt innhold. Hemmelige nøkler og påloggingsinformasjon i klartekst hører aldri hjemme der. Kundespesifikke personaer og fortrolig arbeidsinnhold blir i det beskyttede prosjektmiljøet de tilhører.

Den sentrale hjernen inneholder bare det som faktisk hører hjemme der på tvers av agentene. Denne grensen er en del av arkitekturen, ikke noe som ryddes opp i etterpå.

Slik er kunnskapshvelvet bygget opp

Den konkrete strukturen er bevisst forutsigbar:

• Først kommer spesifikasjonen og oversikter for mennesker og agenter.
• Et felles område inneholder merkevarestemmer, konvensjoner og læringsnotater som gjelder på tvers av agenter.
• Maler sørger for at nye agenter får de samme grunnleggende byggeklossene.
• Harness-adaptere danner forbindelsene til de ulike verktøyene.
• Hver agent får sin egen mappe med persona, arbeidsmåter, ferdigheter, grenser og hukommelse.

Denne ordenen er viktigere enn det nøyaktige mappenavnet. En ny agent skal kunne forstå hvor den kan lese og skrive, uten først å kjenne hele prosjekthistorikken.

Hvorfor Git og ikke en database?

En database kunne ha svart raskere på spørringer. Men for agentenes autoritative identitet gir Git tre fordeler som er viktigere for meg.

Lesbarhet: Markdown kan åpnes uten spesialprogramvare.

Sporbarhet: En diff viser hva som er endret. En commit knytter sammen endringen, tidspunktet og begrunnelsen.

Flyttbarhet: En klonet mappe kan brukes videre på en annen maskin og med et annet verktøy.

Det betyr ikke at databaser eller vektorsøk er ubrukelige. I oppsettet mitt kan de legges til som indeks eller hurtigbuffer. De gjør tilgangen raskere, men eier ikke kunnskapen.

Obsidian er grensesnittet, ikke fundamentet

Jeg bruker også rotmappen i repositoriet som et Obsidian-hvelv. Det gir meg wikilenker, grafvisning, søk og kuraterte oversiktssider. For meg som menneske er det svært nyttig.

Det viktige er likevel at Obsidian lagrer notatene som lokale filer. Grensesnittet kan byttes ut uten at kilden må skrives om.

Det er nettopp dette skillet jeg ønsker også for agentene. Et godt verktøy kan gjøre arbeidet mer behagelig. Det bør ikke avgjøre om kunnskapen min fortsatt er lesbar.

Den praktiske prøven

Et Agents Brain er først flyttbart når du kan svare ja på tre spørsmål:

1. Kan du lese personaen uten verktøyet du har brukt til nå?
2. Kan et annet verktøy laste inn de samme reglene uten at du kopierer dem?
3. Er det synlig hva en agent har tatt vare på i varig form ved slutten av arbeidsøkten?

Hvis ett av svarene er nei, ligger det fortsatt kunnskap i verktøyet i stedet for i hjernen på dette punktet.

I neste del deler jeg en enkelt agent opp i de fire kjernefilene: SOUL, MASTER, RULES og MEMORY. Skillet mellom dem gjør en lang prompt til en arbeidsidentitet som kan vedlikeholdes.

Kilder

• Prosjektkilde: agents-brain-spesifikasjonen, hvelvstrukturen og validatorene, per 15.07.2026 (privat primærkilde)
• CommonMark: åpen Markdown-spesifikasjon
• Pro Git: What is Git?
• Obsidian Help: How Obsidian stores data