EVOLVED, Second Edition: Your Digital Nervous System

Preface to the Second Edition

In late 2024 I watched an agent of mine read its way through a week of my notes, find the thread I had been failing to pull, and hand it back to me as a draft. It took ninety seconds. I had been chewing on the same thread for two months. That moment is what this edition is about.

The first edition of Evolved came out in 2023. It got some things right. The nervous-system metaphor held up. The framing of the human plus machine as a centaur, borrowed from Garry Kasparov's 1998 match in León, still describes the actual working pattern better than any other phrase I have found. And the recognition that something tectonic was already underway, that we had crossed a line and most people had not yet noticed, was correct. Boiling frog. Gradualism. The shift was real.

What the first edition could not yet say was the half of the story it most needed. 2023 was pre-agentic. The LLM section reads now like a recent surprise, because at the time of writing it was one. The protocol chapter promised more than it delivered. Module One was a placeholder. And the lineage that mattered most, the line from Niklas Luhmann's Zettelkasten through Sönke Ahrens's How to Take Smart Notes, through Tiago Forte's Building a Second Brain, through Andy Matuschak's evergreen notes, was named but not given the weight it deserved.

This edition is the book I meant to write.

The core argument is bigger now. A Digital Nervous System extends two human systems at the same time. It extends the peripheral nervous system, the layer of signals and sensing and reflex, which is the half the first edition described. And it extends the neocortex, the layer of reasoning and synthesis and retrieval, which is the half that was missing. The neocortex layer has a name in this book. I call it the Semantic Nervous System, the SNS, the part of the DNS that thinks.

This is what you become after second brains. A second brain stored your notes. A Zettelkasten linked them. A DNS reads, reasons, and acts on them while you sleep. It is the installable protocol the first edition pointed at and did not yet deliver.

A note on the world you are reading this in. It is 2026. Agents browse, write code, send mail, and orchestrate other agents on your behalf. You have probably already used one this week. The question is no longer whether you will. The question is whether you are operating these tools or being operated by them.

This book is a protocol for the first answer. Build the loop once. Run it forever. Let us begin.

Chapter 1: Introduction

You have evolved.

More specifically, your nervous system has evolved to adapt to a digitally enhanced life. Most people have not yet noticed. The shift is the kind the Boiling Frog Paradox describes, the kind where the heat rises slowly enough that the change feels like the new normal instead of a transformation. Gradualism is the word for this in evolutionary biology, the slow accumulation of small adjustments that, given enough time, becomes a new species. The same pattern shows up in personal growth and in societies. Small steps, then more steps, then one day you look back and you are somewhere else entirely.

What has happened to humans over the last few decades does not feel like gradualism if you measure it on the scale of evolution. On that scale it is tectonic. Generations of cognitive offloading have been compressed into a single working lifetime. The phone in your pocket. The notes in your cloud. The model in your browser that finishes the sentence you started. These are not accessories. They are extensions of you, and your nervous system has already begun to treat them that way.

We humans have two long-standing nervous systems. The central nervous system, the brain and the spinal cord, is the one most people picture when they hear the word. The peripheral nervous system is the network of nerves that runs through everything else, the limbs, the organs, the skin, the gut. The PNS connects the CNS to the rest of the body. It carries signals in. It carries signals out. It has worked this way for a very long time, since before we were human at all.

Now there is a third. A Digital Nervous System. Not Domain Name Service, though the acronym collision is unavoidable and I have stopped fighting it. A Digital Nervous System is the layer that connects you to the digital world the way your PNS connects you to your body. It senses. It signals. It acts on your behalf when you have set it up to do so.

The first edition of this book described one half of this third nervous system. The half that handles signals. Sensing, alerting, capturing, routing, automating the small reflexive work that does not need your conscious attention. That half is real and it is essential. It is also incomplete.

The other half is the neocortex extension. The neocortex is the part of your brain that does the slow work, the reasoning, the synthesis, the retrieval, the thinking about things. A DNS extends this half too. It reads your notes. It links concepts you did not know were linked. It drafts the thing you were going to draft, in your voice, from your sources, while you are doing something else. This is the half the first edition gestured at and did not fully deliver. This edition delivers it. I call this functional layer of the DNS the Semantic Nervous System, the SNS. The DNS is the whole. The SNS is the part of the whole that thinks.

There is a lineage behind this. Three names matter most, in order. Niklas Luhmann started it in the 1950s with a wooden card index he called a Zettelkasten. By the end of his life he had built roughly 90,000 numbered cards cross-linked to each other, and he had written 70 books and more than 400 papers in collaboration with that box. He treated the box as a thinking partner. Tiago Forte made it personal. Building a Second Brain, published in June 2022, gave a generation of knowledge workers a method, CODE, and a folder system, PARA, and a permission slip to take their own notes seriously. The Digital Nervous System makes it active. Where Luhmann's box waited for him to open it, and where Forte's second brain waited for you to query it, a DNS reads itself. It runs. Agents move through the graph while you are asleep, and you wake up to the work they did.

This is no longer a forecast. It is May 2026 as I write this. You are almost certainly using at least one tool right now that acts on your behalf. Maybe a coding agent that opens pull requests. Maybe an inbox assistant that drafts replies. Maybe a research model that browses for you. The tools exist. The question is no longer whether they will arrive. The question is whether you are operating them, or whether they are operating you.

That distinction is what this book is about. Operating means you have a protocol. You know what gets captured, where it lands, how it is processed, which agents are allowed to touch it, and what they hand back to you. Being operated means a vendor decided those answers and you are living inside their defaults. The first option compounds. The second one drifts.

Here is what I am promising you. By the time you finish Module One, which lands in Chapter 8, you will have installed the first working loop of your own Digital Nervous System. Not a sketch. Not an aspiration. A loop. Capture in, processing through, an agent reading the result, and an output that lands somewhere you will see it tomorrow. From there the system grows. Chapter by chapter you add a layer. By the end of the book you have a thing that runs.

So. Humanity has evolved. The first generation that lived its entire adult life inside this transition is the one reading this sentence. You are not the same species your great-grandparents were, not functionally, not in the way you remember things or find things or decide things. Homo sapiens, yes, in the biological sense. Homo Digitalis in every other sense that matters.

Before we build the system, we need to talk about the working pattern that makes the system useful. We need to talk about chess, about a Russian grandmaster in 1998, and about the hybrid he discovered when he stopped trying to beat the machine and started working with it. We need to talk about centaurs.

Chapter 2: Roaming, Learning, Trusting

Roaming the Kentucky countryside under the stars with my best friend, for days at a time, ranging across farms and lakes and rivers and ponds. Daring each other to do, looking back now, dangerous things. Nobody told us not to.

Don't crawl into that cave in the ground. Don't walk across that lock system over the rapids thirty feet below. Don't climb that water tower. Don't play on your computer all night. None of it happened. We just did the thing, and then we did the next thing, and the adults who could have stopped us either trusted us or were not paying attention, and the difference between those two readings of the same situation is something I have been turning over ever since.

That place I came from was beautiful, and it was also, for me, a kind of prison. I had to get out. I had to leave. I did, at eighteen and a day, with no one's permission at all. I moved away from home and enrolled myself in school in the biggest city I knew. It was difficult. My school had not prepared me sufficiently. I had thought, in some background way, that I was training to take over the family business, banking, but that was not to be.

What I wanted was to do the thing I most wanted to do, which was to connect with incredible people doing incredible things and teach them everything I knew about how technology could empower them the way it had empowered me. That is still what I want. It is what this book is for.

When you are fourteen years old, generally speaking, you are not handed the keys to a truck and told see you when I see you. But that is exactly what my best friend's grandfather did one day in the Kentucky summer of 1986. We were told to go explore the farm. It was a large farm. We were out for two or three days as I remember it, until an incident taught us both about consequence.

With a bit of food and drink we struck out across the farm in a stick-shift manual transmission farm truck without a care in the world. Over those days we gazed at an unspoiled night sky. We built tree houses that fell down soon after. We chased and were chased by bulls and cows. We explored ponds. We found mysterious caves. That region of Kentucky is riddled with limestone caverns and is home to Mammoth Cave, one of the largest known and mapped cave systems in the world. One day we were driving too fast, of course, and there was a thing we did not see.

