Research

Niklas Luhmann's Zettelkasten Has Been Waiting Seventy Years for the LLM

Luhmann produced 90,000 cards and 500-plus books with a method that has worked for seven decades — but most of his time went into bookkeeping that does not directly contribute to thinking. The LLM Wiki pattern is the first plausible automation of exactly that bookkeeping. Trail is what it looks like as hosted infrastructure.

A method that worked, and a tax that almost nobody could pay

Niklas Luhmann was a German sociologist who, between 1952 and his death in 1998, wrote roughly 90,000 index cards and published more than 500 books and papers. He did this while holding a full professorship and raising a family. When asked how he managed the output, he gave the same answer for the rest of his career: he did not produce it. His Zettelkasten — his slip-box — produced it. He was, in his own description, a junior partner to his note system.

This is not the modesty it sounds like. Luhmann was making a precise architectural claim. The system he built was a knowledge infrastructure that compiled, cross-referenced, and accumulated for decades, and the books were a downstream artefact of that compilation rather than the primary work. He read, he distilled, he filed — and the distilled material, threaded together by hand into a network of cards, became dense enough that querying it produced book-length output more or less by exposure.

If the method worked this well, an obvious question follows. Why did almost nobody else manage to run it? The answer, the same answer for seventy years, is that the bookkeeping cost was prohibitive. Luhmann paid the tax personally because he had no choice. The 1950s could not automate any of it.

The shift in 2026 — and the reason this essay exists — is that the bookkeeping tax has finally come down to something a normal person can afford. The rest of this piece is about what that shift unlocks, why Luhmann's architecture survived intact under a completely different technological regime, and what we built on top of it.

What Luhmann's slip-box actually was

The slip-box was three layers, kept physically distinct.

The first layer was reading notes — passages from books and papers that Luhmann had read closely, transcribed onto a slip with a citation, and dropped into a holding box. These were never the final material. They were raw input.

The second layer was the permanent cards. When Luhmann had digested a reading note enough to extract a single specific idea — usually a sentence or a short paragraph — he wrote it as a permanent card in his own words and assigned it a number. The numbering was the trick. Cards were not filed under topics. They were filed wherever there was an open slot in the existing sequence, which meant that the number itself encoded a position in a network rather than a position in a hierarchy. A new card on, say, the role of trust in differentiated societies might be filed as 21/3d27c, meaning it sat next to card 21/3d27 (which was something close in spirit) and would have its own children later.

The third layer was the index. Luhmann maintained a separate set of cards that listed entry points by keyword. When he wanted to follow a thread, he did not look up a topic and read everything filed under it; he looked up a keyword in the index, found two or three numbered cards that served as entry points, and began walking the network from there. The number sequence guided him outward through associations. Topical organisation, on his account, would have killed the system within a few years; networks of association could keep growing for decades.

This description should sound familiar to anyone who has read Andrej Karpathy's LLM Wiki gist. Karpathy proposes a raw/ folder of sources you do not modify, a wiki/ folder of compiled markdown pages the LLM maintains, and a schema/ document that tells the system how to behave. He proposes an index.md for entry-point navigation and a log.md for chronological audit. Two thinkers, seven decades apart, reached the same architecture from opposite directions — Luhmann from the constraints of paper, Karpathy from the constraints of language models. The agreement is not coincidence. It is the shape the problem keeps converging on when the goal is sustained accumulation rather than fast retrieval.

The Chinese cognitive scientist Shuyi Wang made this convergence explicit in a long Medium essay published in April 2026. In spirit, LLM Wiki and Luhmann's Zettelkasten are close cousins; in practice, LLM Wiki takes over all the time-consuming, non-thinking parts of Luhmann's method. Wang's framing is the cleanest version of what is going on. Karpathy did not invent a new method in 2026. He proposed the first plausible mechanism for running an existing seventy-year-old method without paying Luhmann's tax.

The four convergences

Wang lays out four points where the slip-box and the LLM Wiki are saying the same thing in different vocabularies. They are worth stating cleanly because they explain why the architecture did not have to be redesigned for the LLM era — it just had to find a different labourer for the middle layer.

First, both reject synthesis-from-scratch at query time. Luhmann did not trust himself, when it came time to write a book, to dig up every supporting argument from memory; that is why he accumulated 90,000 cards. Karpathy says the same thing in the gist: the language model is rediscovering knowledge from scratch on every question, and there is no accumulation. Decades apart, both are addressing the same complaint. On-the-fly synthesis is unreliable; you have to accumulate first.

