Tre arkitekturer for agenthukommelse — og hvorfor Trail valgte Compile

Den fælles diagnose, som alle fortsat genopdager

Da Andrej Karpathy i april 2026 offentliggjorde sin "LLM Wiki"-gist, nåede den fem tusinde stjerner på få dage. Da Garry Tan nogle uger senere open-sourced GBrain, læste den samme kreds begge systemer. De to systemer tager modsatte ingeniørmæssige retninger, men de starter med en identisk klage: En agent, der holder en million tokens i kontekst, genlæser stadig sit kildemateriale fra bunden hver session, akkumulerer aldrig, lærer aldrig, forbinder aldrig i går indsigt med dagens spørgsmål. Karpathy formulerede det skarpt — RAG genlæser de samme bøger til hver eksamen, uden nogensinde at lære materialet. Den luxembourg-baserede finanspraktiker Yanli Liu, der i slutningen af april undersøgte feltet for AI Advances, opsummerede diagnosen mest præcist: det er en henter, ikke en tænker.

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

Liu, der observerede feltet efter at både Karpathy og Tan havde lanceret deres respektive mønstre, identificerede tre forskellige arkitektoniske reaktioner. RAG er hent-mønsteret, modent og udbredt. LLM Wiki er kompiler-mønsteret, en offentlig artefakt i april, men faktisk meget ældre — Niklas Luhmann kørte en papirbaseret udgave af det fra 1952 til 1998. GBrain er agér-mønsteret, en autonom færdighedsramme bygget omkring fireogtyve cron-jobs og sytten tusinde indbyrdes forbundne sider. De tre reaktioner konkurrerer ikke. De løser forskellige versioner af det samme problem, og spørgsmålet om, hvilken man skal bruge, viser sig at afhænge af et spørgsmål, de fleste hold springer over: Hvad er din agents opgave?

Trail valgte en af disse tre. Vi valgte det med vilje. Denne artikel er forklaringen på hvilken, hvorfor, og hvad vi ved, vi går glip af.

Tre mønstre, tre afvejninger

{{svg:three-architectures-comparison}}

Hent-mønsteret er den letteste vej og den vej, de fleste produktionshold tager. Du integrerer dine dokumenter i vektorer, gemmer dem i Pinecone, Chroma eller pgvector, og når et spørgsmål kommer ind, finder du de nærmeste stumper, indsætter dem i prompten og lader modellen generere. Arkitekturen er moden. Rammeværkerne er standardiserede omkring den. Du kan levere en fungerende intern vidensassistent på en lang weekend.

Det, du ikke kan gøre med hent, er at opbygge ekspertise, der akkumuleres. Liu gennemgår tre fejltilstande — opsplitning, genopdagelse, passivitet — og de to første er strukturelle snarere end løselige med bedre værktøjer. Når en tredive sider lang teknisk specifikation deles op i femhundrede-tokens fragmenter, lander den stump, der nævner en overholdelseskrav, og den stump, der forklarer hvorfor kravet eksisterer, i forskellige vektorer. Henteren finder den ene og misser den anden. Din agent giver et teknisk korrekt, men farligt ufuldstændigt svar. Dette er ikke et problem med stumpstørrelse. Det er, hvad hent er.

Kompiler-mønsteret angriber dette direkte ved at flytte syntesearbejdet fra spørgsmålstid til skriftid. Du læser en ny kilde gennem en sprogmodel, der allerede har indlæst den eksisterende wiki. Modellen skriver opsummeringssider, opdaterer berørte entitetsprofiler, arkiverer krydshenvisninger, markerer modsætninger og lander resultatet tilbage som varigt markdown. Fremtidige spørgsmål henter ikke rå stumper; de læser mod det kompilerede produkt. Lius levende ramme for, hvad der sker ved indlæsning, er, at et enkelt nyt dokument berører ti til femten wiki-sider — hver eneste af dem lidt rigere end i går. Dette er den arkitektur, Karpathy beskrev, og den, vi byggede Trail omkring.