Remember those caves? Caves make sinkholes. Sinkholes are not always obvious at eye level.

We drove directly into one, deep enough that the truck rose up and then tipped down nose first and ended up basically vertical. It happened in slow motion. Any number of things came toward my face with strange clarity, including, for reasons I still cannot explain, a pair of Barbie shoes that must have been in the cab from someone else's earlier ride. It was not the crash that was the lesson. Don't crash into sinkholes. That part is easy.

The lesson was the walk back. Many miles, for a long time, with the dread of explaining that the truck was in a sinkhole and we had put it there, to the man who had trusted us with the keys in the first place. He didn't say much when we told him. He took the keys back. We never saw them again. We went out with a tractor to pull the truck out. It wasn't much worse for wear. Old farm trucks were built differently. But it stung to have betrayed that man's trust that way. I have never forgotten. I know it is part of who I have become.

Two things sit in that memory together. The first is the weight of trust given and then broken. Integrity matters. It matters in the moment even when practicing it costs you something, especially then. The second is the freedom itself. The freedom and the agency and the trust were just there, handed to us without question, because in that place at that time a fourteen-year-old was supposed to have them. That was transformative. I am not sure you can get that anywhere anymore. I am not sure I would let my own kids have it either, which is its own kind of loss.

When I decided to leave home at eighteen I had been planning, thinking, and laying the groundwork for at least a year, the entire senior year of high school. I rearranged my social structures. I distanced myself from friends and family in preparation for the journey. I cannot fully explain why I was so driven to get out of what, by every reasonable account, was a loving and supportive place. I just was. There was no bittersweetness. There was no tearful goodbye. The day after I graduated I drove myself and a few of my things to Louisville and rented a small apartment in a part of the city so unlike where I had grown up that I had no idea what was going on. None.

I ended up next door to someone I was pretty sure was a significant drug dealer. He gave me CDs of his favorite music, which of course I had never heard of. Bobby Brown was pretty exotic to me at the time, having grown up on hair metal and tortured rock ballads, with some Prince and bluegrass and show tunes mixed in, a different kind of eclectic. He never tried to sell me drugs. I cannot prove he was a dealer. It was almost certainly an exaggeration in my mind. Instead, we played tennis at the local park and he encouraged me to get out and see more of the city on my own. Nice guy. Not a drug dealer at all. The mind plays tricks when you are in strange situations.

In all honesty, I hurt a lot of people when I left home. I did not do it well. I was not capable of the empathy at eighteen that the situation deserved. Empathy still does not come entirely naturally to me. I know now, many years later, that leaving home, and then leaving Kentucky thirteen years after that, left wounds that I am not sure can fully scar over.

Academically, the schools I attended were insufficient for what came next. I have always had a deep capability with information technology, and I come from a highly entrepreneurial and teacher-influenced background. When I tried to enroll in Electrical Engineering at Speed Scientific Engineering School at the University of Louisville, intending to learn how to build microprocessors, I found out I was not even close to their admission standards. My grades were not good enough. I was way behind on math. And, honestly, I had been difficult enough with my teachers in middle and high school that an average performance and a quiet sort of I will learn what I want attitude was something any teacher could smell from a mile away. I eventually worked through all of that with some fine personal work, but I wish someone had told me sooner. Then again, it was hard to tell me much of anything for a long time. I am still stubborn. Just ask my wife.

In any event, I enrolled myself in supplementary summer school before the regular semester. I talked them into letting me prove I could catch up and keep up. So I spent the entire summer studying algebra, trigonometry, and pre-calculus. All of it stuff I should have already known.

Something else happened that same summer. I built my first IBM 386 compatible clone from parts I bought at a local store. I set up an account with a local dial-up internet provider called IGLOU. And over a PPP/SLIP connection on my dial-up modem, I logged into the World Wide Web when there were still more gopher sites than web sites.

I think I browsed the entire web that evening.

Honestly, it kind of sucked. Gopher was better still. But that was 1990, and it made me one of the first people in the world browsing the World Wide Web. The effect on me was profound. It dictated everything about my future, academically and professionally. The screen was a door. On the other side of it was a network that had no end, written and run by people I could not see and did not know, and it was already big enough that an evening's browsing felt like an accomplishment instead of an absurdity. By the next summer the absurdity would be obvious. The web doubled, and doubled again, and kept doubling, and the idea of finishing it became a joke I tell now to mark the year.

What I did not know that evening was that I had just met my first centaur partner. Not a machine that thought for me. A network that thought with me, if I knew how to ask. The truck-in-a-sinkhole lesson, about trust given and consequence earned, was already in me. The walk-back lesson, about the long road from a mistake to a repair, was in me too. What I picked up that night in front of a dial-up modem was the third piece. There is a partner out there, made of wires and protocols and other people's minds, and learning to work with it is a separate skill from learning to use it.

That is the skill this book is about. The pattern has a name. Garry Kasparov gave it to us in 1998. We are going to talk about him next.

Chapter 3: Being Centaur

In May 1997, Garry Kasparov sat across the board from a machine and lost. Deep Blue, IBM's purpose-built chess engine, took the rematch 3.5 to 2.5. The world champion, the man who had spent the 1980s casually dismantling every chess computer thrown at him, had been beaten in a six-game match by silicon. The headlines read like an obituary for human intelligence.

Kasparov did not write the obituary. He did something more interesting. He asked a different question.

A year later, in June 1998, he showed up in León, Spain, and played a match against Veselin Topalov. Both players had a computer at their side. Both players were allowed to consult it on every move. Kasparov called the format Advanced Chess. The match ended 3-3. The chess was, by Kasparov's own account, the strongest chess he had ever played. Not because the machine had taken over. Because the seam between his judgment and the machine's processing produced something neither one could produce alone.

He called the pairing a centaur. Half human. Half machine. One player.

What happened next is the part most people forget. Freestyle chess events, opened to anyone willing to bring whatever tools they wanted, started producing strange results. Sometimes the winning team was not the strongest grandmaster with the strongest engine. Sometimes it was a pair of amateurs running multiple machines and coordinating their outputs with a tight process. The takeaway was not "the computer wins." It was not "the human wins." It was this. The team with the best process between human and machine wins. The seam matters more than the raw horsepower on either side of it.

That is the centaur principle. It has nothing to do with chess.

The seam, not the parts

Centaur thinking is not about the human. It is not about the machine. It is about the line where one ends and the other begins, and what crosses that line in each direction.

The human brings judgment, taste, context, accountability, the ability to recognize when the situation has changed. The machine brings speed, breadth, memory, tireless pattern matching, the ability to consider a thousand options while you consider three. Neither side is the protagonist. The protagonist is the workflow that decides which questions go to which side, and what to do with the answers when they come back.

Most readers already know this in their bones, even if they have not named it. If you have used Cursor to write code, you have watched a centaur play. The AI proposes. You judge. The AI proposes again, sharper this time, because your judgment carried information back across the seam. If you have run an analyst through Claude or GPT for a piece of research, you have done the same thing. You asked, you read, you sharpened, you asked again. Each loop tightened the work. The output at the end was not the model's. It was not yours. It was the pair's.

The centaur is now the default

In 1998, the centaur was a novelty. A chess curiosity. Something Kasparov was trying to popularize against a chess world that was still mourning Deep Blue.

In 2026, the centaur is what knowledge work is. Engineers ship code through Cursor and Claude Code. Analysts run research through agentic tools that browse, retrieve, and summarize. Operators orchestrate small teams of agents that each handle a slice of a larger task. Lawyers, doctors, marketers, founders. The pairing is everywhere. Most people doing it have not given it a name. They are centaurs without knowing it.

This matters because the unnamed thing is the unmanaged thing.

Most centaur configurations today are running on improvisation. The human types something into a prompt box. The machine answers. The human copies the answer somewhere, edits it, sends it on, forgets where it came from. There is no graph. There is no memory between sessions. There is no agent that knows what you decided last Tuesday or what you are trying to do this quarter. The centaur is real, but it is feral. It works, but it does not compound.

The point of this book

What you are going to build in the chapters ahead turns the centaur from a clever pairing into a disciplined practice. The trick is to stop treating each prompt as a one-off, and start treating the whole arrangement, the notes, the agents, the retrieval, the memory, the decisions, as a single system you own.

