Blog / AI Teknikken
AI Company Brain med Claude: fra vidensbase til en hjerne der handler
En company brain er ikke en vidensbase — det er en eksekverbar hjerne, AI-agenter handler ud fra. Her er mønstret fire teams fandt, og hvordan jeg byggede min.
Indhold (8 afsnit)
- Fire teams byggede det samme uden at tale sammen
- En vidensbase svarer. En company brain handler.
- De fire builders bag company brain-arkitekturen
- Anatomien: de seks lag, ét ad gangen
- Lag 01 — Markdown i git: substratet
- Lag 02 — Instruktionsfilen: CLAUDE.md
- Lag 03 — RESOLVER: omstillingsbordet
- Lag 04 — Skills: kørbare kapabiliteter
- Lag 05 — Skriv-tilbage: capture-filteret
- Lag 06 — Sundhedstjekket: det, der holder den ærlig
- Den femte builder: en dansk en-mands-portefølje
- Det jeg byggede først: RESOLVER (lag 03)
- De første tre skills (lag 04)
- Skriv-tilbage og sundhedstjek (lag 05-06)
- Den lavpraktiske detalje der reddede det
- Hvad det faktisk kræver af dig
- FAQ
Fire teams byggede det samme uden at tale sammen
Mens du ikke kiggede, skete der noget der sjældent sker i teknologi: fire vidt forskellige teams byggede den præcis samme ting, fra hver sin vinkel, uden at koordinere. Andrej Karpathy. Garry Tan og YC. Et team hos DoorDash. Og Ramp. Ingen af dem kaldte det det samme, men arkitekturen var identisk — og YC har nu sat navn på den i deres 2026 Request for Startups: en company brain.
Konvergens på den måde er et signal. Når uafhængige folk lander på samme design, er det ikke en trend — det er en form der har fundet sit problem.
Og her er det, der gjorde det konkret for mig: jeg indså at jeg allerede havde bygget det meste af den, uden at vide den havde et navn. Den her artikel er hvad mønstret er, hvorfor det ikke er det samme som en vidensbase — og hvordan jeg byggede den femte version af det på tværs af min egen portefølje på en enkelt aften.
En vidensbase svarer. En company brain handler.
Lad os få den vigtigste skelnen på plads med det samme, for den er let at misse.
En AI-vidensbase er noget du slår op i. Du fylder en inbox, kompilerer til en wiki, og spørger den. Den er passiv — en hukommelse du konsulterer. Den er fantastisk, og du bør bygge den. Men den er ét niveau under det her.
En company brain er noget en AI-agent handler ud fra. Som YC formulerer det: et system der trækker viden ud af fragmenterede kilder, strukturerer den, holder den aktuel — og gør den til en eksekverbar skills-fil for AI. Forskellen er ordet eksekverbar. Filerne er ikke kun til at læse. De er instruktioner og arbejdsgange agenten kan køre.
En vidensbase er en hukommelse. En company brain er en hukommelse plus et sæt hænder — og et kort over hvem der gør hvad.
Det er også derfor svaret på »kan jeg ikke bare bruge Notion?« er nej. Notion, Confluence, en RAG-bot oven på dine dokumenter — de kan alle svare på et spørgsmål. Men de kan ikke udføre opgaven, fordi de ikke er bygget til at en agent kan eksekvere dem. Du køber ikke en company brain. Du bygger et substrat af filer, og lader agenten arbejde oven på det. Står I midt i en bredere AI-strategi og -implementering, er company brain'en det operationelle lag under strategien — stedet hvor beslutninger bliver til noget agenter kan udføre, ikke bare noget der står på en slide.
De fire builders bag company brain-arkitekturen
Det smukke ved konvergensen er at hver builder bidrog med ét lag af den samme bygning:
| Builder | Hvad de tilføjede |
|---|---|
| Andrej Karpathy | Det oprindelige mønster: en wiki af markdown-filer, hvor hvert svar files tilbage. Den kompounderende loop. |
| Garry Tan / YC | Disciplinen: RESOLVER.md — et org-chart for agenter — og en ugentlig audit der finder de kapabiliteter ingen kan nå. |
| DoorDash-teamet | Brugbarheden: ikke-tekniske folk bidrog dagligt. Rolle-specifikke indgange slår perfekt dokumentation. |
| Ramp | Skalaen: 350+ skills, hvor det at skrive en skill er onboardingen. Man lærer systemet ved at lære det noget. |
Læg lagene oven på hinanden, og du har hele mønstret. Seks lag — og hvis du aldrig har set en company brain indefra, ser navnene nok kryptiske ud lige nu. Det er meningen; de bliver konkrete om lidt. Her er hele figuren først, så du har et kort at holde resten op imod:
De fire nederste lag er filer og regler. De to øverste er vaner. Men summen er en organisation der er struktureret omkring intelligens i stedet for hierarki — præcis det skift Salim Ismail beskriver i exponential organizations: "Organizations need to be architected around intelligence, not around hierarchy."
Resten af det her afsnit tager ét lag ad gangen: hvad det er, hvorfor det virker sammen med en AI som Claude, hvad du vinder ved at have det (og taber ved at lade være) — og hvordan filen faktisk ser ud, med indhold. Du behøver ingen teknisk baggrund. Tre begreber er nok at have med:
- Markdown er bare tekst med et par enkle tegn til overskrifter og lister — det du skriver i Slack eller Notion, uden et tungt tekstbehandlingsprogram imellem. AI'er læser og skriver det flydende.
- Git er et versionsstyret arkiv: en mappe, der husker hver eneste ændring, så intet går tabt, og flere kan arbejde i den uden at træde på hinanden. Tænk "Google Docs-historik", men for en hel mappe af filer.
- En agent er en AI, der ikke bare svarer, men kan gøre noget — læse dine filer, køre en arbejdsgang, skrive et resultat tilbage. Claude og Claude Code er den, jeg bruger; derfor står "med Claude" i titlen. Mønstret virker med enhver agent, der kan læse en mappe og skrive i den.
Anatomien: de seks lag, ét ad gangen
Lag 01 — Markdown i git: substratet
Hvad det er. Fundamentet under det hele — og det er forbløffende lavteknologisk: en mappe med almindelige tekstfiler på din computer. Ikke en database, ikke en platform, ikke et SaaS-produkt med login. Bare filer. To ord skal du kende, og begge er enklere end de lyder.
Markdown er tekst med nogle få tastetegn til struktur — en # foran en overskrift, en - foran et punkt, stjerner om noget der skal være fedt. Det er alt. Sådan ser en fil ud indeni:
# Selskab: Nordvik Handel ApS
CVR: 12345678. Moms afregnes kvartalsvis.
## Tone over for kunder
- Kort og konkret. Svar inden for én arbejdsdag.
- Brug altid kundens navn i hilsenen.
Ingen skjult formatering, intet filformat som kun ét program kan åbne. Det kan læses lige godt af et menneske og af en maskine.
Git er et versionsarkiv lagt rundt om mappen. Det gør to ting, der betyder alt, når en AI får lov at skrive i dine filer: det gemmer hver eneste ændring, og det lader dig fortryde. Tænk "Fortryd"-knappen i Word — men for hele mappen, for altid, med en note om hvem der ændrede hvad og hvornår. Du behøver ikke kunne kommandolinjen; Claude Desktop eller Claude Code opretter og passer arkivet for dig. Du skal bare vide, hvad det giver dig.
Hvorfor det virker med Claude. Når du peger Claude på mappen, læser den filerne direkte som sin kontekst — der er ingen integration, intet plugin, ingen database der skal forbindes. Det er bare tekst, og tekst er præcis det, en sprogmodel er bygget til at forstå. Læg den samme viden i en database eller et SaaS-værktøj, og den sidder bag login og API: du kan ikke selv åbne den uden værktøjet, og agenten kan ikke handle på den uden en særlig integration. Som filer kan både du og agenten læse og skrive direkte — gratis, uden at en leverandør kan lukke for det, og stadig læsbart om ti år. Git er sikkerhedsnettet: agenten kan rette i en fil, du ser nøjagtig hvad der blev ændret, linje for linje, og kan rulle det tilbage med én kommando, hvis det var forkert. Det er dét, der gør det trygt at lade hjernen skrive selv — ikke kun læse. Substratet er med vilje kedeligt; det kedelige er det, der holder i årevis.
Sådan ser det ud. Læg de filer i én mappe, og du har substratet. Hele company brain'en er i sin kerne bare den her struktur:
min-virksomhed/
├── CLAUDE.md ← instruktionsfilen (lag 02)
├── RESOLVER.md ← routinglaget (lag 03)
├── skills/ ← kørbare kapabiliteter (lag 04)
│ ├── ugentlig-status.md
│ └── ugentligt-tjek.md
├── hukommelse/ ← skriv-tilbage havner her (lag 05)
│ └── journal.md
└── viden/ ← referencebank: cases, citater, frameworks
└── ...
Lag 02 — Instruktionsfilen: CLAUDE.md
Hvad det er. Én fil i roden, der fortæller agenten hvem du er, hvilke projekter der findes, og hvor tingene ligger. På engelsk hedder den CLAUDE.md (eller AGENTS.md, hvis du vil være værktøjsneutral). Det er det første, en agent læser.
Hvorfor det virker med Claude. Claude Code indlæser automatisk en CLAUDE.md fra rodmappen ved hver session — det er en indbygget konvention, ikke noget du skal bede om. Filen bliver agentens onboarding-memo: uden den starter hver samtale fra nul, og du bruger de første ti minutter på at gentage dine projekter, din tone og dine regler. Med den ligger konteksten der og bliver læst, før arbejdet går i gang — agenten ved allerede, hvad hvert projekt hedder, og hvor en opgave hører hjemme.
Sådan ser det ud. Kort, konkret, vedligeholdt:
# CLAUDE.md — koordinator for firmaet
Du arbejder for ejeren. Match sproget i beskeden (dansk/engelsk).
Vær kort og konkret.
## Projekter
1. Webshop — ordrer, lager, kundesupport.
2. Konsulentydelser — tilbud, leverancer, fakturering.
## Regler
- Skriv kun til hukommelsen, når jeg beder om det.
- Slå op i RESOLVER.md, før du gætter på, hvor noget hører hjemme.
Lag 03 — RESOLVER: omstillingsbordet
Hvad det er. Et routing-index. "Routing" betyder bare at sende en opgave det rigtige sted hen — som et gammeldags omstillingsbord, der stiller opkaldet videre til rette afdeling. RESOLVER er én tabel: én række pr. opgavetype, der peger på, hvilken skill, fil eller del af organisationen, der løser den. Garry Tan kalder den et org-chart for agenter.
Hvorfor det virker med Claude. En agent er enormt god til at følge en eksplicit instruks og elendig til at gætte, hvor noget "nok hører hjemme". Uden en opslagstabel spørger den sig selv "hvor hører det her mon hjemme?" og rammer forkert alt for ofte; med den slår den op, før den handler, i stedet for at improvisere. Reglen, jeg overtog ordret fra Tan: enhver ny skill skal tilføje en RESOLVER-række samtidig. Ellers findes kapabiliteten, men kan ikke nås — en dark capability, en hånd hjernen har, men har glemt, den har. Sidegevinst: de manglende kapabiliteter bliver synlige, fordi de tomme rækker stikker ud.
Sådan ser det ud. En markdown-tabel, ikke mere:
# RESOLVER.md
| Opgave handler om... | → gå til |
|--------------------------|----------------------------------|
| ordrer og lager | webshop-mappen |
| kundesupport | skills/support.md |
| tilbud og salg | skills/tilbud.md |
| selskabsfakta, CVR, moms | viden/oekonomi.md |
| ugentlig status | skills/ugentlig-status.md |
Lag 04 — Skills: kørbare kapabiliteter
Hvad det er. En skill er en kørbar kapabilitet — en fil, der beskriver, hvordan en tilbagevendende opgave udføres, præcist nok til at gentages. "Kørbar" (på engelsk callable) betyder, at agenten kan kalde den og udføre den, ikke bare læse om den. Det er ikke en prompt, du copy-paster ind i en chat. Det er en arbejdsgang, agenten selv kan køre.
Hvorfor det virker med Claude. Claude Code kan indlæse sådan en skill-fil og følge dens trin som en opskrift. Uden skills genopfinder du (og agenten) den samme arbejdsgang hver gang, lidt forskelligt og lidt ringere; med dem gør du det godt én gang, skriver det ned og høster det igen og igen. Viden, der før forsvandt, når samtalen lukkede, bliver til en kapabilitet, der bliver liggende. Det er Ramps indsigt i miniature: du lærer hjernen noget ved at skrive en skill, og næste gang opgaven dukker op, er den allerede løst. Forskellen er et værktøjsskab vs. en kollega: et skab venter på, at du finder det rigtige værktøj; en kollega rækker dig det.
Sådan ser det ud. En lille fil med ét formål og nogle trin:
# skill: ugentlig-status
Formål: Saml en status på tværs af firmaets dele på 5 minutter.
Brug: når ejeren spørger "hvor står vi?" — eller mandag morgen.
## Trin
1. Læs hukommelse/journal.md (sidste 7 dage).
2. Hent ugens nøgletal (salg, ordrer, åbne supportsager).
3. For hvert område: én linje — fremdrift, blokering, næste skridt.
4. Slut med ÉN ting, der haster mest.
Lag 05 — Skriv-tilbage: capture-filteret
Hvad det er. Vanen, der lukker loopet: hvert svar, der vil komme igen, files tilbage i hjernen, så den bliver rigere for hver opgave. Ikke alt — det ville drukne signalet i støj. Derfor et capture-filter: ét spørgsmål, hvert svar skal bestå, før det gemmes — vil mit fremtidige jeg, eller en kollega, gerne finde det her om tre måneder? Beslutninger og begrundelser ind; hot takes og halvfærdige tanker ud.
Hvorfor det virker med Claude. En agent kan ikke bare læse dine filer; den kan også skrive i dem. Det er det, der gør en company brain til mere end et arkiv: agenten lægger selv beslutningen, begrundelsen eller den nye case tilbage på det rigtige sted — og næste gang er den en del af konteksten. Uden den vane lækker din bedste tænkning ud med hver lukket fane; med den kompounderer den, og den kompounderende vidensloop kører af sig selv.
Sådan ser det ud. En dateret note, ikke en formular:
## 2026-06-14 — Beslutning: hjernen sidder over projekterne
Valgte at lægge company brain'en i porteføljens rod, ikke inde i
ét projekt. Hvorfor: en projekt-hjerne kan ikke se på tværs.
Konsekvens: hvert projekt blev en under-hjerne, der loades ved behov.
Lag 06 — Sundhedstjekket: det, der holder den ærlig
Hvad det er. Et ugentligt, automatisk eftersyn af hjernen. (I softwareverdenen kalder man sådan en automatisk kontrol en linter — et værktøj, der maskinelt gennemgår dit arbejde for fejl og skævheder. Du behøver ikke ordet; du skal bare kende vanen.) Tjekket gennemgår strukturen og fanger det, der er skredet.
Hvorfor det virker med Claude. Selve tjekket kan være en skill (lag 04), som agenten kører på en fast ugedag: den kontrollerer, at hver skill har en RESOLVER-række, at hver række peger på en fil, der faktisk findes, og at intet er drevet væk fra virkeligheden. Maskinen er god til præcis den slags udtømmende, kedelige kontrol, et menneske springer over. Uden den rådner enhver vidensstruktur stille, mens alle tror, den er sund — links peger ud i ingenting, skills refererer filer, der er flyttet; med den fanges forfaldet, mens det er småt. Det er Garry Tans "check-resolvable": den systematiske jagt på de mørke kapabiliteter, før de bliver til fejl hos en kunde.
Sådan ser det ud. Tjekket er en skill; her er, hvad den spytter ud:
UGENTLIGT SUNDHEDSTJEK — 2026-06-14
✓ 12 skills, 12 RESOLVER-rækker — match
✗ RESOLVER-række "tilbud" → skills/tilbud.md FINDES IKKE
✗ viden/oekonomi.md ikke rørt i 9 uger — forældet?
→ 1 dark capability at rette, 1 fil at gennemgå
Den femte builder: en dansk en-mands-portefølje
Her bliver det konkret. Jeg driver ikke ét firma — jeg driver en portefølje under samme selskab: en håndfuld forretninger på tværs af content, undervisning, e-handel og produkter under udvikling. På papiret er det kaos. I praksis er det den perfekte test af mønstret, for hvis en company brain kan holde sammen på en stribe forretninger styret af én person, kan den holde sammen på hvad som helst.
Da jeg læste mønstret igennem, talte jeg efter hvad jeg allerede havde. Det var mere end jeg troede:
- En koordinator-instruktion i roden (min
CLAUDE.md) der allerede kendte alle projekterne. - En narrativ hukommelse — en natlig journal der dag for dag noterer hvad der rykkede på tværs af forretningerne.
- Et metrics-dashboard der samler tallene fra fire af dem, trend-først.
- En referencebank af frameworks, kilder, citater og cases jeg trækker på når jeg skriver.
Fire lag. Det jeg manglede var de to der gør en samling filer til en hjerne: routinglaget og det eksekverbare skills-lag. Plus disciplinen til at holde det rent.
Det jeg byggede først: RESOLVER (lag 03)
Det første jeg lavede var RESOLVER.md på roden — tabellen fra figurens lag 03, fyldt med mine egne domæner: ét område pr. forretning, hvor hver række peger på den mappe, skill eller fil, der ejer opgaven. Plus en tabel for opgavetyper og en for viden.
Effekten var til at mærke med det samme: agenten router før den gætter. Og jeg holder Garry Tans regel hellig — ny skill, ny række, samtidig — så ingen kapabilitet ender som en dark capability, ingen kan nå.
De første tre skills (lag 04)
Ikke tredive — tre. Én der producerer en tværgående status fra hukommelsen og dashboardet. Én der filer et nyttigt svar tilbage på det rigtige sted. Og én der kører det ugentlige sundhedstjek. Det er de opgaver, jeg gentager hver uge, og fordi hver skill peger tilbage gennem RESOLVER, ved hjernen ikke bare hvad den kan — men hvornår den skal bruge det.
Skriv-tilbage og sundhedstjek (lag 05-06)
To vaner binder det sammen. Skriv-tilbage gennem capture-filteret på ét spørgsmål: vil mit fremtidige jeg, eller en kollega, gerne finde det her om tre måneder? Beslutninger og begrundelser ind. Hot takes og halvfærdige tanker ud.
Og så det ugentlige sundhedstjek — som ikke er til pynt. Hvorfor det er afgørende, så jeg sort på hvidt i en af de cases, jeg trækker på: et stort dansk konsulenthus står som skoleeksemplet. Konsulenterne brugte AI til at skrive udkast til klientleverancer uden nogen form for review undervejs. Det blev en klient, der fandt fejlen: en konkurrentanalyse, hvor tre ud af otte virksomheder var beskrevet med forkerte tal. AI'en havde hallucineret, og ingen havde verificeret. Casen rammer lige ned i forskellen mellem en vidensbase og en company brain — for når en hjerne kan handle, skal den også kunne kontrolleres. Sundhedstjekket er den kontrol: den systematiske jagt på det, der er drevet væk fra virkeligheden, før det når en kunde. Hallucinationer er ikke et teknisk problem. De er et review-problem — og en company brain uden sundhedstjek er bare et hurtigere sted at lave de samme fejl.
Den lavpraktiske detalje der reddede det
Én ting fortjener at blive nævnt, fordi den er hele forskellen på et build der virker og et der knækker noget.
Min referencebank var hardwired ind i en eksisterende automatik — en pipeline læste den direkte fra sin gamle placering. Hvis jeg bare flyttede mappen op i hjernen, ville den pipeline brække. Så jeg flyttede filerne op til deres nye kanoniske hjem og efterlod et symlink, hvor de før lå. Pipelinen følger linket og kører videre, uvidende om at noget er flyttet. Verificeret: den indlæser stadig sine sektioner, præcis som før.
Det er ikke en teknisk fodnote. Det er princippet: en company brain bygges oven på det du har, uden at rive det ned du allerede bruger. Forfatteren bag mønstret advarer mod præcis det modsatte — at flytte hurtigere end strukturen kan følge med. Byg substratet, bevar det der virker, og lad disciplinen vokse i takt med tilliden.
Hvad det faktisk kræver af dig
Hvis du vil bygge din egen — om det så er for dig selv eller for en organisation — er rækkefølgen den her:
- Byg vidensbasen først. Den er fundamentet. Hele opskriften ligger i byg-guiden — én mappe, en inbox, en ugentlig kompilering.
- Læg en instruktionsfil i roden.
CLAUDE.mdellerAGENTS.md: hvem er du, hvilke projekter findes, hvor ligger hvad. - Tilføj RESOLVER. Én række pr. opgave. Og hold reglen hellig: ny skill, ny række, samtidig.
- Skriv tre skills, ikke tredive. De tilbagevendende opgaver du gør hver uge.
- Indfør capture-filteret og et ugentligt sundhedstjek. Det er det der adskiller en levende hjerne fra et arkiv.
Og gør det ikke til et stort projekt. Tag én ikke-teknisk person ind tidligt, lad værdien rekruttere resten, og køb ikke et værktøj før du har bygget substratet. Værktøjerne er udskiftelige. Arkitekturen er ikke.
FAQ
Key takeaway: En company brain er ikke en vidensbase — det er en eksekverbar hjerne, AI-agenter handler ud fra. Fire uafhængige teams (Karpathy, Garry Tan/YC, DoorDash, Ramp) byggede den samme arkitektur: markdown i git, en instruktionsfil i roden, et RESOLVER-routinglag (et omstillingsbord, der sender opgaven det rigtige sted hen), skills som kørbare enheder, en skriv-tilbage-disciplin og et ugentligt sundhedstjek. Du køber den ikke — du bygger substratet oven på det du har, og lader agenten arbejde på det. Byg vidensbasen først; læg routinglaget og skills ovenpå, når din egen loop har bevist sig.
Ofte stillede spørgsmål
En vidensbase er noget, du slår op i — en company brain er noget, en AI-agent handler ud fra. Forskellen er eksekverbarhed: filerne er ikke kun til at læse, de er instruktioner og skills, agenten kan køre. Derfor dur Notion eller en RAG-bot ikke som company brain — de kan svare på spørgsmål, men ikke udføre opgaven.