Ager-mønsteret går endnu videre. Garry Tans GBrain behandler viden ikke som en ting, der skal spørges til, men som en ting, der skal ageres på. Enogtyve cron-jobs kører i baggrunden — scrapes Hacker News hver sjette time, beriger nyligt nævnte enheder dagligt, udarbejder et ugentligt resumé hver mandag morgen. Hvert job er en "tyk færdighed", en markdown-fil, der erklærer sine udløsere, sine værktøjer, sine skrive-mål og om det må ændre hjernen. Intelligensen lever i færdighederne, ikke i rammen. 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 er designet til at løse — men hvilket problem du har. Hent håndterer to hundrede tusinde dokumenter, der ændrer sig dagligt; det håndterer ikke akkumuleret ekspertise. Kompiler håndterer tusind kilder med dyb faglig viden; det håndterer ikke en million Confluence-sider, og det agerer ikke på det, det ved. Ager håndterer autonome arbejdsgange for en enkelt magtanvender; det kræver måneders ingeniørmæssig investering og et systemforståelsesniveau, som de fleste vidensarbejdere ikke har.

Hvorfor Trail valgte Compile

Argumentet for kompiler, for vores specifikke lejere og vores specifikke positionering, lyder således.

De problemer, Trail løser, er ikke søgeproblemer. De er akkumuleringsproblemer. En akupunktør med femogtyve års klinisk materiale ønsker, at systemet skal være klogere på hendes praksis ved hendes hundredede spørgsmål end ved det første. En solostifter, der bygger en vidensbase af kundesamtaler, ønsker, at sporet af Neuroner skal akkumuleres til noget tættere end summen af samtalerne. En forskningskonsulent, der indlæser to hundrede reguleringsdokumenter, ønsker, at det tredje dokument opdaterer, hvad der blev lært af de to første, i stedet for at erstatte det.

I alle tre tilfælde er loftet sat af dybden af krydshenvisninger, ikke af korpusets bredde. De fleste af disse lejere vil aldrig have ti tusinde kildedokumenter, endsige to hundrede tusinde. De vil have et par hundrede til et par tusinde, hver omhyggeligt udvalgt, og de vil vende tilbage til den samme KB i årevis. Dette er det regime, hvor kompiler-mønsteret vinder afgørende. Det er også det regime, hvor hent-baseret RAG stille og roligt underpræsterer: det skalerer ubesværet, men agenten bliver aldrig klogere. Det hundredede spørgsmål er ikke bedre end det første, fordi intet nogensinde blev konsolideret.

Vores afvejning, accepteret eksplicit, er, at vi ikke forsøger at være det rigtige værktøj til en halv million-siders Confluence-migration. Det er et hent-problem. Hvis du har det, kør RAG. Vi forsøger at være det rigtige værktøj til det to hundrede kilders faglige korpus, hvor hver kilde betyder noget, og hver forbindelse mellem dem er værdifuld. Der er en reel grænse et sted omkring fem tusinde Neuroner per vidensbase, hvor ren markdown-navigation begynder at knirke; vi tror, vi kan skubbe dette loft betydeligt med FTS5 i dag og et vektorretrieval-lag, når dataene kræver det. Liu gør det samme punkt — ved hundrede tusinde kilder er LLM Wiki-mønsteret ubrugeligt uden at tilføje et retrieval-lag ovenpå, hvilket derefter begynder at ligne RAG igen. Vi er enige. Konvergensen er reel, og Trails design antager den.

Vores anden afvejning, også accepteret eksplicit, er, at kompiler-mønsteret er passivt. Systemet ved ting. Det gør ikke, ting, i dag. Det vil ikke stille flag, at et nyt klinisk studie modsiger en eksisterende protokol. Det vil ikke udarbejde et mandagsresumé af sidste uges indlæsninger på egen hånd. Vi har en planlagt funktion til dette — internt kalder vi det Trail Routines, brugeroprettede cron-udløste arbejdsgange, der læser mod KB’en og sender kandidater tilbage til kurateringskøen — men det er en planlagt funktion, ikke en udsendt en. Vi udskyder det, fordi vi mener, at fundamentet skal være solidt for én betalende lejer, før aktionslaget bliver nyttigt snarere end farligt.

Hvad forbliver det samme, når skalaen ændres

{{svg:trail-as-compile-layer}}

Den version af dette argument, der går galt, er den tribale. Compile er den rigtige arkitektur, hent er død, agér er fremtiden. Det er ikke, hvad vi tror. Lius afsluttende tese, som vi er enige i, er, at de tre mønstre er under konvergens. Et produktionsklart videnslag i 2026 vil til sidst kombinere alle tre. Retrieval i bunden til at håndtere den skala, korpuset til sidst når. Kompiler i midten til syntesen, som retrieval ikke kan producere. Aktion øverst til de arbejdsgange, der opererer på det kompilerede materiale. Trails design antager denne konvergens og er bevidst bygget som mellemlaget.