I have been building these systems for years. I have built them at personal scale for myself. I have built them at company scale through fOS, the operational system I use with founder-operators. The structure is the same in both cases. A knowledge graph holds what matters. Agents read it, reason over it, and act on it. The human sits at the seam, deciding what the agents pursue and what comes back across the line for review.

That structure is what gives the centaur a spine.

Without it, you are still a centaur. You are just one running on raw improvisation, with no memory and no leverage. With it, every loop you run with a machine adds to a graph that the next loop can stand on. The work compounds.

The next chapter names the spine. It is the Digital Nervous System. The centaur depends on it the way your body depends on the wiring under your skin.

Chapter 4: To Lead or to Follow

Are you leading your nervous system, or is your nervous system leading you?

Open your phone. Watch what happens in the first ten seconds. If notifications pull your attention to whatever the app makers want you to see, you are following. If your tools surface the three things you decided last night actually matter today, you are leading. There is no middle ground. There is only who set the defaults.

A short refresher on the biology

Your nervous system has two halves. The central nervous system, your brain and spinal cord, integrates and decides. The peripheral nervous system, the nerves and ganglia running everywhere else, senses the world and moves your body through it. The senses feed in. The motor functions act out. The neocortex, the outer layer of the brain, handles the highest-order reasoning. Symbols, language, planning, abstraction. That is the wiring you were born with.

For most of human history, that wiring was the whole story. Then people started building external aids. A Rolodex held names. A Filofax held appointments. A wiki held what a team agreed on. Each of these extended memory. None of them extended thinking. They stored. They did not reason.

The third nervous system

The Digital Nervous System is the third one. The DNS.

It is the external system you build to extend the two you were born with. The peripheral side gets extended by agents that sense, signal, and act in the world on your behalf. They watch your inbox. They watch the calendar. They watch the markets, the metrics, the dashboards you care about. They reach in and do small things you would otherwise do yourself. That is the peripheral extension. Signals in, motor functions out.

The neocortex side gets extended by something newer. This is the part a Rolodex could never do. A wiki could never do it either. Even a well-built Zettelkasten could only get partway there. The new piece is reasoning over the graph. Not just retrieving notes. Not just linking them. Thinking about them. Synthesizing. Drawing implications. Proposing actions. That layer of the DNS is the Semantic Nervous System. The SNS.

The SNS is not a separate thing from the DNS. It is the part of the DNS that thinks. The DNS is the whole nervous system, nodes, edges, agents, interfaces, memory, and all. The SNS is the reasoning layer that runs across the graph. When you ask your system "what should I be working on today, given what I committed to this quarter and what came in this week," you are using the SNS. When an agent pushes a notification because a metric crossed a threshold, you are using the peripheral side. Same DNS. Different functions.

This is the distinction the first edition of this book muddled. I want to be plain about it now. DNS is the system. SNS is the layer of the system that reasons. Both terms will show up throughout the rest of the book, and they mean different things.

After second brains

There is a lineage here, and I want to name it before going further.

Niklas Luhmann started it. A German sociologist working with index cards from the 1950s until his death in 1998, he built a Zettelkasten of roughly 90,000 cards, each one numbered, each one cross-linked to others. From that system he produced 70 books and more than 400 papers. The Zettelkasten was the proof that a personal knowledge graph could outproduce a single mind.

Tiago Forte made the idea personal. His 2022 book Building a Second Brain gave knowledge workers the CODE method, capture, organize, distill, express, and the PARA system for filing it. He turned Luhmann's monk-like discipline into something the rest of us could actually do.

The DNS is what comes after. A second brain stored notes. A Zettelkasten linked them. A DNS adds agents that read, reason, and act over the graph in real time. The graph is no longer a passive archive you visit. It becomes an active layer that works alongside you, and sometimes ahead of you.

The reader's choice

This is where the chapter title comes back.

The defaults are designed by other people. App notifications, recommendation feeds, the inbox order your email client picked for you, the order in which your tools surface tasks. Each of those defaults is a small decision someone else made about where your attention should go. Live on defaults long enough and you are not the centaur anymore. You are the horse.

Designing your own DNS is the leader's path. You decide what the graph holds. You decide what the agents do. You decide which signals reach you and which ones the system handles on its own. You set the defaults that govern the rest of your attention. The work is real. The payoff is your own.

Most people will not do this. Most people will continue to follow whatever system the largest software companies have set for them. That is fine. They are the followers in the title of this chapter.

You picked up this book. You are deciding to lead.

The next chapter goes deep on the DNS itself. What it is made of. How the pieces fit. How to build one that compounds instead of one that decays.

Chapter 5: The Digital Nervous System

1. Two extensions, one system

Here is the thesis, stated cleanly so it can be argued with.

A Digital Nervous System is not one extension of the human. It is two. It extends the peripheral nervous system, the part of you that senses, signals, and acts in the world. It also extends the neocortex, the part of you that reasons, associates, and makes meaning out of what the senses bring in. Most personal knowledge systems built before this moment extended only one of those layers, and that is why they always felt incomplete.

Think about what came before. A spreadsheet extended a calculator. It made arithmetic faster, and at scale it made arithmetic possible, but it did not think about the numbers. A notebook extended memory. It held what your head could not, and a good one held it for decades, but it could not retrieve a single line on its own. Twitter, in its early years, extended the social signal stream. It was a nerve ending pointed at the public square. None of those tools reasoned over the rest of your information. None of them looked across your notebook and your spreadsheet and your inbox and said, here is what these three things mean together.

The DNS does that. That is the difference. It is a knowledge graph that holds your work, your reading, your writing, your decisions, and your context, and it has agents on top of that graph that can read, summarize, connect, and act. Sensing on one side. Semantic reasoning on the other. The two layers are not parallel. They feed each other. A sensor that captures a meeting transcript hands the transcript to an agent that links it to the relevant project notes. An agent that drafts a follow-up email is itself a kind of motor neuron, pushing a signal back out into the world.

I use a specific name for the semantic side of this. Semantic Nervous System, SNS. The DNS is the whole organism. The SNS is the layer that thinks. The earlier edition of this book used those words inconsistently, sometimes with typos that made the idea harder to see. I am locking the terminology here so the rest of the book has a clean foundation: DNS is the system, SNS is the reasoning layer inside it, knowledge graph is the underlying data structure, agents are the workers that read and act.

That naming matters because most readers arrive at this chapter holding an older mental model. They think they are building a second brain. They are not. A second brain stores notes. A Zettelkasten links notes. A DNS reads, reasons, and acts on a graph of notes in real time. The first two are nouns. The third is a verb that has not stopped happening since the moment you set it up.

One more orientation point before the lineage. The metaphor of a nervous system is doing more work here than the metaphor of a brain. A brain is a single organ, mostly bounded by a skull. A nervous system is distributed. It runs from the soles of your feet to the crown of your head, with branches into every organ along the way. It senses, it transmits, it reasons, and it actuates. That distributed shape is the right one for the artifact we are building. Your DNS sits on a laptop, a phone, a server, a watch, a microphone in the kitchen if you want one, and a cluster of cloud models you do not own. The body of it is everywhere. The nervous system metaphor is the only one in the human anatomy that maps cleanly onto that geometry.

2. The lineage you stand on

Nothing about this idea is mine alone. The DNS sits on top of four ancestors, and the honest thing to do is name them.

Niklas Luhmann's Zettelkasten

Luhmann was a German sociologist who, between the early 1950s and his death in 1997, built a wooden slip box of roughly ninety thousand index cards. From that box he produced about seventy books and more than four hundred academic papers. The cards were numbered, cross-referenced, and clustered into branching addresses. Each card held one thought. The links between cards did the heavier work of building arguments. Luhmann talked about the slip box not as storage but as a thinking partner, something he had a dialogue with. There is no Luhmann user manual. He did not write down his method for outsiders. We know the system from the surviving archive and from the people who studied it after he was gone.

Sönke Ahrens, 2017

