Tre arkitekturer for agent-hukommelse — og hvorfor Trail valgte Kompilér

Karpathy, Tan og Liu starter alle fra samme diagnose — din agent er en fremsøger, ikke en tænker. De ender med tre forskellige arkitekturer: hent (RAG), kompilér (LLM Wiki), og handl (Fat Skills / GBrain). Trail valgte Kompilér, bevidst. Det er hvad vi accepterer, og det vi tror konvergerer.

Den fælles diagnose, alle bliver ved med at genopdage

Da Andrej Karpathy postede sin "LLM Wiki"-gist i april 2026, ramte den fem tusind stjerner på få dage. Da Garry Tan open-sourcede GBrain nogle uger senere, læste den samme skare begge dele. De to systemer går i modsatte tekniske retninger, men de starter fra den samme klage: en agent, der holder en million tokens i kontekst, genlæser stadig sit kildemateriale fra bunden hver session — den akkumulerer aldrig, lærer aldrig, forbinder aldrig gårsdagens indsigt med dagens spørgsmål. Karpathy formulerede det skarpt — RAG genlæser de samme bøger til hver eksamen, uden nogensinde reelt at lære stoffet. Den Luxembourg-baserede finans-praktiker Yanli Liu, der kortlagde feltet for AI Advances i slutningen af april, opsummerede diagnosen renest:

det er en fremsøger, ikke en tænker

Det er konsensus, og har været konsensus i mindst to år. Det interessante er, hvad folk gør ved det.

Liu, der observerede feltet efter både Karpathy og Tan havde shippet deres respektive mønstre, identificerede tre distinkte arkitektoniske svar. RAG er hente-mønstret, modent og allestedsnærværende. LLM Wiki er kompilér-mønstret — et offentligt artefakt i april, men reelt meget ældre: Niklas Luhmann kørte en papirbaseret udgave af det fra 1952 til 1998. GBrain er handle-mønstret, en autonom skill-harness bygget omkring fireogtyve cron-jobs og sytten tusind sammenlænkede sider. De tre svar konkurrerer ikke med hinanden. De løser forskellige udgaver af samme problem, og spørgsmålet om hvilket man skal bruge, viser sig at afhænge af et spørgsmål, de fleste teams springer over: hvad er din agents job?

Trail valgte én af disse tre. Vi valgte den bevidst. Denne artikel er forklaringen på hvilken, hvorfor, og hvad vi ved, vi giver afkald på.

Tre mønstre, tre afvejninger

Hente-mønstret er vejen med mindst modstand, og den vej de fleste produktionsteams tager. Du embedder dine dokumenter til vektorer, gemmer dem i Pinecone, Chroma eller pgvector, og når en forespørgsel kommer, finder du de nærmeste bidder, sætter dem ind i prompten, og lader modellen generere. Arkitekturen er moden. Frameworkene har standardiseret sig omkring den. Du kan shippe en fungerende intern videns-assistent på en lang weekend.

Det, du ikke kan med hente-mønstret, er at bygge ekspertise, der akkumuleres. Liu gennemgår tre svigt-mønstre — chunking, gen-udledning, passivitet — og de to første er strukturelle, ikke noget bedre værktøj kan fikse. Når en tredive-siders teknisk specifikation splittes op i fem-hundrede-tokens fragmenter, lander den bid, der nævner et compliance-krav, og den bid, der forklarer hvorfor kravet findes, i forskellige vektorer. Fremsøgeren finder den ene og misser den anden. Din agent giver et teknisk korrekt, men farligt ufuldstændigt svar. Det er ikke et chunk-størrelse-tuning-problem. Det er hvad retrieval er.

Kompilér-mønstret angriber det direkte ved at flytte syntese-arbejdet fra forespørgselstidspunkt til skrivetidspunkt. Du læser en ny kilde gennem en sprogmodel, der allerede har indlæst den eksisterende wiki. Modellen skriver resumé-sider, opdaterer berørte entitets-profiler, arkiverer krydsreferencer, flager modsigelser, og lander resultatet tilbage som holdbar markdown. Fremtidige forespørgsler henter ikke rå bidder — de læser mod det kompilerede produkt. Lius levende formulering for, hvad der sker ved indtag, er, at ét nyt dokument rører ved ti til femten wiki-sider — hver eneste en smule rigere end i går. Det er den arkitektur, Karpathy beskrev, og den vi byggede Trail omkring.