Hvad dette betyder i praksis er, at Trail ikke forsøger at være agentplatformen. Vi forsøger at være den vedvarende kompilerede hukommelse, som agentplatformen læser fra. Vores KB’er eksponeres til MCP-klienter som et førsteklasses læsegrænseflade — peg enhver agent på Neuron-sporet, og sporet bliver agentens institutionshukommelse. En fremtidig GBrain-lignende ramme, der kører oven på Trail, ville kalde vores kompilerede Neuroner i stedet for at genopdage den samme forståelse ved hvert spørgsmål. Kompileringsomkostningen er allerede betalt én gang ved indlæsning. Agenten læser mod dette arbejde resten af dens levetid.

Det samme gælder ved retrieval-grænsefladen. Når individuelle KB’er vokser store nok til at begynde at anstrenge markdown- og FTS5-navigation, vil vi tilføje et vektorretrieval-lag, der understøtter de samme Neuroner. Retrieval bliver en ydeevneoptimering under det eksisterende kompileringsmodel snarere end en erstatning for det. Agenten læser stadig kompilerede Neuroner; retrieval-laget hjælper blot med at indsnævre kandidatsættet først.

Dette er vores indsats. 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 rammet valget som et nulsumsspørgsmål. Vi tror, at dikotomien er midlertidig. På samme måde som databaser udviklede sig fra "vælg SQL eller NoSQL" til hybride lagre, der håndterer begge dele, vil agenthukommelse udvikle sig fra "vælg hent, kompiler eller agér" til en lagdelt stak, hvor hvert lag gør én ting godt. Trails valg er at være det varige, styrede, skemabundne lag i midten, som de andre læser fra og skriver tilbage til.

Beslutningsrammen, genfortalt

Det spørgsmål, Liu stiller i slutningen af sin artikel, er det rigtige for ethvert hold, der tænker over dette. Hvad er din agents opgave? Hvis opgaven 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 virksomhedens vidensassistenter bliver bedt om at gøre. Hvis opgaven er at operere autonomt på arbejdsgange, der gentager sig, budgetter måneder til ingeniørarbejde og byg færdighedslaget omhyggeligt; belønningen er en agent, der gør, ikke bare svarer. Hvis opgaven ligger imellem — at opbygge ekspertise, der bør akkumulere over tid, hvor værdien ligger i forbindelserne mellem kilder snarere end i et enkelt dokument — så er det her, kompiler-mønsteret tjener sit formål, og det er her, Trail befinder sig.

De hold, der får dette forkert, tenderer til at falde tilbage på RAG, fordi det er lettest at levere, og derefter opdager de seks måneder senere, at deres agent aldrig er blevet klogere. Det er ikke et værktøjsproblem. Det er en kategorimismatch. Hent-formede problemer er fine; kompiler-formede problemer er anderledes. At navngive forskellen på forhånd er det billigste arkitekturarbejde, du kan udføre.

Vi valgte Compile. Vi valgte det til en klasse af brugere, vi ved, hvordan vi skal betjene. Vi accepterer lofterne og har en plan for dem. Vi tror ikke, Compile vinder overalt, og vi tror ikke, RAG er død. Vi tror, hver arkitektur er det rigtige svar på et andet spørgsmål, og vi tror, at det at vide, hvilket spørgsmål din agent rent faktisk forsøger at besvare, betyder mere end, hvilken arkitektur der i øjeblikket er på mode.

Start med opgaven. Arkitekturen følger.

Yderligere læsning

• Yanli Liu, RAG, LLM Wiki eller GBrain? Hvordan din agents hukommelse ændrer alt, AI Advances på Medium, april 2026 — den trearkitektoniske undersøgelse, som denne artikel bygger på.
• Andrej Karpathy, LLM Wiki GitHub-gist, april 2026 — det oprindelige kompiler-mønster-manifest.
• Garry Tan, GBrain-repository på GitHub — referenceimplementeringen af Fat Skills.
• For Trails specifikke linje fra Vannevar Bush til Niklas Luhmann til i dag, se Niklas Luhmanns Zettelkasten har ventet i halvfjerds år på LLM Wiki’en.