The person who carried Luhmann into the English-speaking productivity world was Sönke Ahrens, in How to Take Smart Notes, published in 2017. Ahrens did the translation work that Luhmann never did. He explained the slip box as a method anyone could adopt, and he tied it to one durable claim: writing should drive thinking, not the reverse. That is the core idea worth carrying forward. You do not write to record what you already know. You write because the act of forcing a thought into one clean sentence is itself how you find out what you think. Ahrens is the bridge author. If you read one book on note-taking before this one, read his.

Tiago Forte, Building a Second Brain, 2022

Forte took the same family of ideas and rebuilt them for mainstream knowledge workers. His method, CODE, names four moves: Capture, Organize, Distill, Express. His organizational scheme, PARA, sorts everything you capture into four buckets: Projects, Areas, Resources, Archives. Forte's contribution was popular, not academic. He made the personal knowledge management practice legible to people who were never going to read a sociology archive. The 2022 book turned second brain into a household phrase. Many readers of this book have already built one. Good. The DNS subsumes what you built.

Andy Matuschak and evergreen notes

Andy Matuschak, working publicly at notes.andymatuschak.org from roughly 2015 onward, pushed in a different direction. His core principle is that notes should be atomic and concept-oriented, with each note holding one idea that you can refine over years. Notes are not journal entries or meeting minutes. They are durable claims you keep editing as your understanding deepens. The links between them are the real intellectual asset. Matuschak's working notes are public, which means you can watch the method in action. The principle to carry from him: atomicity is what makes the graph navigable.

Here is what they all missed, not because they were wrong but because the tools were not there yet. None of these four ancestors had agents that could read and reason over the graph in real time. Luhmann walked to his slip box. Ahrens taught humans to do the linking by hand. Forte assumed the user would do all of the distilling. Matuschak built the most beautiful version of the static graph, and even he, until recently, did the synthesis with his own brain. The DNS is what becomes possible once a model can sit on top of the graph and read it with you.

There are a few more shoulders worth naming, even if briefly. Pierre Teilhard de Chardin, writing between 1927 and his death in 1955, gave us the word noosphere: a sphere of thought enveloping the Earth, a layer of mind sitting on top of the biosphere. Howard Bloom, in Global Brain (2000), pushed the same intuition into a more rigorous frame of collective intelligence, long before any of us had the substrate to test it. These thinkers are not part of the technical lineage of the DNS, but they are part of the conceptual one. They understood that minds, individual and collective, were always going to find a way to externalize themselves. The DNS is one of the ways that prediction is coming true at the scale of a single person.

3. The neocortex extension

This is the section the 2nd edition adds. In 2018, when I first sketched this book, the argument I am about to make would have been speculative. In 2026 it is operational.

The neocortex is the outer layer of the mammalian brain. In humans it is unusually large and unusually folded, and it is the part of you that handles abstract reasoning, language, planning, and semantic association across categories. It is not the part that stores raw facts. It is the part that takes the facts your other systems hand it and finds the pattern. When you read a paragraph and notice that it echoes something you read three years ago in a different book, that is the neocortex doing semantic association. When you draft a sentence and a better version arrives a second later, unbidden, that is the neocortex too.

Large language models, and the agents built on top of them, externalize a meaningful slice of that function. They do pattern recognition over text at a scale no human brain can match. They make semantic associations across vast corpora. They can reason over a graph rather than only retrieve from it. Those three capabilities, taken together, look very much like a subset of what the neocortex does in a human head. Not all of it. Not the embodied parts. Not the parts tied to emotion and personal memory. But the synthesis layer, the verbal reasoning layer, the analogical layer: those are now external.

There is a philosophical literature that anticipated this moment. Andy Clark and David Chalmers, in their 1998 paper "The Extended Mind," argued that the boundary of cognition is not the skin or the skull. If a tool reliably extends a cognitive function, the tool is part of the cognitive system. Their canonical example was a man named Otto who carried a notebook for memory: Clark and Chalmers argued his notebook played the same functional role as a biological memory and should be counted accordingly. Clark expanded the argument in Supersizing the Mind (2008). For two decades that hypothesis sat in philosophy seminars. Interesting, debated, mostly theoretical. Then LLMs arrived and the hypothesis stopped being theoretical. Today, when an agent reads your graph and proposes a synthesis you did not consciously assemble, the extended mind is no longer a thought experiment. It is the thing you are using.

The implication is the point of this section. A Digital Nervous System is the first kind of external system that extends both human signaling and human semantic reasoning at the same time. That dual extension is why the metaphor of nervous system fits the artifact better than the metaphor of brain or memory or notebook. A brain is a single organ. Memory is a single function. A nervous system is the whole signaling-and-reasoning apparatus that lets an organism take in the world, make sense of it, and act on it. That is the right shape for what we are building.

One practical consequence is worth flagging now, before we get to architecture. If your DNS is going to extend your neocortex, you have to feed it the same kind of material your neocortex actually works on. That means writing, not just clipping. It means decisions captured with their context, not bookmarks with no notes. It means the unfinished thought, recorded the moment it arrives, rather than the polished one drafted a week later from memory. The richer the input, the richer the synthesis the SNS can perform on your behalf. Garbage in, garbage out is true for LLMs and it is true for the graph they sit on top of.

4. The properties of a healthy DNS

A DNS, like a body, can be in better or worse shape. Here are the properties to optimize for.

It should be interconnected, with links that grow denser over time. The first ten notes you make will sit mostly alone. The hundredth will already have three or four neighbors. By the time you have a thousand notes the graph starts behaving like a graph, with clusters, bridges, and unexpected adjacencies. Density is the metric to watch. A flat list of a thousand notes is a worse system than a connected web of two hundred.

It should be dynamic, evolving as your understanding evolves. Notes you wrote two years ago should be editable today without guilt. The brain does this naturally. Neuroplasticity is the formal name: the structure of the brain reorganizes itself in response to new experience. A healthy DNS does the same thing. A note is not a tombstone. It is a working position you hold until you hold a better one.

It should be contextual, where the meaning of any node comes from the nodes it links to. A standalone definition is almost useless. A definition that sits next to three examples, two counter-cases, and a link to the project where you first encountered the idea, that is a usable piece of knowledge. The cards in Luhmann's box meant what they meant because of where they sat in the chain. The same is true here.

It should be holistic, where viewing the graph reveals patterns the individual notes hide. Step back from your DNS once a quarter. Look at the clusters. You will find shapes you did not put there on purpose: a theme you have been circling for a year, a question you keep returning to without realizing, a body of work that has cohered into something publishable. The graph view is the planning tool the individual notes cannot be.

It should be active, with agents that read, retrieve, summarize, and write on your behalf. This is the property the older lineage did not have. An active DNS is not waiting for you to query it. It is processing your inbox, watching your calendar, drafting summaries of the meetings you just left, and proposing links between notes that are starting to belong together. The shift from passive to active is the largest functional change of the past three years.

It should be resilient, where missing nodes or noisy inputs do not collapse the system. The human brain handles ambiguity well. You can read a sentence with three typos and three missing words and still recover the meaning, because the surrounding context fills the gaps. A healthy DNS has the same property. One bad note does not corrupt the graph. One day of sloppy capture does not destroy the week. The web of connections is the thing that keeps the system useful even when the inputs are imperfect.

5. Why LLMs change everything

The DNS as an idea predates large language models. The first edition of this book described a version of it that could be built, more or less, with hyperlinked text files and a disciplined human. That version worked. I used it. But it was, in honesty, only as smart as the time I invested in maintaining it.

Pre-LLM, the DNS was static storage with hand-built links. The graph existed only where you had drawn the edges. You wrote a note, you wrote another note, and you, the human, decided whether they were related. Search worked on keywords. Retrieval worked on memory. The system was useful but it was inert between your visits.

LLMs added two things. The first is semantic search and association. The graph became navigable by meaning, not just by key. You can now ask a question your past notes were never tagged to answer, and the system can still find the relevant ones, because the relevance is computed semantically. The second is generation. The system can not only find your notes, it can also write new ones, summarize old ones, and propose connections you did not see. That is a different kind of partner.

Agentic AI, which became practical from 2024 onward, added the action layer. An agent is not a chatbot. An agent is an LLM with tools, given a goal and the latitude to take steps toward it. Agents now read your graph on a schedule. They summarize. They propose new links between notes that are starting to belong together. They write drafts against the corpus you have built and they do it in your voice if you have given them enough of your voice to learn from. They send the email you would have sent, with your review, in a fraction of the time. The DNS stopped being a filing cabinet. It became a collaborator.