Handle-mønstret går endnu videre. Garry Tans GBrain behandler ikke viden som noget, der skal forespørges, men noget der skal handles på. Enogtyve cron-jobs kører i baggrunden — scraper Hacker News hver sjette time, beriger nyligt nævnte entiteter dagligt, udkaster et digest hver mandag morgen. Hvert job er en "fat skill", en markdown-fil, der erklærer sine triggers, sine værktøjer, sine skrive-mål, og om den må mutere hjernen. Intelligensen bor i skills'ene, ikke i harnesset. Agenten er vågen, mens du sover.

Det, der adskiller de tre, er ikke hvilken der er korrekt — de er alle korrekte for de problemer, de blev designet til at løse — men hvilket problem, du har. Hent håndterer to hundrede tusind dokumenter, der ændrer sig dagligt; det håndterer ikke akkumulerende ekspertise. Kompilér håndterer tusind kilder af dyb domæneviden; det håndterer ikke en million Confluence-sider, og det handler ikke på det, det ved. Handl håndterer autonome workflows for én magtbruger; det kræver måneders teknisk investering og et niveau af systemforståelse, de fleste videnarbejdere ikke har.

Hvorfor Trail valgte Kompilér

Argumentet for kompilér, for vores specifikke kunder og vores specifikke positionering, lyder sådan her.

De problemer, Trail adresserer, er ikke søgeproblemer. De er akkumuleringsproblemer. En zoneterapeut med femogtyve års klinisk materiale vil have, at systemet er klogere om hendes praksis ved hendes hundrede spørgsmål, end det var ved hendes første. En solo-grundlægger, der bygger en vidensbase af kundeinterviews, vil have, at sporet af Neuroner akkumuleres til noget tættere end summen af samtalerne. Et research-konsulenthus, der indtager to hundrede regulatoriske dokumenter, vil have, at den tredje sag opdaterer det, der blev lært af de to første — ikke erstatter det.

I alle tre tilfælde sættes loftet af dybden af krydsreference, ikke af korpussets bredde. De fleste af disse kunder vil aldrig have ti tusind kildedokumenter, endsige to hundrede tusind. De vil have et par hundrede til et par tusind, hver især omhyggeligt udvalgt, og de vil vende tilbage til samme videnbase i årevis. Det er det regime, hvor kompilér-mønstret vinder afgjort. Det er også det regime, hvor rent hente-baseret RAG stille underpræsterer: det skalerer uden besvær, men agenten bliver aldrig klogere. Det hundrede spørgsmål er ikke bedre end det første, fordi intet nogensinde blev konsolideret.

Vores afvejning, accepteret eksplicit, er, at vi ikke prøver at være det rigtige værktøj til den halvmillion-siders Confluence-migrering. Det er et hente-problem. Har du det, kør RAG. Vi prøver at være det rigtige værktøj til det to-hundrede-kilders domænekorpus, hvor hver kilde tæller, og hver forbindelse mellem dem er værdifuld. Der er en reel grænse et sted omkring fem tusind Neuroner pr. videnbase, hvor ren markdown-navigation begynder at knirke; vi tror, vi kan skubbe det loft betragteligt med FTS5 i dag, og et vektor-retrieval-lag når data kræver det. Liu gør samme pointe — ved hundrede tusind kilder er LLM Wiki-mønstret ubrugeligt uden at tilføje et retrieval-lag ovenpå, hvilket så begynder at ligne RAG igen. Vi er enige. Konvergensen er reel, og Trails design forudsætter den.

Vores anden afvejning, også accepteret eksplicit, er, at kompilér-mønstret er passivt. Systemet ved ting. Det gør, i dag, ikke ting. Det vil ikke stille og roligt flage, at et nyt klinisk paper modsiger en stående protokol. Det vil ikke selv udkaste et mandags-digest af sidste uges indtagne materiale. Vi har en planlagt feature til det — internt kalder vi det Trail Routines, brugerforfattede cron-udløste workflows, der læser mod videnbasen og udsender kandidater tilbage til kurateringskøen — men det er en planlagt feature, ikke en shippet en. Vi udskyder den, fordi vi tror, fundamentet skal være knivskarpt for én betalende kunde, før handlingslaget bliver nyttigt frem for farligt.

Hvad der forbliver det samme, når skalaen ændrer sig

