Blog / AI Teknikken
Company brain: 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 (7 afsnit)
- Fire teams byggede det samme uden at tale sammen
- En vidensbase svarer. En company brain handler.
- De fire builders bag company brain-arkitekturen
- Den femte builder: en dansk en-mands-portefølje
- Routinglaget: RESOLVER
- Skills: kapabiliteter, ikke skabeloner
- Skriv-tilbage og lint: det der holder den i live
- 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 (kortlagt af Alex Lockey, 2026): 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 (Lockey, 2026), 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: markdown i git (ikke en database), en instruktionsfil i roden (CLAUDE.md eller AGENTS.md), et RESOLVER-routinglag, skills som callable enheder, en skriv-tilbage-disciplin — og en ugentlig lint der holder det ærligt.
Det er ikke meget. Det er filer, regler og en vane. Men summen er en organisation der er arkitekteret 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."
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 content-platform, et AI-kursusudbud, et hudplejebrand, en jobansøgningsservice, et par produkter under udvikling, et politisk projekt. På papiret er det kaos. I praksis er det den perfekte test af mønstret, for hvis en company brain kan holde sammen på syv 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.
Routinglaget: RESOLVER
Det første jeg byggede var RESOLVER.md på roden. Én tabel med én række pr. domæne: »blog og SEO« → content-platformen. »hudpleje og Shopify« → brandet. »LinkedIn outreach« → outreach-motoren. »selskabsfakta og CVR« → company-filen i hjernen. Plus en tabel for opgavetyper og en for viden.
Pointen er ikke tabellen. Pointen er at agenten nu router før den gætter. Uden RESOLVER spørger en AI sig selv »hvor hører det her mon hjemme?« og rammer ved siden af alt for ofte. Med RESOLVER slår den op. Garry Tans regel, som jeg overtog ordret: enhver ny skill skal tilføje en RESOLVER-række samtidig. Ellers er kapabiliteten der, men kan ikke nås — en dark capability, en hånd hjernen har, men har glemt den har.
Skills: kapabiliteter, ikke skabeloner
Så de første skills. Ikke prompts jeg copy-paster — filer der beskriver en arbejdsgang agenten kan køre. Tre til at starte med: én der producerer en cross-project status fra hukommelsen og dashboardet. Én der filer et nyttigt svar tilbage på det rigtige sted. Og én der kører den ugentlige audit.
Det er Ramps indsigt i miniature: jeg lærer hjernen noget ved at skrive en skill, og næste gang opgaven dukker op, er den allerede løst. Viden der før forsvandt med samtalen, bliver til en kapabilitet der bliver. Og fordi hver skill peger tilbage gennem RESOLVER, ved hjernen ikke bare hvad den kan — den ved hvornår den skal bruge det. Det er forskellen på et værktøjsskab og en kollega: et skab venter på at du finder det rigtige værktøj, en kollega rækker dig det.
Skriv-tilbage og lint: det der holder den i live
To regler binder det sammen. Den ene: hvert svar der vil komme igen, files tilbage — gennem et capture-filter 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.
Den anden: en ugentlig lint. Den tjekker at hver skill har en RESOLVER-række, at hver række peger på en fil der faktisk findes, at intet er drevet væk fra virkeligheden. Det er Garry Tans »check-resolvable« — den systematiske jagt på de mørke kapabiliteter. Uden den rådner enhver vidensstruktur stille, mens alle tror den er sund.
Hvorfor den kontrol er afgørende, så jeg sort på hvidt i de cases jeg trækker på: et stort dansk konsulenthus står som skoleeksemplet. Konsulenterne udkastede klientleverancer med AI uden nogen review-proces overhovedet. Det blev en klient der fandt fejlen: en konkurrence-analyse 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. Linten 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-proces-problem, og en company brain uden lint 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 content-platformens automatik — en blog-generator læste den direkte for at undgå at hallucinere kilder. Hvis jeg bare flyttede mappen op i hjernen, ville pipelinen 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 en ugentlig lint. 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, skills som callable enheder, en skriv-tilbage-disciplin og en ugentlig lint. Du køber den ikke — du bygger substratet oven på det du har, og lader agenten arbejde på det. Byg vidensbasen først; lag 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.