Here is a small concrete example to ground all of this. I keep a daily journal in the DNS. The capture is mundane: voice notes, meeting transcripts, the occasional photograph. Every morning, before I sit down, an agent has already read the previous day's entries, looked across the last ninety days for related work, and produced a one-page briefing that names the open threads, the decisions I deferred, and the questions I asked twice without answering. That briefing is not a search result. It is a synthesis. The same agent flags notes that have started clustering into a possible essay and offers to draft an outline. Some mornings I ignore the offer. Some mornings I accept and the outline saves me an hour. None of this was possible in the version of the DNS I described in the first edition of this book. All of it is possible now with tooling a single person can configure in an afternoon.

This is the quantum leap the first edition pointed toward and could not yet describe. The 2nd edition can describe it because it is here. The DNS is no longer a future system. It is the system you should be building this year, with the tools that exist today, in the configuration this book is about to teach you.

Chapter 6 is where the build begins. You now know what a DNS is, where it came from, and what makes one healthy. The next chapter walks through the architecture: how to set up the capture layer, how to structure the graph, where the agents sit, and how the whole thing fits together on a laptop you already own.

Chapter 6: Building and Training Your DNS

The first edition of this book ended this chapter with a shrug. Pick Obsidian, pick Logseq, pick a plain folder of Markdown. Any of them will do. The protocol matters more than the tool. That advice was honest, and it was also incomplete. Three years of running my own Digital Nervous System has changed my mind about where the work actually lives.

So this chapter is going to make an architectural decision the first edition refused to make. I am going to recommend a specific substrate. Not because the others are wrong. Because I have built the one I am about to describe, I run it daily, and the leverage gap between it and a styled note vault is now too large to leave unmarked.

The substrate is three things in one git repo. A folder of Markdown and HTML. A directed acyclic graph of skills, each one a folder shaped by the skills.md standard, the open protocol I publish as SKP v0.2.0. And a routing layer called navigating-skills that scores those skills against any situation you describe and assembles a chain. My live deployment of all of this lives at fos.kentlangley.com. The site is the front door. The graph behind it runs through Claude integration.

You can build this yourself. The architecture is open. The spec is published. This chapter walks the open path. If you would rather have a guide, I run two assisted versions, Contextful for the context pack and Founder OS::BUILD for the full install. One sentence each, that is the entire mention. The book teaches the version you can install on your own machine over the next month.

Part 1: The substrate

The repo has three top-level directories and one index file.

skills/ holds one folder per skill. Each folder has a SKILL.md and a config.toml, and conforms to SKP v0.2.0. SKILL.md is Markdown with YAML frontmatter. The frontmatter names the skill, versions it, describes it in one line, lists its dependencies, and declares the trigger phrases that should activate it. The body of the file contains directives, validation checkpoints, references, and cross-skill workflows. Optional but conventional sidecars include schema.json, examples/examples.jsonl, traces/{date}.jsonl, references/, and templates/. The full spec is at /Users/kent/dev/fos/SKP.md, published under CC BY-SA 4.0. Anyone can read it, fork it, or extend it.

context/ holds the 6-layer context stack. Identity, Operations, Knowledge, Memory, Voice, Guardrails. Each layer is its own file. Identity, Operations, Knowledge, and Memory are the stack layers. Voice and Guardrails are wrappers that cross-cut every output. This is the bundle you load into Claude Projects or whatever AI surface you use, so the model knows who you are, what your business runs on, what you have already decided, and how you sound.

.skp/ holds two append-only logs. routing.jsonl records routing decisions, one JSON object per line, with timestamps, axis scores, and exclusion reasons. usage.jsonl records every time a skill is actually applied. These two files turn the system from a folder of static documents into a record of how you think over time.

manifest.toml at the repo root indexes the skills and exposes their dependencies. The routing layer reads it as an adjacency list.

Why does this beat a styled vault. Four reasons, none of them ornamental.

Skills are first-class. They are not notes about prompting. They are versioned, declarative units with frontmatter, dependencies, and triggers. You can ship a skill, fork a skill, reuse a skill across machines or projects. A note in Obsidian cannot do that.

The graph is structured. Dependencies are explicit. Triggers are explicit. The DAG is queryable. The routing layer can score it. A backlinks panel can show you connections; it cannot weigh them.

The substrate is git. Every change is auditable. The whole system is portable across machines, environments, and AI providers. You are not betting on a vendor's roadmap.

The files are yours. Plain text. Open spec. No lock-in.

To be precise about the move. This is not a recommendation against Obsidian or Logseq. They are fine viewers. They can sit on top of the same folder and render the graph beautifully. Use them if you want a graph view, a daily-notes pane, a command palette. The point is that the truth lives in the SKP-shaped repo underneath, and your first investment goes into making that repo well-formed, not into stylizing the lens that renders it.

Part 2: The daily loop

Tiago Forte's CODE method (Capture, Organize, Distill, Express, Building a Second Brain, 2022) is still the cleanest acronym for the daily moves. I borrow it openly. The shape that follows bends his vocabulary toward graph thinking and toward the SKP substrate.

Capture. During the working day, you write inbox notes into context/memory/ as date-stamped Markdown files. Voice notes, transcripts, decisions, a sentence that caught your attention in a call. One paragraph each. No links. No tags. The goal at this stage is volume. Move the idea out of your head, into a file, and get on with whatever you were doing. Five captures a day is a reasonable target during the build phase.

Process. Within forty-eight hours, every captured note gets a verdict. Read, keep, delete, or escalate into a skill. The bar to write a skill is high. You earn a SKILL.md only after you have done the thing at least three times and you can describe the directives clearly enough that someone else, or some agent, could repeat the move. Most captures stay captures. A few get killed. A small minority get promoted. That asymmetry is the system working as designed. Niklas Luhmann threw away most of what he wrote. The Zettelkasten compounded because of what he refused to keep.

Link. Skills declare their dependencies in frontmatter. Captures point to the skills they support by living inside a relevant skill's references/ folder, or by being cited from a skill's body. This is how the DAG densifies. A skill with no dependencies is a leaf. A skill with many dependents is a hub. The shape of the graph after six months tells you, accurately, where your operating leverage actually concentrates.

Synthesize. Once a week, forty minutes on a Friday, you write a synthesis note that draws a line through three to seven recent skill applications or captures. Sometimes the synthesis becomes a new SKILL.md. Sometimes it stays a note. Either way, you are doing the move most people skip, the move that proves the system is producing thinking and not just storing it.

Andy Matuschak (evergreen notes, notes.andymatuschak.org, 2015 to present) gave the field the atomicity principle. One note, one idea. In SKP this principle becomes: one skill per skill folder. The frontmatter carries one idea. The directives carry one idea. The validation checkpoints carry one idea. Atomicity is what keeps the graph a graph instead of degenerating into a list of long documents.

Part 3: The routing layer

This is the new core of the practice and the part the first edition did not have.

navigating-skills is v1.0.0 of the routing layer. It is a meta-skill. Its job is to take a situation in natural language and decide which skills to fire, in what order. It does this with a deterministic scoring algorithm across four axes.

Axis 1, Trigger Match (×3, max contribution 30). Does the situation match the skill's declared triggers? Exact phrase matches score highest. Domain-keyword overlap scores second. No match scores zero.

Axis 2, Tier Appropriateness (×2, max 20). Is this skill the right scale for where you actually are? A skill written for a Tier 4 founder asking about exit prep is not the right answer for a Tier 1 founder hunting for product-market fit. The algorithm penalizes mismatch.

Axis 3, Prerequisite Satisfaction (×1.5, max 15). Has the upstream work been done? Skills declare dependencies. The algorithm checks skills/{name}/traces/ for prior applications. If the prerequisite has traces, full credit. If it does not, the score drops.

Axis 4, Recency and Redundancy (×1, max 10). Has this skill been applied recently with positive results? If yes, the score drops, to avoid redundant routing. If the situation has materially changed since the last application, the penalty is suspended.