Den udgave af dette argument, der går galt, er den stammebaserede. Kompilér er den rigtige arkitektur, hent er død, handl er fremtiden. Det er ikke, hvad vi tror. Lius afsluttende tese, som vi er enige i, er, at de tre mønstre konvergerer. Et produktionsklart videnlag i 2026 vil til sidst kombinere alle tre. Retrieval i bunden til at håndtere den skala, korpusset til sidst når. Kompilér i midten til den syntese, retrieval ikke kan producere. Handling i toppen til de workflows, der opererer på det kompilerede materiale. Trails design forudsætter den konvergens og er bevidst bygget som mellemlaget.

Hvad det betyder i praksis, er, at Trail ikke prøver at være agent-platformen. Vi prøver at være den holdbare, kompilerede hukommelse, agent-platformen læser fra. Vores videnbaser eksponeres til MCP-klienter som en førsteklasses læse-grænseflade — peg en hvilken som helst agent på Neuron-sporet, og sporet bliver den agents institutionelle hukommelse. Et fremtidigt GBrain-lignende harness, der kører oven på Trail, ville kalde vores kompilerede Neuroner i stedet for at genudlede den samme forståelse ved hver forespørgsel. Kompilerings-omkostningen er allerede betalt, én gang, ved indtag. Agenten læser mod det arbejde resten af sin levetid.

Det samme gælder ved retrieval-grænsen. Efterhånden som individuelle videnbaser bliver store nok til at begynde at belaste markdown-og-FTS5-navigation, vil vi tilføje et vektorlag, der bakker de samme Neuroner op. Retrieval bliver en performance-optimering under den eksisterende kompilér-model, ikke en erstatning for den. Agenten læser stadig kompilerede Neuroner; retrieval-laget hjælper bare med at indsnævre kandidatsættet først.

Det er væddemålet. De tre arkitekturer ligner rivaler i 2026, fordi de blev foreslået isoleret — Karpathys gist, Tans repo, det etablerede RAG-økosystem — og diskursen omkring dem har rammesat valget som et nulsumsspil. Vi tror, dikotomien er midlertidig. På samme måde som databaser udviklede sig fra "vælg SQL eller NoSQL" til hybrid-lagre, der håndterer begge, vil agent-hukommelse udvikle sig fra "vælg hent, kompilér eller handl" til en lagdelt stak, hvor hvert lag gør én ting godt. Trails valg er at være det holdbare, styrede, skema-bundne lag i midten, som de andre læser fra og skriver tilbage til.

Beslutnings-rammeværket, gentaget

Spørgsmålet Liu stiller til sidst i sit stykke, er det rigtige for ethvert team, der tænker over det her. Hvad er din agents job? Hvis jobbet er at finde svar i et stort korpus, der ændrer sig dagligt, kør RAG og par det med en reranker; du vil dække det meste af, hvad virksomheds-videnassistenter bliver bedt om. Hvis jobbet er at operere autonomt på tilbagevendende workflows, budgettér måneder til teknik og byg skill-laget omhyggeligt; gevinsten er en agent, der gør, ikke bare svarer. Hvis jobbet er midt imellem — at bygge ekspertise, der skal akkumuleres over tid, hvor værdien ligger i forbindelserne mellem kilder frem for i noget enkelt dokument — det er det regime, hvor kompilér-mønstret tjener sin ret, og det er der, Trail lever.

De teams, der får det her galt, har en tendens til at falde tilbage på RAG, fordi det er nemmest at shippe, og lægger så mærke til, seks måneder inde, at deres agent aldrig blev klogere. Det er ikke et værktøjsproblem. Det er en kategori-fejlmatch. Hente-formede problemer er fine; kompilér-formede problemer er anderledes. At navngive forskellen på forhånd er det billigste stykke arkitekturarbejde, du kan lave.

Vi valgte Kompilér. Vi valgte den for en klasse af brugere, vi ved, hvordan vi betjener. Vi accepterer lofterne, og vi har en plan for dem. Vi tror ikke, Kompilér vinder overalt, og vi tror ikke, RAG er død. Vi tror, hver arkitektur er det rigtige svar på et forskelligt spørgsmål, og vi tror, at det at kende det spørgsmål, din agent faktisk prøver at besvare, betyder mere end hvilken arkitektur der lige nu er moderne.

Start med jobbet. Arkitekturen følger efter.