Second, both are compilation-first rather than retrieval-first. When Luhmann wrote a permanent card, he had already thought an idea through — the permanent card is itself a compiled product. Karpathy's wiki pages are also compiled products: at ingest time, the LLM has already cross-integrated the new source with existing pages. Both push the most cognitively demanding work forward to write time rather than leaving it for query time. This is the same shift that distinguishes a domain expert from a research assistant who Googles every question.

Third, both reject hierarchy. Luhmann argued explicitly that as soon as you systematically classify cards by topic, you are locking in an ordering decades in advance, and the growth of knowledge cannot be locked in like that. His Zettelkasten was therefore not divided into chapters by subject; it used numbers and links to weave the cards into a network. Karpathy's wiki is the same. Concept pages, entity pages, and comparison pages are connected by bidirectional links, with no folder hierarchy. When the German scholar Johannes F. K. Schmidt later studied Luhmann's papers, he found that Luhmann's actual navigation mechanism was not the numbering itself — it was the index pages that served as entry points. That genuinely echoes Karpathy's design of letting index.md carry the entry-point navigation.

Fourth, both treat the system as a conversation partner. Luhmann, in his 1981 paper Kommunikation mit Zettelkästen, called his slip-box a communication partner. His point was that once a card collection reaches a certain volume, it starts surfacing connections you did not see coming — the system starts teaching you back. Karpathy does not use that word, but he repeatedly emphasises that the wiki is a persistent artefact that compounds the more you feed it. The two of them are saying the same thing.

SAME THREE LAYERS, SEVENTY YEARS APART NIKLAS LUHMANN, 1952–1998 90,000 cards · two slip-boxes · by hand Reading notes books, papers, his own drafts Permanent cards (Zettel) numbered, linked, networked Index cards + rules handwritten conventions, entry points same role same role same role TRAIL, 2026 an LLM holds the pen for the bookkeeping Sources PDFs, articles, transcripts, web clips Neurons cross-referenced markdown, version-traced _schema.md + index declarative rules, machine-readable The architecture is identical. What changed in 2026 is who holds the pen for the middle layer. Luhmann did it himself for 46 years. Trail does it for you while you read.
Three layers, on each side. Luhmann's slip-boxes had reading notes, permanent cards, and index cards with rules. Trail has sources, Neurons, and a machine-readable schema. The architecture survived seventy years; only the labour shifted.

The tax that finally came down

The convergences explain why the architecture survived. They do not explain why almost nobody followed Luhmann.

The answer is the bookkeeping. Luhmann himself, in his published reflections on method, said that the vast majority of his time went into wrestling with the Zettelkasten rather than into writing. The time sink was not the reading or the drafting — it was dealing with the slip-box. Specifically, hand-writing numbers, building cross-references, updating hub cards, maintaining keyword indexes, and deciding where each new card belonged.

Every time he added a card, he might have to walk back through several older cards to add new links by hand. The labour of 90,000 cards, sustained over decades, is exactly what you would expect: enormous, mechanical, and almost completely uncreative. Saying that bookkeeping and thinking can be cleanly separated is a simplification — when Luhmann decided that two ideas were related and should be linked, that decision was itself a small act of thinking. But there is a large core of the work — number maintenance, index updates, cross-reference completion, keeping the catalogue consistent with the cards — that is purely mechanical. None of it directly contributes to thinking, but if you do not do it, you cannot find your way back to anything you saved.

In a 1981 essay, the philosopher and Zettelkasten student Sönke Ahrens argued that this mechanical layer is the reason traditional knowledge-management practices fail at scale: the cost of opening the library and finding what you need eventually exceeds the cost of just searching the open web again. Most people give up. Luhmann did not give up because he had no other option. He was working in a generation where the labour could not be delegated to a machine. That is no longer true.

WHERE LUHMANN'S TIME ACTUALLY WENT 80% — BOOKKEEPING what Luhmann did by hand for 30 years · hand-write card numbers · build cross-references · update hub cards · maintain keyword indexes · decide where each card belongs · walk back through old cards to add links → this is what the LLM takes over 20% — THINKING the part that can't be outsourced · what to read · what to keep · which side to believe · whether an idea deserves a card · value judgments stays with you Luhmann was a grinder because he had no choice. The 1950s could not automate any of the left column. Anyone willing to do the right column can now run his method. That is the shift.
The 80/20 split that defined Luhmann's working life. Most of his time went into mechanical maintenance of the slip-box — the column an LLM can now take over. The smaller column, the part that produces actual ideas, stays with the human.