Composite max is 75. Top candidates are returned with reasoning. The chain is logged to .skp/routing.jsonl with timestamps, per-axis scores, the selected chain, and the reasons any high-scoring skill was excluded.

Here is what that looks like in practice. A founder describes a real situation: "I can't step away from sales for more than two weeks without revenue dropping." The routing pass surfaces three high-scoring candidates. managing-revenue scores around 67, because the trigger match is direct, the tier fit is strong, and the recency is fresh. managing-founder-capacity scores around 63, because the framing names a founder bottleneck explicitly. selling-saleless scores around 45, lower but still in chain range, because it offers a concrete next move for a founder trying to remove themselves from the deal cycle. The assembled chain comes back as managing-founder-capacity first (identify what can be delegated), managing-revenue second (systematize the process), selling-saleless third (install a mechanism that does not require the founder on every call). The exclusion log records that building-operations-systems scored 51 but was deferred, because the binding constraint is revenue dependency rather than operational systematization. Next session, that exclusion becomes the natural starting point.

That whole decision lives as one JSON object in routing.jsonl. You can read it. You can audit it. You can argue with it. If you decide the algorithm got it wrong, you can edit the situation description, re-run, and the new decision lands as the next line in the file. Over a month, the log becomes a record of how you decided things, written in a form you can grep.

This is the line between a DNS and "I asked Claude and it answered." The semantic search and the LLM reasoning happen around the routing decision. The routing decision itself is structured, scored, and logged. You can inspect the math. You can change the weights. You can suppress a skill or promote one. The system is not a black box that you trust. It is a deterministic mechanism you can audit.

Part 4: The 30-day install plan

Week 1. Set up the substrate. Create the repo. Run git init. Make the three directories: skills/, context/, .skp/. Drop a manifest.toml at the root. Then write three SKILL.md files for things you actually do. One process you run weekly. One decision you make recurrently. One piece of expertise you carry that no one else on your team has. Use the SKP v0.2.0 frontmatter, fill in the directives and validation checkpoints, and commit. By Friday, you have three real skills, versioned and indexed.

Week 2. Build the context pack. Sit down for two focused hours and write the 6-layer stack. Identity, Operations, Knowledge, Memory, Voice, Guardrails. Each layer becomes its own file inside context/. Identity is foundational and changes rarely. Operations carries the monthly state of the business. Knowledge is proprietary how-to. Memory is the rolling decision log. Voice tells the model how you sound. Guardrails define the hard nos. Load the bundle into Claude Projects, or whatever AI surface you use, as the project context. Run one real prompt against it. Notice the difference between context-loaded and cold. This is also what the Contextful workshop walks founders through in two hours if they want a guided version. The book gives you the open version.

Week 3. Install navigating-skills. Drop the navigating-skills SKILL.md into skills/navigating-skills/. Update manifest.toml to register it. Route three real situations through it. Real, not hypothetical. A pricing decision, a hire, a customer escalation, whichever three are alive for you that week. After each routing pass, open .skp/routing.jsonl and read what the algorithm wrote. Notice which skills were selected and why. Notice which were excluded and the reasons recorded. That log is the routing layer thinking out loud.

Week 4. Synthesize and trace. Pick the most useful skill from week one and run it twice more on different situations. Write a trace file for each run into skills/{name}/traces/. End the month by reading your own routing.jsonl back to back, like a journal of how you decided things. The skills you keep firing are signaling something true about your work. The gaps the routing surfaces are signaling something true about your weak edges. The DAG is now shaping itself.

You will not finish the month with a complete system. You will finish with a real one. Tiny. Inspectable. Yours.

Part 5: Failure modes

The same four collapse patterns from the first edition still apply. They are worth naming briefly.

The over-organizer builds tags and folder hierarchies before any skills exist. The fix is to forbid yourself from creating structure that does not refer to at least three real skills already on disk.

The capture maximalist captures forever and processes never. The inbox climbs past two hundred items. Nothing gets promoted into a skill. The fix is a hard forty-eight-hour processing deadline. Verdict every capture, even if the verdict is delete.

The closet rebuilder switches tools every two weeks. Three months in, has used four apps and produced zero skills. The fix is a six-month moratorium on tool changes. The substrate is plain Markdown anyway. The lens does not matter as much as you think.

The lonely linker captures, processes, even writes skills. Never routes a real situation through navigating-skills. The graph stays a storage device. The fix is to put one routing pass on the calendar as a recurring weekly block, with a real situation as the input.

One new failure mode is specific to the new architecture. Call it the fOS tourist. The fOS tourist reads the SKP spec, admires the architecture, screenshots the routing log, posts about it. Installs nothing. Six months later, the repo is clean and the leverage is zero. The protocol has nothing for you until you write the first SKILL.md.

Name the shape. Step out of it. Run the loop.

Closer

You now have a substrate, a daily loop, a routing layer, and a four-week install plan. The DNS is running, at the smallest workable scale, on your machine. The next question is where this whole arrangement is heading. Chapter 7 takes the practice you just installed and zooms out, to the version of the DNS that sits behind your shoulder all day and the version of the noosphere it eventually becomes part of. For readers who would rather install the system with a guide, Contextful covers the context pack in two hours and Founder OS::BUILD covers the full install in four weeks. The architecture underneath is the same one this chapter just described. The book teaches the open version, because the open version is the one that compounds when you maintain it yourself.

Chapter 7: The Future

It is May 2026.

Agentic AI is not a coming wave. It is a working layer. When you opened your laptop this morning, there was almost certainly an agent in the loop somewhere, whether you named it or not. Maybe it lives inside the editor where you write code. Maybe it sits behind the research tool you used to brief a meeting. Maybe it is the small worker that drafted three replies in your inbox before you read the first message. The point is not the brand. The point is that the loop is closed. Software now writes, reads, browses, calls tools, and hands you back a result.

If you have made it this far in the book, you are already operating a primitive Digital Nervous System, whether or not you have called it that. You have notes that link. You have agents you talk to. You have a graph forming, even if it lives across four apps that do not yet speak to each other. The DNS is not a future product. It is the name for what you are already doing, organized.

So the question for the rest of this chapter is not whether the future arrives. The future is here. The question is what arrives next, and what posture you take toward it.

The agentic baseline

Start with what is actually live.

Coding agents now read a whole repository, propose a change, write the change, run the tests, and open the pull request. The human does not type the code. The human reviews the diff and answers questions when the agent gets stuck. This is the default for serious engineering work in many shops as of the writing of this book. Tools like Cursor and Claude Code are the visible names. The pattern matters more than the name. The pattern is: agent drafts, human judges, agent revises, work ships.

Research and writing agents do the same thing one layer over. You give a brief. The agent browses, retrieves, cross-checks, drafts. You read, mark up, and send it back. The first pass arrives in minutes. The final pass arrives in hours instead of days. Multi-step browsing, structured synthesis, and citation chains that used to take a graduate student a week now take a competent operator an afternoon.

Behind the scenes, a protocol has begun to standardize how agents reach tools and data. The Model Context Protocol, MCP, is the version most people have run into by name. The principle is older than the protocol. An agent should be able to ask for a calendar, a file, a search, a database row, or another agent, and get a clean answer back. Standards like MCP make that possible across vendors. The plumbing is settling.

Then there are the multi-agent setups. One agent plans the work. Another executes it. A third reviews the output before it reaches the human. This is not science fiction. It is a Tuesday afternoon configuration that any operator can stand up in an evening with the tools shipping today. The cost of running three coordinated agents is now lower than the cost of writing the email asking a contractor to do the same job.

Here is the connection back to your DNS. An agent running on the open internet is informed but generic. It knows everything in general and nothing about you. An agent running on your DNS knows your projects, your decisions, your taste, your last quarter, your open loops. The Semantic Nervous System you installed in the last chapter is the substrate that makes the difference. Without it, you have a clever assistant who keeps forgetting your name. With it, you have a colleague who has read every page of your work.

The next layer: shared and organizational DNS

The personal DNS is the unit. The next layer is multi-user, and it is already arriving.

Consider a founder and a chief of staff sharing one knowledge graph. The founder drops a voice memo from a Tuesday meeting. The chief of staff sees it parsed into decisions, open questions, and follow-ups within minutes. The agents acting on the graph route work to whichever human is the right destination, and the trail of who decided what stays inside the system. The shared DNS is not a new app. It is two personal DNSes that have agreed on a boundary. Where the two-person team works, a research duo can work. A founder and a deputy can work. A coach and a client can work, provided the trust is real and the boundaries are clean.

