# En ekstra hjerne i Claude Code: Slik bygger du strukturen på én time > Slik bygger du en ekstra hjerne for Claude Code: et minnehierarki, en mappestruktur med fem deler og git, slik at agenten husker alt om prosjektet ditt mellom øktene. Source: https://ailoot.ai/blog/nb/claude-code-second-brain/ Canonical: https://ailoot.ai/blog/nb/claude-code-second-brain/ Language: nb Publisher: Ailoot (https://ailoot.ai/) Translation: guide-233 Revision: sha256-fe46c535bce83c1c08011faec2905ad8db81cd0530bfbdd3fa0e05776dadfc68
Hovedpoeng En ekstra hjerne for Claude Code er ikke én fil; det er en struktur med fem mapper pluss git. CLAUDE.md fastsetter regler og ruter, `business/` lagrer kunnskap om prosjektet, `ai-clone/` lagrer informasjon om deg som beslutningstaker, `plans/` inneholder tekniske planer, og `retrospectives/` inneholder lærdommer fra tidligere økter. Agenten starter med CLAUDE.md og følger lenker til riktig mappe for den aktuelle forespørselen. Denne artikkelen dekker minnehierarkiet i den offisielle Claude Code-dokumentasjonen, en struktur med fem deler og hvordan du bygger den trinn for trinn på én time.
Ailoot-referansedokumentasjon: [ailoot.ai/docs/](https://ailoot.ai/docs/). ## Hvorfor trenger Claude Code en ekstra hjerne, og hva er viktig?
Hovedpoeng Én CLAUDE.md-fil dekker de grunnleggende reglene, men den kan ikke håndtere forretningsminne. Etter en måned har du glemt hvorfor du satte opp prisen. Etter tre måneder har du glemt hvorfor du avviste avbetaling. Kunnskapen finnes samtidig på fire steder: i hodet ditt, i Telegram-chatter, i Google-dokumenter og i hodene til de ansatte. En ekstra hjerne samler alt i én mappe med markdown-filer ved siden av prosjektet, og Claude kan finne fram dit på egen hånd.
Du åpner Claude Code på tirsdag. Du forklarer: dette er prosjektet, dette er målgruppen, ikke gjør dette. Dere jobber sammen. På torsdag er det en ny chat, og du må forklare alt på nytt. Hvis du har en CLAUDE.md, har du løst den første frustrasjonen. De grunnleggende reglene og prosjektbeskrivelsen ligger i én fil og lastes inn i hver økt. Jeg har forklart hvordan denne filen fungerer i [veiledningen min om CLAUDE.md](https://ailoot.ai/blog/nb/claude-md-template/) - les den gjerne først for å få grunnlaget på plass. Men CLAUDE.md er en instruksjonsbok for en nyansatt. Hvordan kle seg, hvilken tone man skal bruke overfor kunder, hvilke kommandoer man skal bruke for publisering. Det er ikke nok til å ta gode beslutninger om prosjektet. Beslutninger krever kunnskap: hva produktet er, hvem målgruppen er, hvordan økonomien fungerer, hva du har prøvd, og hva som ikke fungerte. I forfatterens erfaring som beskrives her, fantes denne kunnskapen tidligere på fire steder: i hodet deres, i Telegram-chatter, i Google-dokumenter og i hodene til de ansatte. En måned etter en beslutning husket ingen hvorfor den var tatt. En ny person måtte bruke en time på å stille teamet spørsmål for å komme à jour. Claude var ikke del av denne konteksten i det hele tatt. Før den ekstra hjernen betydde hver økt, slik forfatteren beskriver erfaringen, at jeg måtte forklare på nytt hvem kunden var, hvordan tilbudet var satt sammen, og hvilken leverandør som håndterte betalingene. Med `business/` åpner jeg en chat og sier «oppdater tilbudet for den nye prisplanen» - Claude går på egen hånd til `business/company/legal.md`, leser kravene, går så til `business/products/pricing.md`, ser den nye prisplanen og foreslår en endring i ett trinn. Oppvarmingen er borte; konteksten lastes automatisk.
Merknad Dette er ikke et problem med Claudes minne. Det er et arkitekturproblem. Kontekstvinduet til en agent er arbeidsminnet dens. Det laster bare inn det du uttrykkelig peker på. Alt annet ligger utenfor vinduet og lastes inn ved behov. En ekstra hjerne lagrer «alt det andre» på en strukturert måte, slik at Claude kan finne fram.
Anthropic kaller dette problemet «context rot» i den tekniske bloggen sin:
Jo flere tokener det er i kontekstvinduet, desto dårligere blir modellen til å hente fram informasjon fra den konteksten på en nøyaktig måte.
— Anthropic, anthropic.com/engineering/effective-context-engineering-for-ai-agents
Med andre ord blir agenten dårligere til å arbeide med detaljer jo mer du stapper inn i vinduet. Løsningen er å ha en struktur med eksterne filer som Claude kan besøke på egen hånd som svar på en konkret forespørsel. Det er det en ekstra hjerne er. ## Hva er en ekstra hjerne, og hvordan gjelder Tiago Fortes konsept for Claude?
Hovedpoeng Ideen er enkel: Hjernen er til for å tenke, ikke for å lagre tanker. For Claude Code går et «second brain» fra å være en produktivitetsmetode til å bli en agentarkitektur: en ekstern mappe med notater som agenten kan få direkte tilgang til gjennom filsystemet.
Typisk handler et «second brain» om produktivitet generelt: Folk oppretter et Obsidian-hvelv og legger til utdrag fra bøker, notater fra samtaler og prosjektideer. Da forfatteren tok denne ideen i bruk i arbeidet med Claude Code, sluttet den å handle om produktivitet og ble i stedet agentarkitektur. I den klassiske tilnærmingen er den ekstra hjernen din, og du bruker den manuelt. Når du jobber med Claude Code, blir den ekstra hjernen **toveis**: både du og agenten bruker den. Det endrer kravene til formatet. Siden agenten åpner den på egen hånd, må filene være i et format den forstår uten en separat integrasjon. Markdown er ideelt: tekst, et hierarki av overskrifter og lenker mellom filer. Notion og Google Docs egner seg ikke. Du kan koble dem til via MCP, men det legger til et ekstra lag, en ekstra token per forespørsel og enda et mulig feilpunkt. Siden filene ligger i filsystemet ved siden av prosjektet, er de automatisk innen rekkevidde for Claude Code. Ingen oppsett nødvendig. Start agenten i prosjektmappen, så kan den se alle filene der. Det er gratis og fungerer rett ut av boksen.
Tips Du kan ha den ekstra hjernen i Obsidian - jeg åpner den der også for å gjøre det lettere å se forbindelsesgrafen. Men selve filene ligger i en vanlig mappe ved siden av koden. Obsidian er bare et praktisk skall rundt markdown-filer. Claude kan se dem uten Obsidian. Du kan bruke hvilken som helst editor; det viktige er at filene ligger på disken, ikke i en skytjeneste med sitt eget format.
## Hvilket minnehierarki har Claude Code fra før?
Hovedpoeng Claude Code kan som standard lese fire CLAUDE.md-nivåer (enterprise, user, project og local), og siden versjon 2.1.59 har den hatt sitt eget automatiske minne i `~/.claude/projects//memory/`. Det holder til grunnleggende minne, men ikke forretningskontekst - den legger du i en egen mappe ved siden av prosjektet.
Før vi legger til noe selv, la oss se på hva Claude kan huske uten hjelp fra deg. Anthropic beskriver to mekanismer i den [offisielle dokumentasjonen](https://code.claude.com/docs/en/memory): CLAUDE.md (regler du skriver) og auto memory (lærdommer Claude skriver selv). Begge lastes inn ved starten av hver økt. Claude Code søker etter CLAUDE.md på fire steder samtidig: | Nivå | Plassering | Formål | |----|----|----| | **Enterprise** | `/Library/Application Support/ClaudeCode/CLAUDE.md` (macOS), `/etc/claude-code/CLAUDE.md` (Linux), `C:\Program Files\ClaudeCode\CLAUDE.md` (Windows) | Regler som en administrator distribuerer til hele teamet gjennom MDM. Enkeltpersoner trenger ikke dette. | | **User** | `~/.claude/CLAUDE.md` | Personlige regler som gjelder på tvers av alle prosjekter. «Svar på språket jeg foretrekker», «ikke bruk lange tankestreker». | | **Project** | `./CLAUDE.md` i prosjektroten | Regler for et bestemt prosjekt: teknologistakk, mappestruktur, forretningsregler. Sjekkes inn i git. | | **Local** | `./CLAUDE.local.md` | Dine personlige notater for dette prosjektet, som ikke sjekkes inn i git. I `.gitignore`. | Alle fire filene lastes inn i konteksten. Jo mer spesifikt nivået er, desto høyere prioritet har det. Den lokale filen leses sist, så reglene der overstyrer alt annet. En CLAUDE.md-fil kan også ligge i en hvilken som helst mappe i prosjektet. Når Claude leser en fil fra en undermappe, laster den inn CLAUDE.md-filen fra den undermappen ved behov. Dette er nyttig i et monorepo: frontend-regler ligger i `frontend/CLAUDE.md`, backend-regler i `backend/CLAUDE.md`, og de lastes bare inn når agenten jobber med den aktuelle delen. Automatisk minne kom i Claude Code 2.1.59. Dette er filer Claude skriver om deg: ``` ~/.claude/projects//memory/ ├── MEMORY.md # Indeks, lastes inn i hver økt (200 linjer eller 25KB) ├── debugging.md # Detaljerte notater (lastes inn ved behov) ├── api-conventions.md └── ... ``` Anthropic beskriver det slik i den offisielle dokumentasjonen:
Claude lagrer ikke noe i hver økt. Den avgjør hva som er verdt å huske, basert på om informasjonen kan være nyttig i en framtidig samtale.
— Anthropic, code.claude.com/docs/en/memory
Automatisk minne aktiveres med flagget `autoMemoryEnabled` i `~/.claude/settings.json`. Claude bestemmer hva den skal skrive der. Du kan lese MEMORY.md og redigere den manuelt - det er vanlig markdown.
Advarsel Automatisk minne er nyttig, men det erstatter ikke en ekstra hjerne. Claude skriver taktiske lærdommer om verktøy og kodemønstre der. «Dette skriptet fungerer ikke uten flagg X», «denne databasetabellen heter dette». Den skriver ikke forretningsstrategi der. Hvis du vil at agenten skal huske hvem målgruppen din er og hvorfor du valgte en bestemt pris, må du legge det i en egen kontekstmappe selv.
## CLAUDE.md eller en ekstra hjerne - hvor bør du trekke grensen?
Hovedpoeng CLAUDE.md er en instruksjonsbok for en nyansatt: hvordan man skal oppføre seg, hvilke kommandoer man skal bruke, og hva man ikke skal gjøre. En ekstra hjerne er en bedriftswiki: hva dere gjør, hvem det er for, hvordan økonomien fungerer, og hva dere har prøvd. Én fil med atferdsregler pluss en struktur med ekstern kunnskap. CLAUDE.md er indeksen; den ekstra hjernen er arkivet. Uten indeksen vet ikke agenten at arkivet finnes. Uten arkivet kjenner den bare reglene, ikke forretningskonteksten.
Her er sammenligningen jeg bruker i foredragene mine: Tenk deg at du har ansatt en ny medarbeider. Hva gir du dem den første dagen? En instruksjonsbok: hvordan kle seg, når man skal møte, hvilken tone man skal bruke overfor kunder, hvilket system man skal publisere gjennom. Det er et kort dokument. Det forklarer ikke hva dere gjør eller hvorfor. Det sier bare hvordan man skal oppføre seg. Og separat tilgang til bedriftswikien. Den forklarer hva produktet er, hvem det er for, hvem målgruppen er, hva prisen er og hvorfor, hvem konkurrentene er, og hvilke feil dere har gjort. Det er et omfattende arkiv. Ingen leser alt - man går dit for å finne svar på et konkret spørsmål. CLAUDE.md = instruksjonsbok. Ekstra hjerne = wiki. Du trenger begge. Skillet er enkelt. Legg alt som er **relevant for hver oppgave** i CLAUDE.md: - Hvem agenten er i dette prosjektet (hjelper, leder, assistent) - Hvilket språk den skal svare på - Verktøystakk - Publiseringskommandoer - Forbud (ikke bruk lange tankestreker, ikke kjør `git push --force`) - Ruting: hvor den skal gå for forretningskontekst og hvor den skal gå for prinsipper Legg alt som er **nødvendig ved behov** i den ekstra hjernen: - Produktet, målgruppen, økonomien og målene - Konkurrenter og marked - Tidligere beslutninger og årsakene til dem - Kundecaser og anmeldelser - Prinsipper og metodikk Anthropic gjør det samme skillet i dokumentasjonen sin:
CLAUDE.md lastes inn i hver økt, så ta bare med det som gjelder bredt. For domenekunnskap eller arbeidsflyter som bare trengs av og til, bruker du skills. Claude laster dem inn ved behov uten å gjøre hver samtale unødvendig stor.
— Anthropic, code.claude.com/docs/en/best-practices
Skills er én måte å lagre situasjonsbestemt kunnskap på. En `business/`-mappe ved siden av prosjektet er en annen. Jeg bruker begge, og forklarer dem nærmere nedenfor. ## Hva består prosjektets ekstra hjerne av - 5 deler pluss en tidsmaskin
Hovedpoeng En prosjekt-hjerne er fem mapper med git på toppen. CLAUDE.md fastsetter reglene og rutene. `ai-clone/` lagrer din digitale projeksjon: prinsippene dine, tonen din og tilbakemeldinger etter feil. `business/` lagrer kunnskap om prosjektet. `plans/` inneholder tekniske planer for hver fase. `retrospectives/` inneholder refleksjoner etter økter. Git gjør alt sammen til en tidsmaskin: et år senere kan du åpne hvilken som helst fil og se hva den inneholdt da beslutningen ble tatt.
Et eksempel på arkitektur fra forfatterens beskrevne erfaring: | Mappe | Innhold | Formål | |----|----|----| | **`CLAUDE.md`** | Prosjektregler, stakk, filstruktur, mapperuting, kommunikasjonsspråk | Dette er agentens instruksjonsbok. Lastes inn i hver økt. Under 200 linjer, helst 80-120. | | **`ai-clone/`** | Hvem jeg er, prinsippene mine, tonen min, beslutningsstilen min, tilbakemeldinger etter feil | En digital projeksjon av meg som beslutningstaker. Den vet hva jeg avviser umiddelbart, hvordan jeg pleier å foreslå ting, og hvilke regler jeg har lært av feil. | | **`business/`** | Produkt, målgruppe, mål, økonomi, markedsføring, tidligere beslutninger, eksempler | Lenker til markdown-filer med wikilenker. Hver fil er koblet til andre gjennom lenker av typen `[[...]]`. Agenten går dit for å finne svar på et konkret spørsmål. | | **`plans/`** | Én plan per funksjon. Filen `YYYY-MM-DD-feature.md` med faser og avkrysningsbokser | Plan Mode finnes i én samtale og går tapt etter `/clear`. Mappen `plans/` ligger i repositoriet - enhver agent kan når som helst fortsette med planen. | | **`retrospectives/`** | Refleksjoner etter hver økt: hva som ble gjort, hva man skal huske, hva som kan bli bedre | Systemets egenlæring. Feil blir til regler i `ai-clone/feedback/`. | | **`+ git`** | Versjonshistorikk for alle filer | En tidsmaskin. Åpne en hvilken som helst fil og kjør `git log` for å se når den ble endret og hvorfor. | Det viktigste metodiske poenget er å **holde `ai-clone/` og `business/` adskilt**. `business/` svarer på spørsmålet «hva gjør vi?» Produkt, målgruppe, priser, konkurrenter. Det handler om prosjektet. Hvis du gir prosjektet videre til en partner i morgen, følger denne mappen med. `ai-clone/` svarer på spørsmålet «hvordan tar jeg beslutninger?» Prinsippene mine, tonen min, håndverket mitt og stoppeordene mine. Det handler om meg. Hvis jeg begynner på et nytt prosjekt i morgen, følger denne mappen med meg. Sammen skaper de det jeg kaller et selskap med én person. Én person pluss strukturert kontekst pluss AI som leser den konteksten. Vil du ikke bare sette opp en ekstra mappe, men også bygge et system som gjør Claude konsekvent? Det er ikke nok i seg selv. Uten `profile/` svarer agenten på vegne av alle, ikke deg. Uten context engineering vandrer den gjennom hele mappen og bruker opp tokener. Det er nyttig å koble sammen alle tre tingene: **second brain + AI-klone + context engineering**. Dette er de **tre pilarene** som AI ikke fungerer uten. ## Hva bør ligge i business/, og hva bør ikke ligge der?
Hovedpoeng Legg prosjektfakta som endres høyst én gang i uken i `business/`: posisjonering, målgruppe, produkter og priser, kvartalsmål og viktige beslutninger. Ikke ta med chatkorrespondanse, ubearbeidede råmaterialer, informasjon som allerede finnes i koden, skjermbilder eller dynamiske tall. Erstatt tall med LIVE-markøren og en lenke til en SQL-spørring - dette forklarer jeg i en egen del nedenfor.
Strukturen på øverste nivå i `business/` i forfatterens beskrevne prosjekt: ``` business/ ├── INDEX.md ← kart over mappen, les først ├── company/ ← visjon, juridisk enhet, verdier, juridiske retningslinjer ├── products/ ← produkter, programmer, priser ├── audience/ ← kundeprofil, segmenter, innvendinger ├── goals/ ← årlige, kvartalsvise og månedlige mål, måltall ├── economics/ ← enhetsøkonomi, inntekter, utgifter, prognose ├── marketing/ ← kanaler, salgstrakt, materiell, konkurrenter ├── execution/ ← ukentlig planlegging, backlog └── assets/ ← designsystem, anmeldelser, tekstbank ``` Dette er et eksempel fra forfatterens beskrevne prosjekt, ikke en fast regel. Jeg oppretter mapper ved behov. Jeg begynte med tre (`products/`, `audience/`, `goals/`); de andre kom til etter 2-3 måneder, da det ble uklart hvor nye ting skulle legges. Hovedfilen i mappen er `INDEX.md`. Den er et kart. Den inneholder en tabell med «spørsmål → fil» som Claude bruker for å finne ut hvor den skal gå. Uten den bruker agenten tokener på å lese hver fil i rekkefølge. Et eksempelutdrag fra `INDEX.md`: ```markdown ### Hvor du finner ting | Hva du trenger | Hvor du skal se | |---|---| | Hvem kunden vår er, og hva som er smertepunktene deres | `business/audience/avatar.md` | | Produkter, planer og priser | `business/products/` | | Mål og måltall | `business/goals/` | | Økonomi (inntekter, utgifter, enhetsøkonomi) | `business/economics/` | | Markedsføringskanaler og materiell | `business/marketing/` | ``` Da holder det med én linje i `CLAUDE.md`: «For spørsmål om virksomheten, les `business/INDEX.md` og følg kartet.» Agenten laster ikke inn hele mappen i konteksten. Den laster inn kartet, velger riktig fil og leser bare den. **Sjekkliste over hva du ikke bør legge i `business/`:** - Rå chatkorrespondanse uten bearbeiding. Hvis det finnes en innsikt, trekk ut essensen og skriv den ned. Hvis ikke, utelat den. - Informasjon som allerede finnes i koden. «Betalinger går gjennom CloudPayments» er unødvendig; agenten kan se det i koden. - Skjermbilder og bilder. De øker størrelsen på mappen og blir ikke tolket av en tekstmodell uten et ekstra trinn. - Dynamiske tall. «I dag er det 423 betalinger for produktet» er utdatert om en uke. Bruk LIVE-markøren og en lenke til et databasesøk. - Sensitiv eller tvilsom informasjon. Hvis repositoriet skulle bli lagt ut på YouTube foran 100 tusen fremmede i morgen, ta bare med det du er villig til å vise. Ansatte, agenter og noen ganger eksterne konsulenter leser mappen.
Advarsel Hvis repositoriet er offentlig, er `business/`-mappen også offentlig. Jeg behandler den ekstra hjernen som om repositoriet kunne bli offentlig i morgen, selv om det er privat akkurat nå. Ikke oppgi kundenavn uten samtykke, månedlige omsetningstall eller passord. Denne vanen sparer mye stress.
## Hvorfor ha en egen ai-clone-mappe, og hvorfor bør den ikke blandes med business?
Hovedpoeng `ai-clone/` lagrer din digitale projeksjon: prinsipper, tone, stoppeord og tilbakemeldinger etter feil. Hver agentfeil blir til en regel i `ai-clone/feedback/` etter formelen «regel → hvorfor → hvordan bruke». Mappen følger deg fra prosjekt til prosjekt. `business/` blir hos prosjektet. Hold dem adskilt: i et nytt prosjekt blir `business/` ny, men prinsippene og stilen din forblir de samme.
Ideen er enkel: virksomheten vet hva vi gjør. Klonen vet hvordan jeg tar beslutninger. Strukturen i `ai-clone/` i forfatterens beskrevne prosjekt: ``` ai-clone/ ├── INDEX.md ← kart over mappen ├── role.md ← hvem jeg er, bakgrunn, hva som betyr noe ├── identity/ ← verdier, visjon, oppdrag ├── thinking/ ← mentale modeller fra foredrag ├── voice/ ← tone, ordforråd, stil ├── principles/ ← oppfatninger om produkt, kode, virksomhet ├── feedback/ ← regler lært gjennom feil ← hovedmappen ├── style/ ← stoppeord, Telegram-format └── reference/ ← verktøy, miljø ``` Den nyttigste mappen er `feedback/`. Den inneholder konkrete regler jeg har lært gjennom agentfeil. Hver regel legges i en egen fil med dette formatet: ```markdown --- name: short-name description: one line - what’s in the file and when to apply it type: feedback --- En kort regel i én setning. **Hvorfor:** hvorfor denne regelen finnes. Kontekst, hendelse, observasjon. **Hvordan bruke:** konkrete utløsere for når regelen gjelder. ``` Uten «Hvorfor» er regelen død - agenten vil ikke overføre den til en lignende situasjon. Uten «Hvordan bruke» er det uklart når regelen skal brukes. Et eksempel fra mappen min: regelen «bindestrek, ikke lang tankestrek». Den oppstod fordi den lange tankestreken `—` er et tydelig visuelt kjennetegn på generert tekst. Den gjelder all tekst som skal vises offentlig. Filen ligger på `ai-clone/feedback/no-em-dashes.md`. Jeg gjør det litt annerledes: Jeg skriver regler i `ai-clone/feedback/`, ikke i `CLAUDE.md`. CLAUDE.md er en prosjektfil, men regler om tone og stil er personlige. De følger meg til neste prosjekt. `CLAUDE.md` blir hos prosjektet.
Merknad Et mål på hvor modent dette opplegget er: Hvor mange ganger i uken sier du til agenten «nei, ikke sånn» om det samme? I et modent system er svaret null. Hver feil blir til en regel i `feedback/`, og agenten gjentar den ikke neste gang.
## Hva er Live Metrics, og hvorfor bør man ikke skrive tall direkte inn i filer?
Hovedpoeng Tall i filer for den ekstra hjernen blir utdaterte i løpet av noen dager. «1 000 kunder» i dag blir 1 050 i morgen og 2 000 om en måned. Hvis du skriver tallet rett inn, kommer agenten en måned senere til å foreslå ting basert på gårsdagens data. Løsningen er en LIVE-markør i filen pluss et eget `live-metrics.md`-dokument med SQL-spørringer som er klare til å kjøre. Når agenten ser LIVE, går den til databasen, henter det gjeldende tallet og resonerer ut fra oppdaterte data.
En av de viktigste fallgruvene når man begynner med en ekstra hjerne, er å fylle den med utdaterte tall. Du skriver «vi har 320 kunder», og to uker senere er det allerede 410. Du skriver «månedlig omsetning er 4,7 millioner», og en måned senere mangler tallet kontekst: er det et mål, et faktisk tall eller en prognose? I forfatterens eksempel fungerer det slik. I filen `business/products/practicum.md` står en markør i stedet for et tall: ```markdown ## Kull > **LIVE** - kjør spørringene i `live-metrics.md`, delen «Salg» > for å se gjeldende betalinger per kull. | Kull | Datoer | Betalende | |-------|------|------------| | 1 | 10.-12. mars 2026 | LIVE | | 2 | 24.-26. mars 2026 | LIVE | ``` En egen `live-metrics.md`-fil inneholder SQL-spørringer som er klare til å kjøre, og beskrivelser av hva de returnerer: ````markdown ## Salg (betalinger per kull) ```sql SELECT c.name, COUNT(p.id) AS paid, SUM(p.amount) AS revenue FROM purchases p JOIN cohorts c ON c.id = p.cohort_id WHERE p.status = 'paid' GROUP BY c.name ORDER BY c.starts_at DESC; ``` ```` Når jeg spør agenten «hvor mange betalinger har vi for det andre kullet?», gjør den følgende: 1. Leser `business/products/practicum.md` 2. Ser LIVE-markøren ved siden av tallet 3. Åpner `live-metrics.md` 4. Finner delen «Salg» 5. Kjører spørringen mot produksjonsdatabasen 6. Svarer med oppdaterte data Dette løser to problemer samtidig. Tallene blir ikke utdaterte. Og beslutninger tas ut fra den nåværende situasjonen, ikke fjorårets.
Advarsel I forfatterens beskrevne opplegg har bare betrodde agenter tilgang til produksjonsdatabasen. De får bare tilgang gjennom en wrapper som logger spørringer og ikke eksponerer passord. Å legge inn en direkte `psql`-kommando med et passord i klartekst i `live-metrics.md` er en dårlig idé. Lag en wrapper som henter passordet fra en miljøvariabel og ikke viser det i utskriften. Det er et separat teknisk lag, men uten det blir LIVE et sikkerhetshull.
## Hvordan finner AI fram i den ekstra hjernen for én enkelt forespørsel?
Hovedpoeng Forespørselsløpet er alltid det samme: Claude leser CLAUDE.md, ser kartene (`business/INDEX.md`, `ai-clone/INDEX.md`), går til riktig INDEX, følger den til en bestemt fil og henter om nødvendig et tall via LIVE. Det er 5-6 leseoperasjoner i stedet for å stappe hele mappen inn i konteksten. Vinduet forblir ledig til resonnering, og tokener brukes ikke på irrelevante filer.
En konkret forespørsel kan for eksempel være: «skriv et e-postutkast til deltakerne om det nye kullet». 1. Claude starter med et tomt vindu. Den laster inn CLAUDE.md (regler, stakk, ruting). 2. Fra rutingen i CLAUDE.md ser den: «`ai-clone/INDEX.md` - les alltid i starten av en økt». Den åpner filen og lærer hvem jeg er, hvilken tone jeg bruker, og hvilke stoppeord jeg har. 3. I rutingen ser den: «e-postmaler - `src/lib/email/layout.ts`». Den åpner filen og forstår formatet. 4. Den ser: «produktkontekst - `business/products/practicum.md`». Den åpner filen og leser om produktet. 5. Den ser LIVE-markøren i filen og en henvisning til `live-metrics.md`. Den åpner filen og finner SQL-spørringen som er klar til å kjøres. Hvis den trenger et oppdatert tall, kjører den spørringen. Hvis ikke, merker den av «hent dette tallet ved utsendelse». 6. Den ser tonereglene i `ai-clone/style/telegram-format.md`, forbudet mot lange tankestreker i `ai-clone/feedback/no-em-dashes.md` og konverteringsratene for salgstrakten i `business/marketing/funnel.md`. Den skriver e-posten i min tone, med oppdaterte tall og uten lange tankestreker eller AI-markører. Anthropic kaller dette «just-in-time context» i den tekniske bloggen sin:
Agenter som er bygget med en «just in time»-tilnærming, oppbevarer lette identifikatorer (filstier, lagrede spørringer, lenker og lignende) og bruker disse lenkene til å hente data dynamisk inn i konteksten ved kjøretid ved hjelp av verktøy.
— Anthropic, anthropic.com/engineering/effective-context-engineering-for-ai-agents
Med andre ord har Claude pekere til data, ikke selve dataene. Det er langt mer effektivt med tanke på tokener og langt mer nøyaktig, fordi bare relevant informasjon havner i konteksten. Vinduet forblir ledig til resonnering. ## 5 uheldige mønstre for ekstra hjerner - hva bør du unngå?
Hovedpoeng De vanligste nybegynnerfeilene med en ekstra hjerne: 1) en oppblåst CLAUDE.md med 500+ linjer i stedet for en kort ruter; 2) en samlemappe som blir en dump; 3) duplisering av ting Claude allerede vet fra språket eller koden; 4) tall skrevet rett inn som blir utdaterte fordi de ikke bruker LIVE; 5) å gjøre kontekst utilgjengelig for agenten eller unnlate å vise veien til den, enten den ligger i samme repository eller et separat privat lager.
Uheldig mønster 1. **En oppblåst CLAUDE.md.** 500 linjer med instruksjoner «i stedet for å legge alt på ett sted». Anthropic er tydelig:
Hold den kort. Spør for hver linje: «Hvis jeg fjerner denne, kommer Claude til å begynne å gjøre feil?» Hvis ikke, slett den. Oppblåste CLAUDE.md-filer får Claude til å ignorere instruksjonene dine!
— Anthropic, code.claude.com/docs/en/best-practices
Målet er 80-120 linjer. Legg alt annet i separate filer, og henvis videre til dem. Uheldig mønster 2. **En samlemappe.** Du slenger alt inn i den ekstra hjernen: rå chatkorrespondanse, unyttige skjermbilder, rapporter ingen kommer til å lese. En måned senere har mappen vokst, agenten bruker tokener på å lese søppel, og du husker ikke hvor noe ligger. Regelen: Hver fil i den ekstra hjernen skal besvare et konkret spørsmål. Hvis ingen har åpnet den på seks måneder, slett den eller flytt den til arkivet. Uheldig mønster 3. **Duplisering.** «Betalinger går gjennom CloudPayments, i `src/lib/payment/cloudpayments.ts`; leverandøren er konfigurert i `.env`.» Agenten kan se alt dette i koden. Ikke gjenta det i `business/`. Duplikater blir utdaterte: koden endres, `business/` blir ikke oppdatert, og agenten arbeider ut fra utdatert informasjon. Uheldig mønster 4. **Tall skrevet rett inn.** «Vi har 1 247 kunder, med en konverteringsrate på 6,3 %» - tenk deg at dette er tall fra en eller annen abstrakt fintech-oppstartsbedrift. Slike tall blir utdaterte i løpet av en uke. Bruk LIVE-markøren og `live-metrics.md`. Delen om dette står ovenfor. Uheldig mønster 5. **Kontekst uten tilgjengelig rute.** Hvis den ekstra hjernen ligger et annet sted og agenten verken har tillatelse eller peker til den, er oppstart i kodemappen utilstrekkelig. Ikke-sensitive delte notater kan praktisk ligge i `business/` og `ai-clone/` inne i repositoryet. Privat kontekst bør ligge på et separat kontrollert sted med eksplisitt konfigurert tillatt tilgang og ruting. Praktisk mappeoppsett overstyrer ikke konfidensialitet.
Tips En egen branch (`context` eller `business-context`) organiserer arbeid, men er ingen tilgangsgrense. Filene er fortsatt Git-objekter i samme repository og kan publiseres med grener eller historikk. Bruk et separat privat repository eller eksternt lager med eksplisitt tilgangskontroll og tillatt agentruting for privat forretningskontekst. En submodul kan peke til et privat repository, men personvernet kommer fra det repositoryets tillatelser, ikke submodulen selv. Et alternativ er en bevisst ignorert lokal mappe med egen sikkerhetskopi. Ignorering fjerner ikke filer som allerede spores i Git eller tidligere publisert historikk. Behold bare delbar kontekst sammen med koden.
## Hvordan bygge en ekstra hjerne på én time - en trinnvis oppskrift
Hovedpoeng Du kan sette opp en minimal ekstra hjerne på én time: opprett rotmappene `business/` og `ai-clone/`, lag et `INDEX.md`-kart i hver, legg til en kort produktbeskrivelse under `business/products/`, en kunde beskrivelse under `audience/` og en beskrivelse av hvem du er i `ai-clone/role.md`. Legg til ruting til disse mappene i `CLAUDE.md`. Bygg den deretter videre mens du jobber: etter hver agentfeil legger du til en regel i `ai-clone/feedback/`; etter hver beslutning legger du til et notat i `business/`.
1. ### Opprett to rotmapper I prosjektroten, ved siden av `src/`: ```bash mkdir -p business/{products,audience,goals,economics,marketing} mkdir -p ai-clone/{identity,voice,principles,feedback,style} ``` 2. ### Lag et INDEX.md som kart over mappen `business/INDEX.md` er en tabell med «spørsmål → fil». Start med minst 5 rader og legg til flere etter hvert. Gjør det samme i `ai-clone/INDEX.md`. 3. ### Legg til korte beskrivelser av produktet og kunden `business/products/main.md` - hva produktet er, hvem det er for, hvor mye det koster, og hva som skiller det fra andre. 30-50 linjer. `business/audience/avatar.md` - hvem kunden er, smertepunktene deres, og hva de kjøper. 30-50 linjer. Ikke beskriv en idealkunde - beskriv en faktisk kunde. Hvis du ikke vet noe, merk det «må avklares» og gå videre. 4. ### Beskriv deg selv i ai-clone/role.md Hvem du er, hva du gjør og hva som betyr noe for deg. 20-30 linjer. Det holder til å begynne med. Legg til tone, prinsipper og stoppeord når du legger merke til at agenten skriver i en stil som ikke er din. 5. ### Legg til ruting i CLAUDE.md Åpne `CLAUDE.md` og legg til en del: ```markdown ## Prosjektkart - Forretningskontekst → `business/INDEX.md` - Kontekst om meg → `ai-clone/INDEX.md` - Tekniske planer → `plans/YYYY-MM-DD-*.md` - Refleksjoner over tidligere økter → `retrospectives/` Les alltid `ai-clone/INDEX.md` og `business/INDEX.md` ved starten av en økt. ``` 6. ### Start Claude Code og sjekk Åpne agenten. Spør: «fortell meg om produktet mitt og målgruppen min». Hvis den svarer ut fra mappekonteksten, fungerer det. Hvis den finner på ting, sjekk at mappene ligger ved siden av prosjektet, at filene har riktige navn, og at rutingen i `CLAUDE.md` er formulert presist. Etter dette vokser den ekstra hjernen etter to prinsipper. For det første: Hver gang agenten gjør en feil, legger du til en regel. Etter 3-4 uker vil `ai-clone/feedback/` inneholde 15-20 regelfiler, og agenten slutter å gjøre de vanligste feilene. For det andre: Hver gang du tar en forretningsbeslutning, skriver du den ned i `business/`. Hvis du setter opp prisen, legger du til et notat i `business/products/pricing.md` med datoen og årsaken. Hvis du endrer posisjonering, legger du til et notat i `business/company/about.md`. Om seks måneder vil du ha et arkiv som husker «hvorfor».
Ledetekst: Klar ledetekst for en kveldsoppdatering av den ekstra hjernen ``` Vi har gjort en betydelig mengde arbeid sammen denne uken. Analyser alle kodeendringene fra denne uken, alle innleveringene vi gjorde. Hvilken verdifull informasjon fra dette bør ligge i business/ - skriv den inn i de riktige filene med wikilenker til tilstøtende filer, slik at konteksten ikke går tapt. Hvis det finnes beslutninger i koden som jeg ikke har forklart, spør meg hvorfor og noter årsaken i den riktige filen med datoen. Ikke gjenta det som allerede er åpenbart fra koden. Ta bare med det agenten ikke ville visst i neste økt uten business/. ```
## Hva nå - Skills, Subagents og context engineering
Hovedpoeng En ekstra hjerne pluss CLAUDE.md er grunnlaget. Oppå dette legger du Skills (prosedyrekunnskap som lastes inn ved behov basert på oppgavebeskrivelsen), Subagents (isolerte Claude-forekomster med egne kontekstvinduer for krevende oppgaver) og context engineering (styring av hva som havner i vinduet). Dette er de tre øverste etasjene. De fungerer ikke uten grunnmuren - agenten har ingenting å lese.
Når den ekstra hjernen er på plass, finnes det tre verktøy til som Anthropic beskriver som tre ulike nivåer av kontekstoptimalisering. **Skills** er prosedyrekunnskap. Hvis du har en arbeidsflyt du gjentar (skrive en læringsveiledning, sette sammen et Telegram-innlegg, revidere et nettsted), kan du kode den i en `SKILL.md`-fil med en oppgavebeskrivelse. I starten av en økt skanner Claude navnene og beskrivelsene av skills og laster bare inn dem som passer til den aktuelle oppgaven. Dette sparer tokener og holder fokuset. **Subagents** er isolerte forekomster av Claude med egne kontekstvinduer. Start en subagent på en krevende oppgave (les 30 filer og sett sammen et sammendrag), så jobber den i sitt eget vindu og returnerer bare resultatet. Hovedvinduet ditt forblir ledig. Anthropic skriver:
Spesialiserte subagenter kan løse avgrensede oppgaver i rene kontekstvinduer. [...] Hver subagent kan utforske i stor bredde og bruke titusenvis av tokener eller mer, men returnerer bare et komprimert og destillert sammendrag av arbeidet sitt (ofte 1 000-2 000 tokener).
— Anthropic, anthropic.com/engineering/effective-context-engineering-for-ai-agents
**Context engineering** handler om å styre hva som i det hele tatt havner i vinduet. Anthropic kalte det en grunnleggende ferdighet for arbeid med agenter i 2025, ett nivå over prompt engineering. Prompt engineering handler om å velge ordlyd. Context engineering handler om å velge filer, ruter, skills og subagenter. En ekstra hjerne er den første byggesteinen i context engineering. Uten en slik hjerne leser Skills et tomt rom, Subagents har ingen steder å gå, og agentens vindu fylles med tilfeldig informasjon. Med en ekstra hjerne begynner alle tre verktøyene å fungere. **Neste steg.** Opprett to mapper ved siden av prosjektet: `business/` og `ai-clone/`. Legg til en `INDEX.md` i hver med 5 linjer som fungerer som kart. Legg til fire rutelinjer i `CLAUDE.md`. Om én time har du et fungerende rammeverk for en ekstra hjerne. Bygg det deretter ut ved å følge regelen «etter hver agentfeil legger du til én linje i `ai-clone/feedback/`». Jeg forklarer hele CLAUDE.md-malen du skal bruke for å rute til den ekstra hjernen i veiledningen [Slik setter du opp CLAUDE.md riktig](https://ailoot.ai/blog/nb/claude-md-template/).
### Kilder - [Claude Code Memory-dokumentasjon](https://code.claude.com/docs/en/memory) - offisielt minnehierarki for Claude Code fra Anthropic - [Beste praksis for Claude Code](https://code.claude.com/docs/en/best-practices) - offisielle råd for arbeid med CLAUDE.md - [Effektiv kontekstutforming for AI-agenter](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) - Anthropic Engineering, en forklaring av context rot, oppmerksomhetsbudsjett og just-in-time-kontekst - [Skills forklart](https://claude.com/blog/skills-explained) - Anthropic-blogg: forskjellen mellom Skills, Memory, Subagents og MCP
Fortsett å utforske Ailoot på [ailoot.ai](https://ailoot.ai/). ## Spørsmål om denne veiledningen: En ekstra hjerne i Claude Code: Slik bygger du strukturen på én time ### Holder en annen Git-gren forretningskonteksten privat? Nei. En gren er del av samme repository, og filene kan deles med repositoryets objekter og historikk. Bruk et separat kontrollert privat lager eller en bevisst ignorert lokal mappe med sikkerhetskopi. Ignorering sletter ikke eksisterende sporet historikk. ### Hvordan finner agenten privat kontekst utenfor koderepositoryet? Gi en eksplisitt peker og bare tilgangstillatelsene oppgaven trenger. Behold en kort indeks som viser til relevant dokument, og verifiser at agenten kan lese den tillatte filen. Et privat sted uten ruting gir ikke kontekst automatisk. ## Ailoot · Selskapet og dets prosjektportefølje Ailoot bygger på etablert driftserfaring, en stor kundebase, stabil tjeneste og løpende KPI-kontroll. Selskapet og dets prosjektportefølje: millioner av kunder; månedlig salg for milliarder. Ailoot bruker denne driftserfaringen til API-tilgang til AI-funksjoner i kundenes produkter, agenter, applikasjoner og automatiseringer.