{"id":3897,"date":"2026-07-22T07:45:00","date_gmt":"2026-07-22T05:45:00","guid":{"rendered":"https:\/\/isla-stud.io\/?p=3897"},"modified":"2026-08-14T21:53:55","modified_gmt":"2026-08-14T19:53:55","slug":"gehirn-meiner-agenten-git-repo","status":"publish","type":"post","link":"https:\/\/isla-stud.io\/no\/ki-b2b\/gehirn-meiner-agenten-git-repo\/","title":{"rendered":"Hjernen til agentene mine er et Git-repo"},"content":{"rendered":"

Dette f\u00e5r du med deg:<\/strong> Du f\u00e5r de sju reglene og den enkle strukturen i kunnskapshvelvet som gj\u00f8r at jeg kan holde agentenes kunnskap lesbar, versjonerbar og uavhengig av verkt\u00f8y.<\/p>\n\n\n\n\n\n

For meg trenger ikke en KI-agent noen mystisk hukommelse. Den trenger filer jeg kan lese, kontrollere og bruke p\u00e5 nytt.<\/p>\n\n\n\n

Derfor ligger hjernen til agentene mine i et privat Git-repositorium. Markdown er sannhetskilden der. Git dokumenterer n\u00e5r noe er endret. Obsidian gir meg et praktisk grensesnitt for s\u00f8k, lenker og oversikt, men er ingen forutsetning for \u00e5 f\u00e5 tilgang til innholdet.<\/p>\n\n\n\n

Hvis Obsidian ikke er tilgjengelig, \u00e5pner jeg filene i tekstredigereren. Hvis et agentverkt\u00f8y forsvinner, peker adapteren til samme mappe. Hvis en ekstra hukommelsesmotor kommer til, kan den indeksere innholdet, men ikke erstatte det.<\/p>\n\n\n\n

Det h\u00f8res enkelt ut. For at det ikke igjen skal bli en uoversiktlig samling filer i det daglige, gjelder sju ufravikelige regler.<\/p>\n\n\n\n

Regel 1: Markdown er sannhetskilden<\/h2>\n\n\n\n

Personaer, arbeidsregler og kuratert kunnskap ligger i Markdown-filer. Semantisk s\u00f8k, en vektorindeks eller en hukommelsesmotor kan gj\u00f8re det raskere \u00e5 f\u00e5 tilgang til dette innholdet. Men den avledede versjonen er aldri den eneste som finnes.<\/p>\n\n\n\n

Dette beskytter ikke bare mot \u00e5 bli bundet til et verkt\u00f8y. Det gj\u00f8r ogs\u00e5 rettelser etterpr\u00f8vbare. I en diff kan jeg se hvilken setning som er endret, i stedet for \u00e5 stole p\u00e5 at en usynlig hukommelsesprosess har lagret det riktige.<\/p>\n\n\n\n

Regel 2: En persona har n\u00f8yaktig \u00e9n hjerne<\/h2>\n\n\n\n

Den samme agenten skal ikke f\u00e5 en litt annerledes versjon av identiteten sin i hvert verkt\u00f8y. Claude, Codex, Gemini og Hermes skal ha tilgang til de samme autoritative filene.<\/p>\n\n\n\n

Ellers begynner personaene \u00e5 avvike fra hverandre: I ett verkt\u00f8y gjelder en ny godkjenningsregel, mens den gamle fortsatt gjelder i et annet. Eller en rettelse havner bare i \u00e9n systemprompt og g\u00e5r tapt neste gang agenten bytter kropp.<\/p>\n\n\n\n

\u00c9n kilde hindrer slike stille forgreninger.<\/p>\n\n\n\n

Tillegg:<\/strong> Listen over verkt\u00f8y har vokst. Repositoriet dokumenterer n\u00e5 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.<\/p>\n\n\n\n

Regel 3: Adaptere skal v\u00e6re tynne<\/h2>\n\n\n\n

Et \u00abharness\u00bb er verkt\u00f8yet en agent arbeider i. Hvert system trenger derfor en passende forbindelse: en konfigurasjonsfil, en prosjektbeskrivelse eller en systemprompt.<\/p>\n\n\n\n

Disse adapterne skal bare gj\u00f8re tre ting: finne riktig agentmappe, angi leserekkef\u00f8lgen og kreve tilbakeskriving til hukommelsen. Persona, fagkunnskap og styringsregler kopieres ikke inn i adapteren.<\/p>\n\n\n\n

Jo tynnere forbindelsen er, desto enklere er den \u00e5 bytte ut.<\/p>\n\n\n\n

Regel 4: Felles kunnskap henvises til<\/h2>\n\n\n\n

Flere agenter trenger samme merkevarestemme, de samme typografireglene eller de samme sikkerhetskonvensjonene. Slikt innhold ligger i et felles omr\u00e5de og lastes derfra.<\/p>\n\n\n\n

Jeg kopierer det ikke inn i hver agentmappe. En rettelse i den felles kilden skal n\u00e5 alle ber\u00f8rte roller. Kopier ville begynt \u00e5 avvike fra hverandre allerede etter den f\u00f8rste endringen.<\/p>\n\n\n\n

Denne regelen er lite spektakul\u00e6r. Nettopp derfor er den viktig. Infrastruktur er usexy. Men den varer lenger enn funksjoner.<\/p>\n\n\n\n

Regel 5: Ved slutten av arbeids\u00f8kten skal det skrives<\/h2>\n\n\n\n

Et filsystem husker bare det som faktisk blir skrevet til filer. Derfor h\u00f8rer en oppf\u00f8ring i dagsloggen med n\u00e5r en agent avslutter en arbeids\u00f8kt.<\/p>\n\n\n\n

Hele samtalen skal ikke st\u00e5 der. Det som tas vare p\u00e5, er beslutninger, fullf\u00f8rte steg, viktige funn og \u00e5pne hull. Senere overf\u00f8res dagens kunnskap til kuratert langtidskunnskap eller et varig l\u00e6ringsnotat.<\/p>\n\n\n\n

Uten denne rutinen ville repositoriet bare v\u00e6rt en statisk samling prompter.<\/p>\n\n\n\n

Regel 6: Krav om godkjenning er uttrykkelige<\/h2>\n\n\n\n

Hver agent som er i aktiv bruk, dokumenterer hva den kan gj\u00f8re p\u00e5 egen h\u00e5nd, og hvor et menneske m\u00e5 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.<\/p>\n\n\n\n

Disse grensene er dokumentert hos agenten, ikke bare i et grensesnitt. Dermed f\u00f8lger de med n\u00e5r verkt\u00f8yet byttes ut.<\/p>\n\n\n\n

Regel 7: Brain er ikke et lager for hemmelige n\u00f8kler og p\u00e5loggingsinformasjon<\/h2>\n\n\n\n

Et privat repositorium er ikke automatisk riktig sted for alt innhold. Hemmelige n\u00f8kler og p\u00e5loggingsinformasjon i klartekst h\u00f8rer aldri hjemme der. Kundespesifikke personaer og fortrolig arbeidsinnhold blir i det beskyttede prosjektmilj\u00f8et de tilh\u00f8rer.<\/p>\n\n\n\n

Den sentrale hjernen inneholder bare det som faktisk h\u00f8rer hjemme der p\u00e5 tvers av agentene. Denne grensen er en del av arkitekturen, ikke noe som ryddes opp i etterp\u00e5.<\/p>\n\n\n\n

Slik er kunnskapshvelvet bygget opp<\/h2>\n\n\n\n

Den konkrete strukturen er bevisst forutsigbar:<\/p>\n\n\n\n