The hard problems in this layer are not technical. They are conventional. Who is allowed to read which nodes. Who is allowed to write to them. Whose voice the synthesizing agent should use when it speaks back. What counts as a private draft and what counts as shared truth. The two-person DNS surfaces these questions immediately. A team of ten amplifies them. A team of fifty turns them into the entire job of an operations function.

Which is where the org-scale layer enters. This is what fOS is. The book teaches the personal DNS. fOS productizes the same architecture at organizational scale, with skills as the unit of know-how, a router as the dispatcher that picks the right skill for the right situation, and shared traces and routing logs as the institutional memory the company writes about itself as it runs. I have mentioned it once, on purpose. You do not need to buy anything to take the personal DNS seriously. You should know that the same shape scales when you are ready for it to.

The interesting design question for the next few years is the boundary between personal and shared. Each operator should own their own nervous system. The organization should be able to draw from it without owning it. The right answer there is not yet settled. The operators who get it right early will set the conventions everyone else inherits.

The long horizon

Past the working layer and the shared layer, the road gets speculative. I will be careful here.

The most-cited frontier is the brain-computer interface. Neuralink has put implants in human subjects. Other teams, some less visible, are doing parallel work. The fact of the implants is real. The marketing around their near-term implications is louder than the engineering. Reliable, broadly deployed, full-bandwidth BCIs that compete with a keyboard for thought-to-text speed are not a 2026 reality, and on any honest read they are not a 2030 reality either. For the next decade, your interface to your DNS will be the same set of channels you already use. Typed prompts. Voice. Structured queries that the agents understand. Build for those. The keyboard is not going anywhere on the timeline that matters for the next ten years of your career.

The second frontier is older than the technology, and is more interesting because of that. Howard Bloom, in Global Brain in 2000, argued that human history reads as the slow construction of a collective intelligence, with each new substrate, language, writing, print, the network, adding bandwidth to the shared mind. Pierre Teilhard de Chardin, writing between roughly 1927 and his death in 1955, proposed the noosphere, a layer of thought enveloping the Earth as a kind of evolutionary inevitability. The two men came from very different starting points. Bloom was a popular-science synthesizer. Teilhard was a Jesuit paleontologist with a theological hypothesis riding on top of his geology. They were pointing at the same shape from different sides.

Large language models, trained on a substantial fraction of the recorded written corpus of the human species, are the first piece of working infrastructure that looks at all like what those two were describing. I will not claim the noosphere is here. I will say that an LLM, fed by the writings of millions of people across centuries, talking back in something resembling a coherent voice, is closer to that picture than anything previously built. The personal DNS sits at the seam between you and that collective layer. Your graph is yours. The model in the agent draws on the whole.

Whether that adds up to a collective mind in any strong sense is a question the next generation gets to answer. Your job is to operate well at the seam.

What does not change

There are a few constants. Notice them before the closer.

Taste does not get automated. Knowing which question is worth asking is still the most valuable move an operator makes in a given day, and no agent yet built does it for you. The agent makes you faster at executing the question. It does not pick the question.

Trust does not get automated. Who you let into your graph, who you delegate to, who you take a call from on a Friday night, those decisions are made by humans about humans. The DNS amplifies your bandwidth for those relationships. It does not replace them. The wider your reach gets, the more weight the trust filter has to carry.

And the human reason does not get automated. You are building this thing because there is something you want to do with the time it frees up. A company you want to build. A book you want to write. A family you want to be present for. The DNS does not pick that target for you. It assumes you know it. If you do not, no system in this book will help.

Build now

The reader's stance, then, is the one you already suspected.

Build now. The tools are bending toward the operator at this exact moment in a way that was not true five years ago and may not be true in ten. Right now, in 2026, you can stand up a personal DNS with a weekend of focus and a small monthly subscription to a frontier model. The defaults are still loose enough that you get to shape them. The frameworks are still open enough that you can fit them to your own work. That window does not stay open forever. Defaults harden. Platforms close. The operators who install their nervous system in this stretch will compound for a decade. The operators who wait will install a DNS shaped by the defaults the platforms hand them, and those defaults will not be neutral. They will be tuned for the platform's revenue model, not for the operator's leverage.

I am not asking you to predict the future. I am asking you to take a posture toward it. The posture is this. The system is yours. You build it. You own the graph. You set the conventions. You decide which agents read it, which write to it, and which never see it. You stay at the seam.

The next chapter is where this stops being a book and starts being a practice. It is the first installable loop. Sixty minutes from reading the page to running the thing on your own machine. Bring a laptop, a model you can talk to, and the smallest project you actually care about. We will start there.

Chapter 8: Module One, Your First Loop

Frame

This hour does one thing. It installs the foundations of fOS on your machine, at the smallest scale that still counts. When the clock runs out, you will have a working fos/ repo on disk with five things in it: your first three SKILL.md files following SKP v0.2.0, a minimal three-file context pack (Identity, Voice, Guardrails), the navigating-skills skill (v1.0.0) installed as your routing layer, one real routing decision logged in .skp/routing.jsonl, and a manifest.toml indexing what you have built. The whole thing lives under git. The first commit is yours.

That is the seed of a Digital Nervous System. Small, well-formed, real, navigable. Every protocol in Chapter 6 grows from this seed. The thirty days do not start blank. They start with a tiny version of the entire architecture already running on your machine.

Let me be honest about what this is not. It is not a finished DNS. It is not a purchase of Founder OS::BUILD, the four-week assisted sprint where Kent's team installs the architecture with you. It is not the full six-layer context pack that Contextful, the two-hour workshop, walks founders through. It is the smallest possible version of the architecture, set up correctly, ready to grow. The book teaches the open version. The paid paths are the assisted versions, for founders who want a guide.

One more thing before you start. The architecture matters more than the contents. If your first skill is rough, that is fine. If your context pack reads like a draft, that is fine. What you are installing this hour is the shape of the system, the file layout and the routing layer, so that everything you write tomorrow lands in the right place. The shape is what compounds.

Setup (5 minutes)

Open a terminal. Pick the directory where you keep code. I use ~/dev/. Yours might be ~/code/ or ~/projects/. The location does not matter. The repo does.

Inside that directory, run:

mkdir -p fos/skills/{my-first-skill,navigating-skills} fos/context fos/.skp
cd fos
touch manifest.toml .skp/routing.jsonl .skp/usage.jsonl
git init

That is the entire scaffold. Three folders for skills, context, and audit logs. Three files at the top: a manifest, a routing log, a usage log. One git repo. The schema can grow later, when the system tells you it needs to. Right now, less is more.

Step 1: Write your first SKILL.md (15 minutes)

Pick one thing you actually do. Not aspirational. Something you did this week. A recurring decision, a process you run, a piece of expertise you carry in your head. Drafting a weekly investor update. Running a one-on-one with a direct report. Evaluating a vendor proposal. Pick one. The narrower, the better.

Open two new files: skills/my-first-skill/SKILL.md and skills/my-first-skill/config.toml. Rename the folder later if you want. For now, this is fine.

Paste this into SKILL.md and edit it for your actual skill:

---
name: drafting-weekly-investor-update
version: 0.1.0
description: Compress the week's signal into a 5-bullet update.
dependencies: []
triggers:
  - "investor update"
  - "weekly report"
  - "what should I tell investors"
---

## Core Directives
- MUST lead with the metric that moved most this week.
- MUST include one decision the founder made and why.
- SHOULD include one ask, if the reader has one.

## Validation Checkpoints
- [ ] The update is under 250 words.
- [ ] At least one specific number appears.
- [ ] The update does not editorialize about market conditions.

A few rules to write your own version. Directives should be MUST or SHOULD statements, not vibes. Each one should be checkable by another person reading the output. Validation checkpoints go at the end as true-or-false items. If you cannot answer the checkpoint with yes or no after reading the output, rewrite it. The skill should be specific enough that you could hand the SKILL.md to a junior teammate and get back a draft you would actually send.