The paradigm shift of the LLM Wiki is precisely the handing of this mechanical labour to a language model. Wang's formulation is exact: every time the workflow ingests a new piece of material, it updates the cross-references on a dozen related pages in one go, appends entries to index.md, writes audit records into log.md, and assigns stable frontmatter to new concepts. Link-maintenance work that used to take Luhmann hours holed up in his study can now be compressed into a very short window. The bookkeeping moves off the human's plate.

What does not move is the 20 per cent that actually generates thinking. Before promoting a fleeting thought into a permanent note — the moment Luhmann was famously most disciplined about — you have to make a value judgment. Is this idea worth keeping? Is it sharp enough? How does it connect to the network you already have? That judgment is bound up with your research direction, your taste, your sense of which questions matter. It cannot be outsourced.

This is the dividing line. The LLM Wiki is not a button that thinks for you. It is the first system that lets you run Luhmann's method without being Luhmann.

What Trail is, in this lineage

Trail is the hosted infrastructure version of that pattern. Same three layers — sources, Neurons, schema — same compile-first principle, same insistence that the wiki is something that compounds rather than something that is rebuilt on each query. The differences are operational, and they exist because Luhmann's pattern, scaled to teams and institutions, runs into problems he never had to face.

Three differences matter most.

First, Trail is multi-tenant from the architecture upward. Luhmann had one slip-box. He owned it, he maintained it, and his successors at Bielefeld inherited the boxes themselves rather than the running system. A clinical practice, a research lab, or a consulting firm cannot work that way. Trail's tenant model means each organisation runs its own compiled corpus on isolated infrastructure, with curators on the team rather than a single individual carrying the burden.

Second, Trail's schema is a first-class machine-readable artefact rather than an implicit set of conventions. Luhmann had rules for how he wrote permanent cards, but the rules lived in his head and in his practice. Trail's _schema.md files declare the rules explicitly: which Neuron types can exist, which sections are required, what frontmatter must be present, which sources are immutable. When the LLM compiles, it compiles against the schema. When the schema changes, the compiled corpus is re-evaluated. This is the difference between method-as-discipline and method-as-infrastructure.

Third, Trail enforces a curation queue between the compiler and the compiled corpus. Every change the LLM proposes — every new Neuron, every update, every cross-reference — passes through an explicit gate before it lands. Some categories of change are auto-approved by policy when confidence is high and provenance is clean. Others wait for a human to decide. The result is that the persistent corpus does not silently absorb LLM hallucinations; what is in there has been vetted, either by policy or by a person. Luhmann's gate was his own attention. For an organisation, that gate has to be explicit, configurable, and auditable.

These differences are operational rather than architectural. The architecture is still Luhmann's. We just built it as infrastructure other people can run, with the LLM holding the pen for the bookkeeping that Luhmann did by hand for forty-six years.

Why this matters now

The argument for compile-time knowledge infrastructure has been made before. Vannevar Bush proposed it in 1945 with the memex. Doug Engelbart built the first working pieces in the 1960s. Ted Nelson named the missing link as hypertext. The Web that emerged in the 1990s implemented Bush's surface idea but discarded the compilation layer. Luhmann ran the only complete instance of the design from 1952 to 1998, and he ran it on paper because he had to.

What changed in 2026 is not the architecture. The architecture has been correct for eighty years. What changed is that the labour required to run it has finally come down to something an organisation can afford. Karpathy named the pattern publicly. Wang explained why it works. Mark Chen showed that an individual can stand up two domain wikis in an afternoon. Sanne Andersen, an acupuncturist with twenty-five years of clinical material, can now operate a system that previously required a Niklas Luhmann.

The organisations winning long-term with AI for knowledge work are the ones that have noticed this. Not because they read Luhmann or Bush. Because the cost-of-bookkeeping tax has finally collapsed below the threshold where institutional knowledge can compound rather than dissipate. The methods worked all along. Only the maintenance held them back.

We think the architecture matters more than the model. We think Luhmann's design from 1952 is still the right one. And we think the time has finally arrived to run it as something other than the personal heroism of one disciplined sociologist.


Further reading

← MORE FROM RESEARCH