The frontmatter is the SKP v0.2.0 metadata block. name matches the folder. version starts at 0.1.0 because you are going to revise this skill. description is one line. triggers are the phrases that should pull this skill into a routing decision later.

Now the config.toml. Three lines is enough for Module One:

[skill]
author = "your name"
created = "2026-05-13"

SKP allows more. Tags, default models, environments. You do not need any of that to start. Save both files.

Step 2: Build a 3-file minimal context pack (10 minutes)

The full Contextful pack has six layers (Identity, Operations, Knowledge, Memory, plus Voice and Guardrails as wrappers). Module One uses three. The other three you will add in Week 2, or, if you want a guided walkthrough, in the two-hour Contextful workshop.

Open context/ and create three Markdown files.

context/identity.md. Three sentences. What is your business, who is the founder, what is the one thing you do that nothing else does. No marketing copy. Plain description, the way you would say it to a peer over coffee.

context/voice.md. Three short paragraphs. Pick three real artifacts: one email you sent, one tweet or LinkedIn post, one decision memo. Paste them verbatim. The model will infer your voice from the samples better than from any rule you could write about your voice. Do not edit them to look better. They are training data, not a portfolio.

context/guardrails.md. Three hard nos. Concrete things the assistant must never do. Examples: "do not write in marketing voice," "do not make claims about my customers without evidence in the conversation," "do not invent statistics or sources." The shorter and harder, the better.

That is one half of the six-layer stack, plus both wrappers. It is enough to start. The other three layers (Operations, Knowledge, Memory) describe how you run the business, what you know that few others know, and what you have decided before. Those grow as you use the system. Right now, the seed is enough.

Step 3: Install navigating-skills (10 minutes)

The routing layer comes next. navigating-skills (v1.0.0) is the meta-skill that scores your other skills against a real situation and picks a chain. Without it, you have a pile of SKILL.md files. With it, you have a DAG that knows which subset to fire.

Copy the canonical SKILL.md from Kent's open spec at /Users/kent/dev/fos/skills/navigating-skills/SKILL.md into skills/navigating-skills/SKILL.md. Add a config.toml next to it with the same three-line skeleton you used in Step 1.

Now open manifest.toml at the root of fos/ and paste this:

[[skills]]
name = "drafting-weekly-investor-update"
path = "skills/my-first-skill"
status = "active"

[[skills]]
name = "navigating-skills"
path = "skills/navigating-skills"
status = "active"

That is the index. Two skills, both active, both pointed at their folders. The routing layer can now see them. As you add more skills, this file grows. The router reads it as the adjacency list for your DAG.

Step 4: Route your first real situation (15 minutes)

Open Claude. Or whichever frontier model you use. Start a fresh conversation, no memory, no prior context. You are going to paste the system in, in order, then ask it to think.

Paste, in this order:

1. The contents of context/identity.md, context/voice.md, and context/guardrails.md, each with a one-line header noting which file it is.
2. The full text of skills/navigating-skills/SKILL.md.
3. The contents of manifest.toml.
4. A one-paragraph description of a real situation you have on your desk today. A decision to make, a piece of writing to produce, a meeting to prepare for. Be specific. Names, numbers, deadlines.

Then ask: "Apply the navigating-skills 4-axis routing algorithm to this situation. Score the available skills. Return the top candidates with their scores and the chain you would assemble."

Read what comes back carefully. Two things should happen. First, the model will notice that the manifest contains only two skills (drafting-weekly-investor-update and navigating-skills itself), so the routing options are narrow. That is expected. Module One is the seed, not the canopy. Second, the model will name the four axes by their weights: Trigger Match times three, Tier Appropriateness times two, Prerequisite Satisfaction times one and a half, Recency and Redundancy times one. Maximum composite score is seventy-five.

Copy the routing decision into .skp/routing.jsonl as a single JSON line. Include the timestamp, a one-sentence summary of the situation, the scored skills with their composite scores, the chain you selected, and a one-line rationale. That entry is the first audit log in your DNS. Future routing decisions will read from this file before they score, so the system gets better at recognizing the situations you actually face.

Close

Look at fos/. Two skill folders. Three context files. A manifest. A routing log with one real entry. A git history. Commit it: git add . && git commit -m "module one complete". The clock says you are still under sixty minutes.

Acknowledgments

This book is not a solo act. It is a thin layer on top of a long lineage of thinkers who did the hard work of figuring out how human minds extend themselves into paper, into systems, and now into agents.

Niklas Luhmann showed that a numbered card and a cross-link, repeated 90,000 times, can outproduce a research institute. Sönke Ahrens translated Luhmann for the rest of us, and gave the English-language world a vocabulary for what a working knowledge system actually looks like. Tiago Forte put a name and a method on the practice of capture, and made it possible for millions of people to start. Andy Matuschak quietly published the principle I lean on the most, that notes should be atomic and concept-oriented, and he did it in the open.

Andy Clark and David Chalmers gave me the philosophical permission slip. Their 1998 paper said out loud what builders already knew: the mind is not stuck inside the skull. Howard Bloom widened the frame to the species. Pierre Teilhard de Chardin widened it further, to the planet. Garry Kasparov, after losing to a machine, named the thing the rest of us would spend the next three decades becoming. The centaur.

Thank you to the readers who ran the protocol from the first edition and told me where it broke. You shaped this revision more than you know. Every awkward step in chapters four through six got rewritten because someone wrote in and said, "this part did not work for me."

To my family, who gave me the time and the patience to write a second edition of a book about a thing most people still cannot name. Thank you.

Further Reading

The reading list below is short on purpose. These are the works the book actually stands on. Read them in any order. Read the ones that pull on you.

The note-taking lineage

Niklas Luhmann's Zettelkasten (1950s to 1997). The original. Roughly 90,000 numbered cards, with cross-links between them, that Luhmann used to produce about 70 books and more than 400 papers. There is no published manual. The system is known through the archive itself and through Sönke Ahrens. If you want to understand why a graph of small atomic notes beats a folder of long documents, this is the source.

Sönke Ahrens, How to Take Smart Notes (2017). The bridge book. Ahrens took Luhmann out of German sociology departments and put him in the hands of every knowledge worker who reads English. Start here if you want the practice without the archaeology.

Tiago Forte, Building a Second Brain (Atria, 2022). The book that gave the modern productivity world a shared vocabulary. The CODE method (Capture, Organize, Distill, Express) and the PARA system (Projects, Areas, Resources, Archives) are both worth knowing, even if you eventually outgrow them. The DNS I describe in this book is what comes after the second brain. Forte's work is the floor you stand on.

Andy Matuschak, evergreen notes and related essays. Published openly at notes.andymatuschak.org. Matuschak's principle that notes should be atomic and concept-oriented is the single design rule that does the most work in a real knowledge graph. His site is itself a working DNS. Read it as both content and demonstration.

The extended mind

Andy Clark and David Chalmers, "The Extended Mind," Analysis 58, no. 1 (1998). The original paper. Short, philosophical, and still the best argument for why your notebook, your phone, and now your agents are part of your cognition rather than tools sitting outside it. If you have ever felt defensive about needing your notes to think, this paper tells you why you should not be.

Andy Clark, Supersizing the Mind: Embodiment, Action, and Cognitive Extension (Oxford University Press, 2008). The book-length version of the 1998 paper. Slower, deeper, and worth it if you want the full argument with the philosophy of mind machinery underneath.

Collective intelligence and the centaur

Howard Bloom, Global Brain: The Evolution of Mass Mind from the Big Bang to the 21st Century (2000). Bloom traces collective intelligence from bacteria to the internet, well before LLMs existed. The book is a useful corrective. The intelligence layer growing on top of humanity is not new. It is just newly visible.

Pierre Teilhard de Chardin, writings on the noosphere (developed 1927 to 1955, with Édouard Le Roy and Vladimir Vernadsky). Teilhard called the sphere of thought wrapping the Earth the noosphere. He was writing decades before computers, and centuries, in a sense, before the thing he was describing actually arrived. Read him for the long view.

Garry Kasparov's Advanced Chess match against Veselin Topalov, León, Spain, June 1998. The match ended 3-3. More importantly, it gave us the centaur framing. Human plus machine, working together, beating either alone. Every chapter of this book is downstream of that match.