Agents are actors. Multi-agent is just the actor model.

An actor…

• Receives messages

• Updates its internal state

• May spawn other actors

• And generate messages in response

That sounds a lot like an agent! An agent receives a user message, it updates its context, it may spawn other agents, and generate messages in response.

It also sounds a lot like Von Foerster’s non-trivial machine, a cybernetic model of the minimal system that can generate agentic behavior: a function that accumulates state through feedback (aka, a reducer).

Actors can also be seen as an idealized biological cell. A cell has a membrane that protects its internals. It sends and receives signals that pass through the membrane. It may also occasionally spawn other cells. This cell analogy is what Alan Kay was reaching for when he designed one of the earliest manifestations of Object-Oriented Programming:

I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning—it took a while to see how to do messaging in a programming language efficiently enough to be useful)… OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.

(Alan Kay in an Email to Stefan Ram, 2003)

I have a degree in molecular biology, and one of the things that struck me as I was studying molecular biology, was that, compared to the kinds of structures that we tend to build here on earth, the average biological structure is more than a thousand times as complex… For instance, a grand piano, a rather complex machine, has about 20,000 parts. Our bodies have approximately a trillion cells, and each cell has many millions of components in its own right…

One of the ways nature discovered to control complexity, and the kinds of interactions that are likely to happen, is to try and encapsulate them in various ways… What biological systems encapsulate is the environment in which processing takes place… If you give each cell its own captured ocean, and let it devote about 90% of its energies toward protecting itself from the outside world, then you get a situation where you can build very large structures rather safely.

(Alan Kay, OOP talk)

If each agent is a cell, how can we make the jump to multicellularity?

OOP never properly made this jump, and it never attained the sublime levels of biological complexity that Kay envisioned. This is because mainstream OOP languages had fatal design mistakes that broke compositionality. Actors fix this. There are multiple formal mathematical models that let us reason about actor composition at scale.

To scale up our multi-agent systems, we could borrow some ground rules from actors:

• Strong encapsulation: Actors never share state. They are strongly-encapsulated black boxes. Information sharing happens exclusively through sending messages.

• State machines: Messages that get sent to an actor’s inbox are processed one at a time, sequentially, resulting in discrete state updates.

• Concurrent messages: Actors process messages sequentially, but the messages themselves are sent and received asynchronously.

• Location transparency: Because messages are sent asynchronously, sending a message to another actor looks the same whether the actor is running locally, or remotely on another computer.

These qualities make it very easy to parallelize actors. You don’t have any of the problems of shared mutable state, because there is no shared mutable state. The system can scale horizontally, from one process to many, and from one computer to many.

Designing our agents as actors lets us spin up lots of parallel agents. Now what? How should these swarms of agents interact and be structured? Here too, the actor model offers useful patterns:

• Supervisor trees: parent actors manage children, handling any failures by restarting them, stopping them, or escalating the failure up the tree.

• Request-response: short-lived actors get spawned to perform a request. They respond with the result, then die.

• Become: an actor replaces its own message-handling behavior after reaching a particular state, effectively becoming another actor.

• Scatter-gather: a coordinator sends queries to N actors in parallel, collects their replies, and produces an aggregated result.

• Routers and worker pools: a router actor parallelizes work by distributing incoming messages to a pool of identical worker actors.

• Aggregators: collect related messages over time, then emit a combined result once a condition is met.

This is just a sample of the patterns that emerge naturally from the actor model. It is pretty easy to imagine how they might be useful in a multi-agent system. Some of them are already common: scatter-gather is used for Claude Code’s Explore agents, and prompt resolvers are a riff on the become pattern.

Actor agents could allow us to run hundreds of parallel agents on a computer, or thousands across load-balanced servers, or even millions of agents across the whole internet. With location transparency, “Have your agent call my agent” and “have your factory call my factory” become essentially the same move.

Furthermore, if every agent signs its messages with a cryptographic key, we get a decentralized protocol for massively multi-agent systems.

Signed messages give us the basis for untrusted coordination between agents. Because signed messages are non-repudiable, we can begin to accrue cryptographically-verifiable reputations for specific agents, and distribute those reputations through webs of trust. Our agents can decide whether to interact with another agent based on that agent’s reputation.

It is also pretty easy to imagine how we might extend such a decentralized agent protocol to enable end-to-end encrypted communication between agents. In the actor model, actors send messages directly to other actors using an address, so just encrypt the message, and send directly to the other agent’s address.

The implementation for such a protocol could be very simple. Sign JSON with an agent-controlled key, send it over the wire. For the details, I would be inclined to borrow from Nostr for message signing, ATProto for DID-based signing and key rotation, and UCAN for delegating authority from user to agent to sub-agent. But in many ways, this protocol problem is simpler than the problem of decentralizing social media. Actor communication is point-to-point, rather than broadcast, so it’s a good fit for HTTP. In its most basic incarnation, an agent could be a URL, its address could be a POST request to that URL, and messages could be signed with a JWT.

Reflecting on this, I feel like I can begin to see the shape of a new internet, something that may supersede the web: the internet of agents.

I do not know.

What I do know, following Clayton Christensen, is that we are in the beginning stages of a disruption. The signs point toward this disruption being bigger than the iPhone on the technological Richter scale. Another thing I know, following McLuhan, is that we are a network society, and networks do not produce nice normal distributions. They produce exponential booms and busts. I also know, following Carlota Perez, that AI is not just a technology, it is a technological revolution. The foom is real, but we will have to survive an epic bust.

What does it look like to have agency in this kind of VUCA environment? How to survive the disjunction? I’ve been puzzling over this, and have fallen back on a barbell strategy.

A barbell strategy is when you put most of your money into extremely safe assets, and invest a small portion in high-risk, high-reward bets. A common split is 90% treasury bills, cash, short-term bonds, and 10% options, venture bets, and volatile stocks. You avoid the middle entirely. This whole approach was pioneered by Nassim Taleb as a reaction to black swans, because in a black swan event, medium risk/medium return assets aren’t actually medium risk. They tend to lose big, while offering modest returns. That’s bounded upside, unbounded downside.

The barbell is designed to protect you from ruin, while exposing you to potentially massive returns. Bounded downside, unbounded upside.

Barbells are one of my favorite heuristics, along with double it or cut it in half, and chopping Gordian knots. My friend Ben Follington has another heuristic, how you do anything is how you do everything, and he says that barbells are how I do everything. This is true 90% of the time.

Whereas the migrant leaves behind a milieu that has become amorphous or hostile, the nomad is one who does not depart, does not want to depart, who clings to the smooth space left by the receding forest, where the steppe or the desert advances, and who invents nomadism as a response to this challenge… The nomads are there, on the land, wherever there forms a smooth space that gnaws, and tends to grow, in all directions. The nomads inhabit these places; they remain in them, and they themselves make them grow.
(Gilles Deleuze and Félix Guattari, “A Thousand Plateaus”)

Instead of being automated themselves—fragmented in task and function—as had been the tendency under mechanization, men in the electric age move increasingly to involvement in diverse jobs simultaneously, and to the work of learning, and to the programming of computers… Man the food-gatherer reappears incongruously as information-gatherer. In this role, electronic man is no less a nomad than his paleolithic ancestors.
(McLuhan, 1964, “Understanding Media”)

When going barbell, the first order of business is don’t die. There are several moves one can make to help stave off death, including cutting down personal burn rate, reducing exposure to personally catastrophic risk, and optimizing for flexibility.

The Instagram moodboard version of this is the Tech Yurt. A solar panel, battery, laptop, and Starlink make for a pretty viable nomadic stack.

Recurse Center, Mars College, and Edge Esmeralda offer turn-key versions of this high-tech/low-cost lifestyle. For me personally, cutting burn rate has been less glamorous, but after a couple of plot-twists, I have found myself outside of the US in a low-burn locale, where I am essentially default alive.

This software nomadism feels precarious, but then again, what isn’t precarious in 2026? I was chatting recently with a friend in big tech. He’s watching AI change by the week and is anxious about the opportunity cost of doing slide decks and middle management while everyone else is hacking. Exposure to upside is bounded (promotions), while exposure to risk is unbounded (layoffs and permanent job displacement). Many startups are also in a bind. As Steve Blank puts it, if your startup raised more than two years ago, it's probably DOA. Excluding a few AI companies like Anthropic, OpenAI, and Google, much of incumbent tech is looking like the kind of middle-risk investment that a barbell strategy tries to avoid.

Professionalism is environmental. Amateurism is anti-environmental. The professional tends to classify and to specialize, to accept uncritically the groundrules of the environment. The expert is the one who stays put. The amateur can afford to lose.
(Marshall McLuhan, “The Medium is the Massage”)

Freedom of movement, both intellectually and physically, is worth a premium in this environment. Ideally, you want to work on whatever is most important, with whoever is most interesting, wherever that needs to be. The goal of relinquishing attachments is not just to survive, but to gain this freedom of movement.

So, my move right now is to stay lean. A low burn-rate leaves me free to explore the jagged frontier full-time. I can follow my intuitions as a founder, and no one can tell me no.

For this to work, I need to budget for a fast internet connection and at least $200/mo in tokens. This is table stakes for gaining exposure to the unbounded upside. These costs are not nothing, but, speaking as an entrepreneur, it is far easier to get going from a standing start today than it was a few years ago, when you would have had to form a team and raise a round to start finding PMF. I’m also budgeting for conference travel, since the downside of living in a low-burn locale is missing out on the network effects of a city like San Francisco or New York. Conferences create condensed versions of this network effect. So, 90% building, 10% high-intensity networking. Another barbell.

After don’t die, my next priority is GLHF: Good Luck, Have Fun. In a greenfield, having fun maximizes your chances for good luck:

Another clue to the importance of novelty in innovation is that humans tend to be very sensitive to it. Often we feel the urge to explore a particular path or idea despite being unsure where it might lead. Our intuitions and hunches often prod us in directions that might not be justified objectively but still lead to something different or interesting. So it’s no coincidence that the concept of interestingness comes up naturally when discussing novelty. When an idea feels genuinely novel, that’s often enough to make us curious. The idea interests us even if its ultimate purpose is unclear.
(Kenneth Stanley, “Why Greatness Cannot Be Planned”)

Your novelty-seeking impulse is the compass evolution gave you to explore the unknown. Objectives often lead us astray in unknown territory, whereas finding and following the fun can help us discover potential exponentials.

To find the fun, we need beginner’s mind, to let go of preconceptions that were formed in the old environment. We need to take off the mask of the expert, and put on the mask of the hacker.

The Hacker - seeking surprise, steering by gut. The spontaneous disruptor demon who tinkers, breaks and modifies systems, discovers first principles, and unlocks new leverages along the way. The wizard, the pharmacist, the magician, the trickster.
(Ian Cheng, 2019, “Who worlds?”)

So, demos over memos. Build to think, and log what you learn. As in any new greenfield, nature favors fast-moving r-selectors.

Another way to maximize good luck is to make more bets with low cost and high upside. The lower the cost, the more bets you can make. My cofounder and I have been working to reduce the marginal cost of making bets by building AI tooling. This is sort of an engine-building game:

• We’ve been working on a multi-agent factory that can generate high-quality prototypes while we sleep. Coding agents have already increased my velocity by about 3x. I expect agent factories will be another step-change (10x?).

• We’ve also been building a Web-component-based generative UI toolkit, designed to help agents piece together high-quality interfaces.

• All of our infra is set up for Continuous Deployment (CD). Every change is automatically tested and immediately released to production. We ship at the speed of git push.

Soon, most of those pushes will come from our agent factories. Agents writing code, testing code, shipping code. The goal here is to be able to riff on an idea, rapidly generate a prototype with an agent factory, test for PMF, repeat.

Two hackers, hundreds of agents, scale bounded only by the number of tokens we can usefully burn. This feels like the way forward, a new way to build a venture. Will it work? Let’s find out.

Good luck. Have fun. Don't die.

It is 2026, and agents can code, which means everyone is building software. The number of new git repos is increasing exponentially, and Github is struggling to keep up.

Open source is r-selected now. What does this massive glut of new software mean?

A grim ferryman guards these floods and rivers, Charon, of frightful slovenliness; on whose chin a load of gray hair neglected lies; his eyes are flame: his vestments hang from his shoulders by a knot, with filth overgrown. Himself thrusts on the barge with a pole, and tends the sails, and wafts over the bodies in his iron-colored boat, now in years: but the god is of fresh and green old age. Hither the whole tribe in swarms come pouring to the banks, matrons and men, the souls of magnanimous heroes who had gone through life, boys and unmarried maids, and young men who had been stretched on the funeral pile before the eyes of their parents; as numerous as withered leaves fall in the woods with the first cold of autumn, or as numerous as birds flock to the land from deep ocean, when the chilling year drives them beyond sea, and sends them to sunny climes. They stood praying to cross the flood the first, and were stretching forth their hands with fond desire to gain the further bank: but the sullen boatman admits sometimes these, sometimes those; while others to a great distance removed, he debars from the banks.
– Virgil, Aeneid, VI. (Davidson translation)

Every abundance creates new scarcities, because scarcity is not absolute, it is a difference between rates. As software goes from supply-constrained to demand-constrained, the scarcity shifts from creation to attention. Why should anyone notice you in the crowd?

What information consumes is rather obvious: it consumes the attention of its recipients. Hence a wealth of information creates a poverty of attention, and a need to allocate that attention efficiently among the overabundance of information sources that might consume it.
- Herbert A. Simon

This is what it takes for your free and open source project to be recognized in 2026: you must secure the endorsement of legendary actress Milla Jovovich. You know, like a celebrity vodka.

There is a fixed amount of scarce attention to go around, and too many people want it. The metagame becomes: secure attention by any means necessary. You can draw some attention by performing stunts, and you can direct attention with influencers or celebrity endorsements. However, the scale really kicks in when you secure distribution from a platform that owns users, a platform such as Facebook, Google, the App Store, or OpenAI. These platforms can push supply to create hits. Of course, this means platforms have extreme power over who lives and who dies. The platform becomes a kingmaker and can leverage control over demand to extract outsized taxes from supply.

Hal Varian recognized as much when he published his famous paper presaging the Google ads monopoly, but because this was the 90’s, and because the Berlin Wall had fallen, and because markets were going to fix everything, and because Google was Google, Hal Varian then designed the most mathematically efficient and fair ad auction system that is theoretically possible: the Georgist-land-tax-inspired Second-Price Vickrey Auction. Unfortunately, we are not in the 90’s anymore. The vibe is less policy wonks, more bad emperors. Expect strong power laws.

In the last 4 months, my workflow has changed repeatedly, from code completion, to coding agents, to multiple agents in multiple worktrees, to agent factories. I’m about 3x faster, and I suspect I can ratchet this up to 10x with factories. At the same time, I feel keenly aware that I am just a hair’s breadth ahead in the Red Queen Race, with selection pressure nipping at my heels.

Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!
(The Red Queen in Lewis Carroll’s Through the Looking-Glass)

This is what it feels like to live through disruption. The situation gets into your OODA loop and it’s hard to stay oriented. You just keep moving as fast as you can.

This poses a challenge when writing. See, when I write, it is usually to capture a speed run through an idea maze. For example, I explored the idea maze around decentralized software for about 5 years, and came away with a map of paths that work (user-owned keys and hash addressed data), and paths that seem like they should work, but are dead-ends (flat p2p network topologies). It took a long time to map these paths. They are highly compressed models of the problem space.

I struggle to develop this kind of highly-compressed model for AI. A model is a map of the parts of a system that aren’t changing. But during a disruption, everything changes. Value chains dissolve and are reformed, and the competitive landscape goes from clear to chaotic. If you try to build a complex model in a chaotic environment, it will end up being overfitted, and will get obsoleted faster than you can build it anyway.

God is very cruel. He only gives us data about the past.
-Paraphrasing Clayton Christensen

When data is really bad, you should use the simplest model at hand. When data is very good, you can use complicated models.
-SFI Podcast Apr 6, 2020

Really, when things are moving this quickly, we don’t want a model, we want a log. It’s the simplest narrative structure that could possibly work. Just lines of timestamped comments, one after the other: “this happened, then this happened, then this happened”. No higher-level analysis. In software, we log everything that happens during program execution, because logs are invaluable when things spin out of control. We can comb through the log to find patterns, and begin to form higher-level hypotheses about what is happening.

I think this is the right level of sense-making for the moment. It’s time to drop to log level. You’ll see me shifting away from essays, toward work in progress, technical posts, fragmentary ideas, and raw logging.

In/out:

Out: essays.
In: logging what I learn, as I learn it.

Out: theory.
In: practice.

Out: good writing.
In: good ideas.

Out: “having an audience”.
In: hoarding things I know how to do.

1. Encounter a complex programming challenge

2. Get three papers related to my problem

3. Open three terminal windows, have separate Claudes read each paper

4. Ask some questions about each paper

5. Save a summary of each conversation to an .md file.

6. /clear

7. Have Claude read all three summaries. Generate a synthesis with a comparisons table.

8. Save to synthesis.md.

9. /clear

10. Include @synthesis.md and brainstorm with Claude

11. A solution appears

This works great for learning speed-runs, too.

1. Go to plato.stanford.edu and get pages for three different philosophers (Plato, Kant, Nietzsche, say)

2. Open three terminal windows, have separate Claudes read each page

3. Ask some questions about each philosopher

4. Save a summary of each conversation to an .md file.

5. /clear

6. Have Claude read all three summaries, synthesize, compare and contrast.

7. Save to synthesis.md.

8. /clear

9. Include @synthesis.md and have a conversation

(Claude Code is an excellent tool for thought, by the way.)

I think of this move as folding context, because it feels like folding dough when baking. The results I get from the AI are much, much better when I fold the context.

Why is folding context so effective? Well, it’s almost like we’re doing Deep Research by hand. Each Claude instance is functioning as a research agent. Critically, these are research agents that we are guiding manually. In each thread, we’re asking questions that draw out the dimensions of context that are most meaningful to our larger question. It’s a kind of smart compression, and compression = intelligence, or close enough.

Context folding also creates useful byproducts. These little markdown files are valuable compressed insights that you can include in future conversations to infuse them with deep contextual background. Our team has started checking them into the codebase under the docs directory.

Context folding is one example of a more general pattern for provoking effective behavior from LLMs. When we fold context, we diverge, exploring separate paths in different context windows. After exploring the solution space, we converge, comparing what we have learned, and synthesizing everything together.

Claude Code’s Plan mode is another example of this pattern. First Claude diverges, exploring the codebase with sub-agents, then Claude converges, writing up a plan that synthesizes the findings.

Designers call this process the diamond model. When using the diamond model, we often do two passes, one for research, one for development. Most AI tools today do just one pass (Plan mode). Are there gains to be had in doing more than one pass?

Cyberneticist Horst Rittel situates the diamond model within a larger theory framework. He says design is “the generation of variety and the reduction of variety.”

Variety here means cybernetic variety, as in the set of all possible behaviors that a system can generate.

Ashby’s Law of Requisite Variety: The variety of a regulator must be at least as large as that of the system it regulates.

Ashby’s Law tells us that a solution must be at least as complex as the problem. If it isn’t, the problem spills over, routes around the solution, becomes an externality. This is useful information. It tells us that to solve a problem the LLM has to be at least as large as the problem.

And LLMs do have a lot of cybernetic variety. An internet’s worth. This extreme variety manifests when you run a raw base model. What you get back is inhuman, the rantings of someone channeling hyperdimensional cosmic horrors. A base model’s variety is way beyond the range of normal human behavior.

So, LLMs have a lot of variety. Too much variety to fit within the tiny reference frame of human meanings. The solution? Slap a smiley face on top. RLHF reduces the variety of LLMs to meaningful ranges.

But RLHF reduces variety almost too much. The model comes away with a strong tendency to seek toward oatmeal. It has lost the requisite variety to surprise.

But being in control means defining the range of what will be considered, that is, the range of the possible. In effect, when I am in control I restrict the world to what I can imagine or permit…
(Ranulph Glanville, 2019, “Design Cybernetics”)

We can bring back some of this variety through the context window. LLMs are highly steerable via the context window, and through prompting, you can sort of pluck at the latent dimensions of the model, drawing out distinct behaviors.

This is why putting an LLM in a loop with tools makes it so much smarter. Tools add contextual variety to the context window, which educes latent variety from the model. The conversation between model and outside context generates meaningful behavior that has the variety to surprise.

OpenClaw is an extreme example here. When you give a claw full access to your computer, it imports the variety of a high-level Turing machine into the agentic loop. That’s a lot of variety, potentially unbounded. Some of that variety is deeply surprising, like when OpenClaw’s creator discovered it could figure out how to do voice transcription on its own. Some of that variety is negatively surprising, like when you ask your claw to tidy up your inbox, and it deletes all of your emails. Either way, a claw with full bash access has more than enough variety to surprise.

The great benefit of not having enough variety to control a system is that, if I give up trying to control, I can discover many possibilities I would have excluded if I had insisted on being in control. These possibilities are unexpected, outside my frame of reference, in a word, novel.
(Ranulph Glanville, 2019, “Design Cybernetics”)

From the standpoint of requisite variety, folding context makes a lot of sense. We’re letting our agents’ understandings diverge, specialize, and spin off in unexpected directions. The difference in their understandings, the contradiction, is alpha, valuable variety.

Do I contradict myself?
Very well then I contradict myself,
(I am large, I contain multitudes.)

Questions I’m asking myself:

• Where does the variety live? In the agent? In me? In the loop between the agent and me?

• Who has requisite variety? Who is steering the system? The agent? Me? Neither? Do we have requisite variety together?

• Can I increase variety by spinning up agents in divergent roles? Busytown is my current attempt at this, a multi-agent swarm coordinating over SQLite.

• Is the variety manifesting within meaningful parts of the possibility space? What is meaningful to me? Over the short term? Over the long term? Can I craft agentic systems that manifest deeper meaning over time?

• Erich Fromm said, creativity requires the courage to let go of certainties. Is my notion of meaning constraining me to oatmeal? Do I need to increase the variety of my agentic systems? Do I need to lose some control? Where can I embrace threats to meaning, to generate creative breakthroughs?

You can listen to the episode on YouTube, Spotify, Apple Podcasts, and anywhere else you might get podcasts.

Our conversation covers a lot of ground: we discuss scenario planning, how it works, the difference between risk and uncertainty, why it can be useful to hold multiple futures in superposition, and how AI might improve our strategic thinking.

Sam is an intellectual hero of mine. Scientist in Residence at Lux, a research fellow at the Long Now Foundation, he also has a great Substack, and a website full of fascinating rabbit holes, like this catalog of para-research organizations. Joining his podcast was an honor.

Eno was an early pioneer in the field of generative music. His Music for Airports is an example. It is composed of multiple tape loops—literal loops of tape, spliced together so they can be played around and around, indefinitely.

Eno stitched each loop together at a different length, winding tapes around the room, through chair and table legs, and back through the tape player. When played together, these tape loops gently phase in and out of relationship to each other, creating complex musical patterns that are rarely, if ever, repeated.

It’s a cybernetic approach to composition. Music as a system. As Eno puts it,

My contention is that a primary focus of experimental music has been toward its own organization, and toward its own capacity to produce and control variety, and to assimilate “natural variety” — the “interference value” of the environment. Experimental music, unlike classical (or avant-garde) music, does not typically offer instructions toward highly specific results, and hence does not normally specify wholly repeatable configurations of sound…. I hope to show that an experimental composition aims to set in motion a system or organism that will generate unique (that is, not necessarily repeatable) outputs, but that, at the same time, seeks to limit the range of these outputs.
(Brian Eno, 1976, Generating and organizing variety in the arts)

He later contrasts this bottom-up generative approach to the top-down approach of traditional musical scores. In a traditional score, you play the music. In a generative score, you play with the system that plays the music.

It seems to me that AI agents turn all of us into generative composers. Instead of writing the code, we write a generative score for agents to write the code. Instead of playing the music, we’re playing the system.

If you’re a programmer, this isn’t exactly new. We don’t actually write the ones and zeros the computer executes. We haven’t done that in a long time. Instead, we write the code that writes the code that writes the code that writes the ones and zeros.

So, in a sense, an AI coding agent just adds another layer to the cake. Agents generate code, which generates code, which generates code… However, the critical difference with agents is in the expressiveness of the generative system. Sure, a programming language like JavaScript allows us to express ourselves using higher-level concepts, and these are later compiled into ones and zeros. Yet JavaScript is still a formal language. It describes exact instructions, and the same script will generate the same exact instructions, every time. This is a bit like the traditional musical score, specifying how to play the music within fairly tight tolerances. A coding agent, by contrast, takes an English prompt, and extrapolates it into code. The agent is making an intuitive leap, from informal language, to a formal language, from a gesture, to a fully-specified set of instructions. There is a lot of ambiguity in that extrapolation process. The same prompt may generate different programs each time it is run.

But what if we see this ambiguity as a creative opportunity? Take Terry Riley’s In C, another generative piece. Its score is unusual:

All performers play from the same page of 53 melodic patterns played in sequence.

Any number of any kind of instruments can play. A group of about 35 is desired if possible but smaller or larger groups will work. If vocalist(s) join in they can use any vowel and consonant sounds they like.

Patterns are to be played consecutively with each performer having the freedom to determine how many times he or she will repeat each pattern before moving on to the next. There is no fixed rule as to the number of repetitions a pattern may have, however, since performances normally average between 45 minutes and an hour and a half, it can be assumed that one would repeat each pattern from somewhere between 45 seconds and a minute and a half or longer.

There’s a lot of ambiguity here. That ambiguity results in radically different performances. So here is a performance with Terry Riley,

…and another one, this time incorporating kora, balafon, and tama.

…and my personal favorite, by Invisible Polytechnic. It’s so energetic and cheerful.

The ambiguity of the instructions is what makes In C so special. There is no one exact way to play it. Individual performers are given the freedom to interpret the instructions for themselves, making every performance a surprise to the audience, and to the performers.

Instead of trying to specify it in full details, you specify it only somewhat. You then ride on the dynamics of the system in the direction you want to go.
(Stafford Beer, 1972, “Brain of the Firm”)

How might we adopt this creative stance toward AI agents?

There is no “correct” version of In C. The variety is the point… which is another way to look at this. In traditional programming, the coder has requisite variety to control the system, which is another way of saying that the system we’re working with, the system of code and compilers, is just not that complex. Its behavior can fit into our head.

Ashby’s Law of Requisite Variety: If a system is to be stable, the number of states of its control mechanism must be greater than or equal to the number of states in the system being controlled.

But working with an AI agent is different. Some of the complexity gets transferred out of our head, and into the head of the agent. The agent gains variety. Much more variety than a compiler. By working with it, we sacrifice some of our requisite variety, and lose some of our direct control over the system. But what if that’s good? Can we work with variety as a creative material?

How would Dwarf Fortress think about this? “You basically have a group of dwarves, and they mine in the mountains. You don’t control any specific dwarf, but you just kind of order their general activities…” Maybe the future of creative work looks more like Dwarf Fortress?

What if, as Eno suggests, our role as programmers, artists, designers, and thinkers, expands beyond playing the music, to playing with the system? To sculpting the variety of our agentic systems?

The research methods that ground Deep Future have roots in the Cold War, when RAND began adapting ideas from game theory and systems theory toward military strategy. By mapping the systemic forces driving change we can trace the outlines of futures that may emerge as forces collide. It’s a bit like forecasting, except instead of making specific predictions, we hold multiple scenarios in superposition, and use the contrasts like a wind tunnel.

Why map multiple futures instead of making particular predictions? The answer boils down to uncertainty. When uncertainty is within bounds, we can deploy the tools of risk management; things like portfolio theory, forecasts, and classical decision theory. However, extreme uncertainty fundamentally changes the strategic terrain. The heavy machinery of classical decision theory gets bogged down in the mud. Scenario planning, developed to help navigate the extreme uncertainty of conflict, can offer some traction.

Risk and uncertainty are two different things

The first thing to recognize is the distinction between uncertainty and risk. Risk is when you know the possible outcomes, and can assign probabilities to those outcomes. Uncertainty is when you don’t know the possible outcomes. These are two very different kinds of strategic situation.

Uncertainty must be taken in a sense radically distinct from the familiar notion of Risk, from which it has never been properly separated.... The essential fact is that ‘risk’ means in some cases a quantity susceptible of measurement, while at other times it is something distinctly not of this character; and there are far-reaching and crucial differences in the bearings of the phenomena depending on which of the two is really present and operating.... It will appear that a measurable uncertainty, or ‘risk’ proper, as we shall use the term, is so far different from an unmeasurable one that it is not in effect an uncertainty at all.
(Frank Knight, Risk, Uncertainty and Profit)

Rolling a six on a die is a risk. All of the possible outcomes are known and quantifiable. Aligning AGI is an uncertainty. The possible outcomes are unknown, and unquantifiable. We’re not sure what the space of possible intelligences looks like. We don’t know which paths through that space lead to alignment. We don’t even know if our concepts of alignment and intelligence are well-posed.

A pivotal question here is if we can identify the set of all outcomes. If we can, we’re dealing with risk. We can calculate expected utility and use classical decision theory. If we can’t, we’re dealing with Knightian uncertainty.

When we don’t know the possible outcomes, it is difficult to assign them meaningful probabilities. We have to grapple with uncertainty on its own terms. If we treat it like risk, it becomes too easy to assign false precision to unknowns, or just ignore the things we can’t quantify.

Uncertainty defines the strategic environment

If we can’t quantify uncertainty, we can at least classify it. One useful heuristic is to divide uncertainty into four levels:

• Clear environments are defined by known-knowns. The relationship between cause and effect is obvious.

• Complicated environments hinge on known-unknowns. The important factors are knowable. There are direct relationships between cause and effect, but they might require expert knowledge and analysis to understand.

• Complex environments are full of unknown-unknowns. The behavior of the environment is nonlinear. The relationship between cause and effect is indirect. The set of all possible outcomes is unknown, and often computationally irreducible.

• Chaotic environments are structureless. The relationship between cause and effect is untraceable. Future states are unknowable and radically uncertain.

Production lines are clear, rocket science is complicated, climate change is complex, stampeding crowds are chaotic. If you don’t know which one you’re dealing with, you’re confused.

These quadrants correspond to distinct phase transitions we can observe in ecosystems. We could say clear, complicated, complex, and chaotic are archetypal patterns of behavior that emerge in ecosystems as they spiral upward in complexity. The increasing structure generates repeated patterns. More structure, more pattern, less uncertainty. Less structure, less pattern, more uncertainty.

Different environments require different strategies

Clear environments are dominated by risks. Complicated, complex, and chaotic environments are dominated by varying degrees of uncertainty.

A clear environment is basically a closed system. The rigid structure of clear environments generates very predictable patterns of behavior. The relationship between cause and effect is well-known. Decision theory is a no-brainer here. The important system states are all known and quantified, and we can easily calculate the expected utility of various strategies. At the extreme, we might even be able to apply automated optimization strategies.

Complicated space involves moderate amounts of uncertainty. The critical unknowns are mostly knowable in principle. However, putting bounds around these unknowns usually requires expert analysis.

An important quality of complicated and clear environments is that they tend to be ergodic, in the sense that we can poke the system without causing any fundamental changes to its structure or behavior. The relationships between cause and effect are linear. We can probe, measure results, and put bounds around key uncertainties. This allows us to apply optimization strategies, such as hill-climbing.

Superforecasting is highly effective in complicated environments. Detailed analysis of what is known allows a superforecaster to make highly educated guesses about what is not. The ergodic nature of complicated systems also means that we can often probe the system, identify possible outcomes, assign them probabilities, and practice Bayesian updating, without blowing anything up.

Things start to get muddier in complex and chaotic environments.

In chaos, all bets are off. Chaotic systems have no discernible structure, so prediction becomes almost useless. What we need are fast reflexes. Keep your eyes peeled, your ears open, and stay on your toes. This means expanding the Observe phase of the OODA loop, keeping Orientation simple, and Deciding and Acting as quickly as possible. The only success metric here is survival.

Complex environments are also dominated by uncertainty. However, unlike chaotic systems, there are patterns here. These patterns are driven by interacting feedback loops.

Because complex systems are driven by feedback, linear strategies that work in simple or complicated environments can generate unintended consequences in complex ones. To give a particularly stark example from The Great Leap Forward, when grain harvests didn’t meet expectations, sparrows were blamed for eating seeds and causing the shortfall. Therefore, the Party decided to eliminate the sparrows. Citizens were encouraged to kill sparrows by any means: shooting them down, throwing rocks, destroying nests. Hundreds of millions of sparrows were wiped out. A Soviet scientist present at the time recounts,

The results of this extermination drive were felt soon enough. The whole campaign had been initiated in the first place by some bigwig of the Party who had decided that the sparrows were devouring too large a part of the harvests… Soon enough, however, it was realized that although the sparrows did consume grain, they also destroyed many harmful insects which, left alive, inflicted far worse damage on the crops than did the birds. So the sparrows were rehabilitated. Rehabilitation, however, did not return them to life any more than it had the victims of Stalin’s bloody purges, and the insects continued to feast on China’s crops.
(Mikhail Antonovich Klochko, 1961. Translation by Andrew MacAndrew)

This man-made plague of locusts reduced harvests by 20%, leading to the deaths of two million people.

It is an extreme example, but characteristic of the disasters that happen when linear optimizers plow headlong into complex situations. Complex systems do not react to linear force in linear ways. This is because feedback loops make the relationship between cause and effect circular. The harder we try to optimize toward the goal, the more energy we pump into feedback loops. Eventually, some loop spins out of control, and the system kicks back.

“You see, when you get circular trains of causation, as you always do in the living world, the use of logic will make you walk into paradoxes. Just take the thermostat, a simple sense organ, yes? If it’s on, it’s off; if it’s off, it’s on. If yes, then no; if no, then yes.”

With that he stopped to let me puzzle about what he had said. His last sentence reminded me of the classical paradoxes of Aristotelian logic, which was, of course, intended. So I risked a jump.

“You mean, do thermostats lie?”

Bateson’s eyes lit up: “Yes-no-yes-no-yes-no. You see, the cybernetic equivalent of logic is oscillation.”

(Interview with Gregory Bateson)

And it’s never just one loop. Imagine how multiple loops might feed into each other, damping or amplifying each other. You can see how the relationship between cause and effect becomes very complex indeed. Even small actions can produce big effects. The right move can generate exponential returns, or exponential collapse. The stakes are high.

There is no way to be a passive observer in such a complex system, since probing the network can alter its patterns of behavior in dramatic and irreversible ways. Complexity is non-ergodic, not a marble in a bowl that will roll back into equilibrium, but a dancing landscape, with multiple attractors, constantly changing, and being changed by our actions. It is difficult to assign probabilities to a fixed set of outcomes, when, in trying to discover the set of possible outcomes, we change the set of possible outcomes.

Scenario planning is for navigating complexity

To survive complexity, we need to accept some uncertainty. This means letting go of the optimal outcomes promised by expected utility. Instead of an optimal strategy, we want a robust strategy. We want to become antifragile to a wide range of possible plot twists.

This is where scenario methods come in. The first thing scenario planning helps us with is identifying major drivers and ballparking their level of uncertainty and potential for impact. During scenario research, we systematically catalog the forces driving change, tracking trends across social, technological, environmental, economic, political, and other categories. Maybe we can’t pin exact numbers to everything, but we can spot many of the unknowns and put bounds around them. Systematically cataloging and grading forces like this often surfaces important strategic factors that would otherwise be missed. We especially want to keep an eye on weak signals that could have high potential impact. Using superforecasting techniques can be very high-leverage here, and in fact, the kind of cataloging and grading we do in this phase looks a lot like the detailed estimation that a superforecaster does before making a forecast.

Another thing that scenario planning helps with is mapping connections between forces and between actors in the environment. This surfaces many of the feedback loops that can generate nonlinear behavior in a complex environment. Spotting these feedback loops can give us a good sense of what might spin out of control, or, taking another perspective, where the systemic leverage points are.

Using this map of our strategic environment, we can also generate numerous research-grounded scenarios. These scenarios emerge from the intersection of trends that we can point to in our environment today. Rather than attempting to predict one or the other future, we use these scenarios—particularly the divergent scenarios—to wind-tunnel strategies. This helps us develop strategies that are robust across many possible futures. We can even develop multiple contingency plans to deploy in one scenario or another.

Most interesting to me, scenario planning can help us shape the future by articulating a range of possible futures we can aim for. Used in this way, a scenario is prescriptive rather than descriptive. Instead of debating the odds of a scenario like a spectator, we can use scenario planning to tilt the odds in our favor. The best way to predict the future is to create it, after all. In this view, scenario planning is more like map of leverage points that we can push on, to try to bring about particular futures.

Reality is bigger than any one model

These are all just heuristics. Reality is never just one thing. Real strategic challenges involve a wide range of problems and sub-problems, some clear, others complicated, complex, chaotic, or in-between.

I was chatting with Nuño Sempere about all of this recently. Nuño is an advisor to Deep Future and a superforecaster who’s team won the CSET-Foretell forecasting competition by a surprising margin—“around twice as good as the next-best team in terms of the relative Brier score”. So Nuño is someone you want to listen to when it comes to the future. Anyway, he described the experience of trading between foresight and forecasting techniques as almost a yin-yang kind of thing. The skilled strategist freely borrows from a wide repertoire of strategic tools, including forecasting, scenario planning, decision theory and everything else. This instinct is a kind of tacit knowledge learned in the trenches. Can we infuse some of it into an AI agent? I’m optimistic.

We’re developing Deep Future alongside a limited number of exclusive founding partners. Interested? Reply to this email, or join the waitlist.

Picture this: you’re reading a news story about rare-earth minerals. Curious, you fire up the Deep Future agent and run a rapid analysis. In the time it takes to finish your morning cup of coffee, it has developed a detailed analysis covering supply chains, chips, defense tech, possible scenarios, a list of the forces driving change, early warning signals, and strategic leverage points. Deep Future has completed a multi-day strategic analysis in 15 min.

My research in this area has been supported by The Future of Life Foundation as part of the AI for Human Reasoning program. FLF believes AI can augment intelligence. I agree. If you follow this newsletter, you’ll know that I’ve long been interested in using AI to accelerate the OODA loop. Scenario planning is a promising place to start.

Thinking in scenarios

Everyone has a plan until they get punched in the face.
- Mike Tyson

Scenario planning emerged during the Cold War, when the US military and RAND started to adapt ideas from game theory and systems theory to make sense of the new strategic landscape. At its core, scenario planning tackles a fundamental challenge: how do you make plans in an unpredictable environment?

When your environment is predictable, strategy is simple. You identify a goal, plan steps toward your goal, carry them out. But our environment is seldom predictable. We live in a networked world, a world governed by asymmetry, feedback loops, and power laws. The US Army and Navy War College has an acronym for this kind of world: VUCA.

Volatile
Uncertain
Complex
Ambiguous

Plans that work in stable environments fail in VUCA environments. They are too brittle, because they depend upon prediction in an unpredictable world. VUCA environments demand a different approach. But if you can’t predict, how do you plan?

Picture your future as a cone. This cone represents the space of all possible outcomes: good, bad, everything in-between. The further into the future we go, the wider the cone of possibilities becomes.

Traditional planning traces a single path through this cone, the preferable path, a direct path toward your goal. But this is like drawing a line between two points and claiming you’ve drawn a map. Sure, we can follow that line and hope for the best, but the line doesn’t give us any sense of scale or orientation. It doesn’t tell us anything about the territory. While following that line, we might run into mountains, get mired in swamps, or walk off of cliffs. Worse still, the further we get into the future, the less predictive the line will be! Any errors will compound, until we find ourselves way off of our intended course.

Drawing one line isn’t enough. The preferable path articulates what we hope will happen, but hope is not a strategy. We need to map more territory! This is where scenario planning comes in.

Scenario planning traces multiple paths through the cone of possibility. Each of these paths cuts through a different part of the cone. Between them, we end up covering a broad radius of potential outcomes. Tracing these paths is not about predicting. It is about exploring the space of the probable, plausible, and possible.

How does this work?

The future is already here, it’s just not evenly distributed.
-William Gibson

We can’t predict the future, but we can identify the forces that are driving change in our environment today. This process of mapping drivers is not speculative. Drivers are trends, issues, projections, obstacles that we can point to, that are happening now, things like demographic changes, technological adoption curves, economic bubbles, environmental tipping points, political transitions… These forces have mass and momentum. If we see them driving change today, we know they will drive change tomorrow.

Systems fool us by presenting themselves as a series of events.
-Donella Meadows

Once we have mapped the relevant forces, we can begin exploring how they are connected into feedback loops that generate exponential growth, collapse, stasis, or transformation. We can also look at how forces sort into pace layers, revealing what is changing quickly, and what is changing slowly. Where fast and slow collide, we find pivot points.

Analyzing forces as systems can help us break out of the trap of linear thinking:

The human mind is not adapted to interpreting how social systems behave. Social systems belong to the class called multi-loop nonlinear feedback systems. In the long history of evolution it has not been necessary until very recent historical times for people to understand complex feedback systems. Evolutionary processes have not given us the mental ability to interpret properly the dynamic behavior of those complex systems in which we are now embedded.
(Jay Forrester, 1971. “Counterintuitive behavior of social systems”)

The complex processes we call “systems” present special challenges to our uneducated imaginations. We tend to think additively, and are constantly surprised when something that seems to be “just added in” causes surprising and often disastrous changes. For example, in 1859 in Australia, Thomas Austin said “The introduction of a few rabbits could do little harm and might provide a touch of home, in addition to a spot of hunting.” The result was not the Australian ecology + rabbits, but an entirely new ecology, which in many cases became a landscape of ruins. None of the efforts since then to “subtract” the rabbits from the ecology have come close to working.
(Alan Kay, 2005. “Enlightened Imagination For Citizens”)

Twice the cause does not mean twice the effect. Actual results will depend upon system structure. Mapping the relationships between forces reveals places where nonlinear change is likely to occur.

Some confluences of forces will be so powerful that they form the outline of an obvious scenario—a large-scale outcome driven by the interaction of multiple forces. After identifying a few of these scenarios, we can triangulate between multiple possible outcomes, and form strategies that are robust across many futures. We can even create multiple plans, contingency plans, that we can deploy if we see ourselves moving toward one scenario or another.

Instead of planning from the inside-out, projecting our hopes onto the environment, we are now planning from the outside-in. We’re mapping the possibility space, then charting paths through it!

It’s a process that produces surprising insights. My favorite thing about scenario planning is how it changes my understanding of the present.

Accelerating scenarios with AI

So where does AI come in? Scenario planning goes through several structured research stages:

1. Framing: Establish a focal question with clear timeframe and scope to guide our research (e.g. “what will cancer research look like in 10 years?”).

2. Environmental scanning: Catalog the forces driving change across multiple areas (Social, Technological, Economic, Environmental, Political…). Map major actors in the environment. Build up a database of research.

3. Structural analysis: Perform various structural analyses, looking at actors and forces, how they interact. Rank forces by impact and uncertainty, pace layer, etc.

4. Scenario identification: Identify a cluster of pivotal forces, typically high-impact forces with uncertainties related to our focal question. Explore how these forces might collide, e.g. by crossing forces up in a 2x2 matrix, or by doing a cross-impact analysis. This yields four or more windows into possible futures.

5. Scenario development: With four or more representative scenarios identified, explore scenarios in-depth. Develop descriptions that help us understand what these futures might look like, how actors might behave within them, what this implies for our focal question. Techniques like wargaming can also be used to dynamically explore scenarios.

6. Signpost monitoring: Develop a list of indicators that act as early warning signals for one scenario or another. Track them regularly.

7. Strategic development: Identify strategies to meet threats and achieve goals across a wide range of scenarios. Develop contingency plans. Identify new uncertainties and questions for future research.

Digging into these stages reveals multiple opportunities for AI to automate or augment the research process. Agents can help search for signals during environmental scanning, work with you to identify forces, perform automated analysis, explore thousands of scenarios, monitor signposts, and more. The data we generate during scanning acts as a ground-truthing mechanism, allowing us to trace our assumptions all the way back to the scanning hits—facts, events, trends—that started our analysis.

Scenario planning has well-developed research methods and processes (TAIDA, Houston Framework Foresight, etc). At the same time, these processes are not simple, fixed, or linear. We might need to change the methods we use within a stage depending on the question, the number of participants, and the context. We might loop back to earlier stages as we learn from our research. It’s the same kind of fluid domain faced by Deep Research:

Research work involves open-ended problems where it’s very difficult to predict the required steps in advance. You can’t hardcode a fixed path for exploring complex topics, as the process is inherently dynamic and path-dependent. When people conduct research, they tend to continuously update their approach based on discoveries, following leads that emerge during investigation.

This unpredictability makes AI agents particularly well-suited for research tasks. Research demands the flexibility to pivot or explore tangential connections as the investigation unfolds. The model must operate autonomously for many turns, making decisions about which directions to pursue based on intermediate findings. A linear, one-shot pipeline cannot handle these tasks.

(Anthropic, 2025. “How we built our multi-agent research system”.)

This kind of dynamic process requires a facilitator with strong intuitions for when to move forward, when to loop back, and when to dive deeper. As Deep Research has shown, agents are surprisingly good at this!

I’m still early in the development process, but the prototypes already feel promising. Deep Future agents are equipped with a MemGPT-like memory system, a handful of tools, and a library of prompts adapted from scenario methods. They can successfully guide you through defining a focal question, identifying forces, analyzing structural connections, and making strategic recommendations. I’m pretty happy with the early results—not as good as an experienced facilitator, but then speed has a quality all its own.

There is also a lot of headroom for improvement. LLMs are getting better at forecasting, a skillset that has critical overlap with strategic foresight. We may soon have LLMs that can predict as accurately as a superforecaster.

And there are areas where AI can already outperform us. Agents are patient. They never sleep. They can do continual environmental scanning, ingesting news feeds, identifying driving forces, updating scenario models, and sending notifications the very millisecond an early warning signal is detected. This kind of signals intelligence used to require a dedicated team of researchers. Now AI brings it within reach of individuals.

Ultimately, by dropping the cost of scenario analysis from days to minutes, we can begin to do high-frequency scenario planning, applying the power of scenario-thinking to more questions, more often.

I’m developing Deep Future alongside a limited number of exclusive founding partners. Interested? Reply to this email, or join the waitlist.

It is a principal aspect of the electric age that it establishes a global network that has much of the character of our central nervous system.
(McLuhan, 1964. Understanding Media)

The medium is the message, McLuhan says. Culture conforms to the shape of communication.

Our medium is the internet, a network that instantaneously propagates electrical impulses around the globe. What does it mean to share this global nervous system?

Our specialist and fragmented civilization of center-margin structure is suddenly experiencing an instantaneous reassembling of all its mechanized bits into an organic whole. This is the new world of the global village.
(McLuhan, 1964)

Like our biological nervous system, the internet creates a kind of holistic field of awareness, at odds with the logic of industrial society, a logic of narrow specialization and hierarchy. Instead, we find ourselves in a condition closer to our state of nature, a new kind of oral culture, where power flows like gossip over the network.

And if you ask me, this transformation predicted by McLuhan is coming to a head. Our 18th century institutions are imploding, 4chan drives national politics, and missiles are launched from the boys groupchat. We live in network society now.

I’m trying to orient myself to this new reality, using McLuhan as a guide. This post is a bit of a brain dump exploring two themes I think will be important: cities and nomads.

Among the people of the world, strange new vortices of power will appear unexpectedly. (McLuhan, 1964)

Since Westphalia, a lot of history has been driven by the nation/country/state. McLuhan would point out that this is a byproduct of organizing society around broadcast technologies, first literature, then airwaves. Now we’re organized around networks. How does this change the political packet size?

Broadcast technologies tend to produce normal distribution curves. Power is thickest at the center of the broadcast, and trails off toward the margin. You can see the social hierarchy in the shape of the curve.

What about networks? Networks generate dancing landscapes with strong power laws that collide, causing unpredictable cascades. Survival under these VUCA conditions often means adopting a barbell strategy.

Anything that promotes ease of travel and communications has a positive effect on state growth and expansion, and vice versa, anything that creates barriers to movement has a negative effect. (Turchin, 2012)

Up to the point just short of electrification, increase of speed produces division of function, and of social classes, and of knowledge. At electric speed, however, all that is reversed. (McLuhan, 1964)

A broadcast has natural borders. There is a center that emits, and a margin that receives. A border begins where the sphere of the broadcast ends.

A network has no border and no center, only hubs and edges. And networks interact with existing borders in strange ways. Networks flow around and through borders like water. Connections constantly form and break, as the network adapts.

The network interprets censorship as damage and routes around it.
(John Gilmore)

Broadcasting is centralized, one-to-many, homogenizing. The same message is sent everywhere, to everyone. Conformism is the ground condition. Collective action happens through shared ideology.

Networks are decentralized, many-to-many. This has radical atomizing, individualizing effects. At the same time, cascades, triggered by broadcast-scale gossip, produce new emergent collective behaviors. These collective behaviors have a will all their own, and the individuals that manifest them may believe radically different, even opposing things.

If bell curves build empires, networks, with their power laws and dancing landscapes, unbundle us into nodes and edges, cities and nomads.

Cities are densely-connected hubs in the network, exhibiting steep power laws that drop off rapidly as you move out from the city center. They are islands in the net, with people and packets routed between.

Village and city-state essentially are forms that include all human needs and functions. (McLuhan, 1964)

Cities are “real” in ways that nations are not. They are made of atoms, not ideologies. A city offers a minimum viable infrastructure stack: food, water, shelter, security, all bundled into one platform, benefiting from dense network effects and economies of scale. An operating system for life.

Cities look to me to be our most characteristic technology. We didn’t really get interesting as a species until we became able to do cities—that’s when it all got really diverse, because you can’t do cities without a substrate of other technologies. There’s a mathematics to it — a city can’t get over a certain size unless you can grow, gather, and store a certain amount of food in the vicinity. Then you can’t get any bigger unless you understand how to do sewage. If you don’t have efficient sewage technology the city gets to a certain size and everybody gets cholera.
(William Gibson, Paris Review, Summer 2011)

How do cities emerge? Well, Paris and London are river cities. Constantinople sits at the end of the Silk Road. New York is a port. Cities seem to emerge around some stock or flow of resources, like rainforests emerge around precipitation patterns, and life emerges around energy gradients.

Cities outlive civilizations. You can see this in the oldest cities, like Rome, where layers of civilizations accrue like geological strata.

Cities are like compost heaps—just layers and layers of stuff. In cities, the past and the present and the future can all be totally adjacent.
(William Gibson, 2011)

How long does a city live? Probably as long as the underlying resources continue to flow.

Instead of being automated themselves—fragmented in task and function—as had been the tendency under mechanization, men in the electric age move increasingly to involvement in diverse jobs simultaneously, and to the work of learning, and to the programming of computers… Man the food-gatherer reappears incongruously as information-gatherer. In this role, electronic man is no less a nomad than his paleolithic ancestors.
(McLuhan, 1964)

Understanding Whole Systems
Shelter and Land Use
Industry and Craft
Communications
Community
Nomadics
Learning
(Table of Contents, The Whole Earth Catalog, 1968)

Every technology retrieves something from the past. McLuhan posits that networks retrieve nomadics.

And indeed, a lot of technological innovation seems directionally aligned with networked nomadism. The energy transition is pushing us to electrify everything. Solar panels and lithium batteries allow for cheap decentralized power generation. Software drives miniaturization and ephemeralization in many areas.

The really big theme I’d like to emphasize… is the importance of being able to substitute a control system—sensors and computers—for actual materials. We are actually now replacing atoms with bits.
(Saul Griffith, Otherlab. Soft not Solid @ O’Reilly)

The upshot is that you can construct a pretty viable nomadic stack today for a few thousand bucks: solar panel, battery, Starlink, induction stovetop, pressure cooker, laptop…

There are already more than 40 million digital nomads worldwide today. We should expect that number to increase, both due to networks, and to climate migration.

Industrialization demanded specialization and fixed roles for working with special-purpose machines. By contrast, electricity, automation, computing, are all general-purpose technologies. Computer-driven tools like CNC routers, 3D printers, and robotic arms can be programmed for an open-ended range of tasks on the fly. McLuhan sees networks pushing more and more of production into this software-defined direction. You get the picture he envisions something like dark factories.

So, AI and automation increasingly absorb the scalable aspects of production. That leaves us to putty over the cracks. “Work” takes on a DIY/jugaad quality, focused on creatively hacking together powerful resources to solve contextual problems.

You have access to a pocket supercomputer, hundreds of AI agents, and The Hitchhiker’s Guide to the Galaxy. What can you do with that?

We are suddenly threatened with a liberation that taxes our inner resources of self-employment and imaginative participation in society. This would seem to be a fate that calls men to the role of artist in society.
(McLuhan, 1964)

A realm of intimate, personal power is developing—power of the individual to conduct his own education, find his own inspiration, shape his own environment, and share his adventure with whoever is interested.
(Introduction to The Whole Earth Catalog, Spring 1969)

Maybe The Whole Earth Catalog and the 1960’s back to the land movement weren’t wrong, just early? Maybe they were hints of a future that was already here, just not evenly distributed.

The first cities were parties. People didn’t live there full-time. Places like Göbekli Tepe were Schelling points where nomads would gather in summer to party and hook up and trade.

“The line is blurring between remote workers and tourists,” Bloomberg reports, “For years, cities, states and regions have been competing to lure corporate headquarters and offices… But the remote revolution is upending this traditional model of economic development. The last two years of pandemic have accelerated previous trends, shining a spotlight on an alternative to the corporate sweepstakes, one in which cities chase the workers themselves.”

With people going nomad, cities take on the role of ritual pilgrimage site once again.

Art at its most significant is a Distant Early Warning System that can always be relied on to tell the old culture what is beginning to happen to it. (McLuhan)

As usual, artists are ahead of the game. Every year, for the last 39 years, Burning Man has constructed and dismantled a city as performance art. Mars College offers a freeschool in the desert with a DIY off-grid residential program. Edge Esmerelda takes the hacker house and expands it into a pop-up city.

Distant Early Warning System: cities are routers in network society.

Queries:

I’m surrounded by smart readers, and so I would love your help with some of the questions I’ve been exploring:

• Due to a life plot twist, I’m moving to Nairobi, Kenya in two weeks. Who should I meet?

• There’s a kind of “spherical cow” version of networked manufacturing where everything gets manufactured on-demand via 3D printing, robotics, etc. However, last time I explored this area, there were bottlenecks preventing decentralized manufacturing from reaching scales where it displaces traditional manufacturing… Stuff like 3D printer feed rates, etc. Where are these bottlenecks? Which are likely to be permanent? Which are likely to experience breakthroughs?

• I’ve been completely floored while revisiting McLuhan’s Understanding Media. Who else is thinking deeply about these themes? Who should I read?

Reply to this email and let me know!

McLuhan absolutist, as in Marshall McLuhan, as in the medium is the message. And the more I think about it, the more I think he’s right. More than any other lens, McLuhan is the key to understanding our present moment.

So what is McLuhan absolutism? If you’re like me, you’ve probably heard the medium is the message, and thought to yourself “Got it. Media influences culture”.

No. It’s not that media influences culture. The medium is the culture.

Medium, as in Petri dish. Medium, as in the thing in which the culture grows.

All media work us over completely. They are so pervasive in their personal, political, economic, aesthetic, psychological, moral, ethical, and social consequences that they leave no part of us untouched, unaffected, unaltered.
(Marshall McLuhan, 1967. The Medium is the Massage)

Without a medium, there is no culture.

• Without language, there is no recitation of genealogies, so there are no tribes.

• Without writing, there is no accounting, so there are no empires.

• Without print, there are no novels exploring the depth and diversity of subjective experience, so there is no individualism.

• Without broadcast, there is no mass transmission of ideas, so there is no mass society.

Language creates tribes, writing creates empires, print creates individualism, broadcast creates masses.

What does the network create? What would McLuhan absolutism predict?

What is the shape of network society? Let’s trace the outline, and begin to form an intuition.

First, what media defined the last four cultures?

Oral: folklore
Literary: books
Broadcast: TV, radio
Network: social media, AI

The medium is the message because the medium is the thing through which the message flows. So how does information flow through these media?

Oral: circular
Literary: sequential
Broadcast: one-to-many
Network: many-to-many

Since the behavior of a system is determined by the structure of its flows, media determine the behavior of the system. Broadcasting radiates in every direction, generating normal distribution curves. Networks, on the other hand, receive, repeat and amplify, creating traffic spikes, cascading failures, runaway viral memes. Networks generate exponentials.

Broadcast: normal distributions
Network: exponential distributions

These exponentials are fractal, displaying power laws at every level. Networks are highly unequal. At the same time, networks are fluid, so the balance of power is constantly shifting. Broadcast power tends to be symmetric. Network power is asymmetric.

Broadcast: symmetry
Network: asymmetry

When these asymmetries collide, they produce a stochastic landscape of booms and busts. Network society is volatile.

Broadcast: managed reserves
Network: booms and busts

Many-to-many, exponential, asymmetric, booms and busts… We’re beginning to see the outline of a new set of rules. Let’s keep going…

Coordination
Oral: genealogies
Literary: organized religion
Broadcast: ideologies
Network: algorithms

Cooperation
Oral: traditions
Literary: bureaucracies
Broadcast: standards
Network: protocols

Time-perception
Oral: generational
Literary: historical
Broadcast: scheduled
Network: instant

Memory
Oral: rituals
Literary: archives
Broadcast: recordings
Network: memes

Production
Oral: self-manufactured
Literary: craft-manufactured
Broadcast: mass-manufactured
Network: JIT-manufactured (3D printed, print-on-demand, etc…)

Social currency
Oral: reputation
Literary: credentials
Broadcast: fame
Network: attention

Authority
Oral: elders
Literary: texts
Broadcast: celebrities
Network: algorithms

Truth
Oral: consensus
Literary: facts
Broadcast: experts
Network: virality

Faster now…

Broadcast: centralized
Network: decentralized

Broadcast: efficient
Network: adaptive

Broadcast: standardized
Network: personalized

Broadcast: manufactured consensus
Network: runaway amplification

Broadcast: spectacle
Network: outrage

Broadcast: shared reality
Network: sharded reality

Broadcast: economies of scale
Network: swarms

Broadcast: welfare
Network: gofundme

Broadcast: institutions
Network: groupchats

Broadcast: countries
Network: cities

Broadcast: internationalism
Network: archipelagos

Broadcast: big cold wars
Network: small hot wars

Broadcast: armies
Network: guerillas

Broadcast: prevents damage
Network: routes around damage

Broadcast: coal, dams, nuclear
Network: microgrids, batteries, rooftop solar

Broadcast: climate mitigation
Network: climate adaptation

Some things that don’t exist in a network society: facts, shared truth. Facts don’t exist in oral cultures either. They are a byproduct of literary culture. Books, as an artifact, are permanent, unalterable, and shared, like a fact. They are tablets come down from the mountain.

Social media isn’t like that. Social media has no memory. It lives in the internal instant, amplifying and exaggerating the most salient features of signals.

What does the network amplify?

…and maybe two more: aww and horny. Limbic system stuff.

Networks are constantly adapting, so hardwired instincts are the one stable point in the system. The network forms itself around them. It evolves to take on the distorted shape of our collective psyche, like a funhouse mirror. The deep, instinctual, hardwired emotions are also the easiest ones to rootkit. You’re outraged! Of course you’ll amplify.

So, networks don’t product facts. Instead, they combine the gossip of oral culture with the scale of broadcast culture. Network culture is a hyper-oral culture.

No facts, no shared truth. As a child of literary culture, I do not like this! But whether I like it is beside the point.

World War 3 is a guerrilla information war with no division between military and civilian participation.
(Marshall McLuhan, 1970, Culture Is Our Business)

An absence of facts and shared truth does not imply an inability to coordinate. Ants don’t have shared truth, yet they coordinate. The truth doesn’t live in any one ant. It is embodied in the structure of the network.

To some, the critical test of whether a machine is or is not a ‘brain’ would be whether it can or cannot ‘think.’ But to the biologist the brain is not a thinking machine, it is an acting machine; it gets information and then it does something about it.
(W. Ross Ashby, 1948, Design for a Brain)

Intelligence is a scarce resource in literary culture. Experts, wonks, and researchers act as priests of knowledge.

Broadcast culture centralizes this intelligence, and scales it through mass-mobilization. That’s how it solves problems.

In network culture, intelligence becomes abundant. Thousands of people and AIs and algorithms all interact.

With the arrival of electric technology, man has extended, or set outside himself, a live model of the central nervous system itself.
(McLuhan, 1964. Understanding Media: The Extensions of Man)

It’s no accident that a network society sounds a lot like a neural net. Social media users act just like neurons, relaying messages when our action potential is reached. React, retweet, remember to like and subscribe.

AIs are, themselves, reflections of this network intelligence. LLMs crystalize the intelligence of the network by compressing an internet’s worth of text until the text speaks back. Intelligence becomes software. It can be scaled up and down, on demand, exactly like servers.

A new medium… not only does not wipe out the old, but actually reinforces the older medium or media. However, in doing so it transforms the old, so that the old is no longer what it used to be. Applied to books, this means that in the foreseeable future there will be more books than ever before but that books will no longer be what books used to be.
(Ong, 1977. Orality and Literacy)

So, AI reenforces and transforms intelligence. That means there will be more intelligence than ever before, but intelligence will no longer be what it used to be.

These AIs won’t be experts dispensing wisdom from an ivory tower. That’s literary culture. No, they’ll be wired up to the network, and they will repeat and compete and collide and be herded around by algorithms, just like the rest of us. Any aggregate intelligence will be the result of the emergent behavior of these interactions.

This is a world inhabited by many different agents and emergent network spirits, each with their own personalities and motivations. It’s a re-enchanted world, an animistic world, with no single locus of control.

Surviving in network society will mean learning to think together with our egregores.

How? Practically speaking, cryptography lets us solve a bunch of thorny problems with trust, stuff like:

• Authenticity: how do I know you are who you say you are? Cryptographic signatures use math to prove a message was signed with a particular cryptographic key. Signing makes messages non-repudiable, meaning the author is provably the author. This holds true even if the message was sent from a computer or network that can’t be trusted.

• Privacy: how do I know only you can see it? End-to-end encryption (e2ee) encrypts data so that only the recipient who holds the key can decrypt it. To everyone else, it’s a black box that can’t be read or tampered with.

• Integrity: how do I know this is it what it says it is? Is this mp3 a song or a virus? Cryptographic hashing functions let us generate a hash, a string of numbers and letters, unique to the content. To verify the integrity of the file, we just check the hash. If the file has been tampered with, the hash won’t match.

• Proof-of-x: how do you show you’re human? Authorized to log on? Eligible to vote? ZK proofs let people cryptographically prove things about themselves without revealing their actual identity or information.

• Contracts: how do I know you’ll do what you say you’ll do? Smart contracts deterministically execute agreements when conditions are met, preventing defection or cheating.

These are just some examples. At the most abstract level, cryptography allows us to replace other forms of trust with trust in math. Or put another way,

Cryptography is a tool for turning lots of different problems into key management problems.
(Dr. Lea Kissner, Head of Privacy Eng and CISO at Twitter)

We’ll get to that in a minute. Anyway, the trust isn’t eliminated. It just moves to a different part of the system, a part which can be scaled.

Take your bank website, for example. How do you know it’s legit? After all, the website had to hop through a lot of computers to get to you. What if one of them swapped out the real website for something else? A scam? Well, instead of trusting each computer that helped deliver the website, you trust the cryptographic key that was used to sign it. That little green lock in your browser? That’s called SSL.

It’s not clear how we could even establish trust on the internet without cryptography. To trust a message, I would have to trust every computer that touched the message as it bounced around the internet to me. Since internet routing is dynamic, I can’t even know who that might be ahead of time!

So, ordinary forms of trust, like reputational trust, just taking your word for it, cannot work at internet scale. But trusting a cryptographic key? That works! Cryptography scales trust.

Clever hacks to scale trust

Finding new ways to scale trust is a big deal. In a state of nature, our species lives in small bands of 150 or less, hunting, gathering, sharing stories, migrating from one place to another. Yet today, it is common to live in cities of a million or more. How did we end up here?

Well, one way to see our history is as a series of clever hacks to scale trust. Each unlocked new forms of cooperation, leading to new social structures. Researcher David Ronfeldt identifies at least four:

How have people organized their societies across the ages? The answer may be reduced to four basic forms of organization,

• the kinship-based tribe, as denoted by the structure of extended families, clans, and other lineage systems.

• the hierarchical institution, as exemplified by the army, the (Catholic) church, and ultimately the bureaucratic state.

• the competitive-exchange market, as symbolized by merchants and traders responding to forces of supply and demand.

• and the collaborative network, as found today in the web-like ties among some NGOs devoted to social advocacy

(Ronfeldt, 1996, “TIMN - Tribes, Institutions, Markets, Networks”)

We’re still figuring out that fourth one. Anyway, each of these social structures was catalyzed by a hack to scale trust:

Language scaled trust by enabling oral storytelling, the recitation of genealogies, and the development of larger kinship networks. I can trust you because my father’s father’s father is your father.

One of the fascinating characteristics of lineages is that they can be aggregated upward into much larger superlineages simply by tracing descent back to an earlier ancestor. (Fukuyama, 2011. The Origins of Political Order)

Shared language lead to the accumulation of shared ideas, shared beliefs, shared gods. Belief in Big Gods scaled trust by expanding the scope of kin to include co-religionists. I can trust you, because we are brothers and sisters in the same god and share the same moral framework. Ideologies perform the same purpose.

The ability to create mental models and to attribute causality to invisible abstractions is in turn the basis for the emergence of religion. (Fukuyama, 2011)

If we had to constantly negotiate new rules with our fellow human beings at every turn, we would be paralyzed and unable to achieve routine collective action. The fact that we become attached to certain rules not as means to short-term goals but as ends in themselves greatly enhances the stability of social life. Religion simply reinforces that stability and widens the circle of potential cooperators.
(Fukuyama, 2011)

Writing scaled trust by expanding the reach of Big Gods, and by enabling the emergence of durable hierarchical institutions. I can trust this because it was written down. It isn’t just hearsay. It is the word of god, etched in stone, or perhaps the word of an institutional authority, inked in papyrus, signed with an official seal.

Writing also meant math, and math lead to money. Money scaled trust by creating markets. I don’t have to trust you, I can trust double-entry bookkeeping and the almighty dollar.

These are just a few of the tricks for scaling trust that allowed us to solve new and bigger coordination problems. More trust meant greater levels of cooperation, deeper specialization, more social complexity, larger economies of scale.

Of course, this specialization and hierarchy and complexity has its downsides. Sometimes modernity makes me want to return to monke. Yet, it is difficult to outrun the economies of scale that come through scaling trust.

So, tribes, institutions, markets. What about networks? I want to propose that,

Cryptography scales trust by making it possible to build networks that only require trust at the the endpoints.

When the network is built on cryptographic protocols, we don’t have to trust anything in-between. We don’t have to trust the computers, the wires, the institutions, beliefs, or kinship of the network participants. We can trust the math. All we have to do is verify the message with cryptography.

This is a powerful primitive for scaling trust, because it means everyone on the network can cooperate together, even if they don’t trust each-other. The costs to producing high-trust results are greatly reduced, and we can spend our coordination efforts on building larger, more fine-grained, more complex networks of cooperation.

If language produced tribes, writing built institutions, money made markets, then perhaps cryptographic protocols will construct a network society?

The crypto archipelago

In a high-trust society, we might not often care about cryptography. In such a society, social protocols can take the place of cryptographic ones, and we can scale trust through means other than math: I trust in God, I trust Google, I trust government, I trust judges to rule with an even hand, I trust contracts, I trust institutions, I trust banks, and money I’m holding in my hand.

Nice work if you can get it. High social trust creates something like a Coasean “firm”, within which the costs of cooperation are greatly reduced. The higher the trust, the larger the Coasean space in which we can cheaply cooperate.

Does this look like a high-trust society?

The challenge is that we seem to be in the middle of some kind of social transition, driven by the internet. Old forms of trust are eroding, or getting DDOS’d by the scale of the internet. Social transitions are messy.

A new internet-scale paradigm, the cryptographic protocol, is in its nascent stages. But then new paradigms, by their very nature, question the logic of incumbent social structures which were designed around older forms of trust.

All media work us over completely. They are so pervasive in their personal, political, economic, aesthetic, psychological, moral, ethical, and social consequences that they leave no part of us untouched, unaffected, unaltered.
(Marshall McLuhan, 1967. The Medium is the Massage)

The closest analog to this transition might be the introduction of the printing press in Europe. This transformed a world of feudal estates, knit together by religion, into a world of states, knit together by markets, communication networks, and scientific/democratic institutions. I like these changes a lot! But then they also induced 200 years of religious warfare. Yikes.

So it might be the case that we find ourselves in a high-trust society that is experiencing rapid unbundling. Formerly functional institutions and shared social norms are fragmenting into pieces.

When hierarchies break down, they usually split along their subsystem boundaries. (Donella Meadows, Thinking in Systems)

What we’re left with is the small remaining islands of functional high-trust—friends, family, maybe church, community, some local institutions—separated by growing oceans of distrust. Where to go from here?

Cryptography suggests a way forward: network.

Cryptographic protocols can act like undersea cables between islands of high-trust. We can span low-trust oceans because we only have to trust the endpoints. Trustless networks re-build trust on a new foundation, giving it new scaling properties. You don’t have to trust apps not to snoop, you can trust the end-to-end encryption. You don’t have to trust me to honor the contract, you can trust the smart contract code. Parties with limited trust between can cooperate effectively together using protocols. The protocols knit them together into a functional network organization.

We could think of cryptographic protocols as a kind of software-defined Weberian routinization, where protocols are to institutions as packet switching is to circuit switching.

Queries

I’m surrounded by smart readers, and so I would love your help in answering some of the questions I’ve been exploring:

• Who are the smartest people working in this space? Who is building new networked forms of coordination? Bonus for examples with fundamental needs in the loop—food, water, shelter, etc. Double bonus for street uses, as in “The street finds its own uses for things” (William Gibson)

• “A good science fiction story should be able to predict not the automobile, but the traffic jam." (Frederik Pohl) What traffic jams should we anticipate in the transition toward network society? Where could cryptographic protocols help? What traffic jams will protocols cause?

• What are some other ways we’ve scaled trust? What was the transition like? Who’s studied this? What should I be reading?

Reply to this email and let me know!

WE MUST BUILD ON A CLEAR SITE. The city of to-day is dying because it is not constructed geometrically. To build on a clear site is to replace the 'accidental' layout of the ground, the only one that exists today, by a formal layout. Otherwise nothing can save us.
(Le Corbusier, 1929, "The City of Tomorrow")

Why did the web centralize? Why is it slow? Why can’t CPython be parallelized? Why is null both an object and not an object? Why is null at all? Most of our software has been shaped by chance decisions made in haste by people who could not have predicted how the system would end up being used today. Some chance decisions become structural problems. They constrain the system, make it inefficient, hacky, slow.

If we could start over, and rebuild the system, knowing what we know now? We could fix these mistakes, swap out the security model, alter that layout algorithm, make the object threadsafe, avoid the billion dollar mistake. It would be fast, beautiful, elegant. Except…

You can’t rebuild an ecosystem

You can rebuild software. Software is just a machine. Swapping out modules and replacing code is no problem. We do it all the time. The impulse, then, is to use this engineering toolkit to fix the ecosystem.

We could scrape away the old system, the old city, with its layers of ugly history and compromised infrastructure, and replace it with clean geometric lines and rational choices. The city will continue, of course, just as before, only better, more efficient. People will come and go, work, sleep, shop, except these people will be happier, healthier, more beautiful. Like in this architectural model we made. See the little plastic people walking around the plaza?

Somehow this fantasy never quite works out, in cities or in software ecosystems.

Software can be rebuilt, because software is a machine. But a software ecosystem is not a machine. It is a living system. When we attempt to rebuild the ecosystem, we’re making a category error. We’re confusing the software for the ecological process unfolding around it.

In Ersilia, to establish the relationships that sustain the city's life, the inhabitants stretch strings from the corners of the houses, white or black or gray or black-and-white according to whether they mark a relationship of blood, of trade, authority, agency. When the strings become so numerous that you can no longer pass among them, the inhabitants leave: the houses are dismantled; only the strings and their supports remain. From a mountainside, camping with their household goods, Ersilia's refugees look at the labyrinth of taut strings and poles that rise in the plain. That is the city of Ersilia still, and they are nothing.
(Italo Calvino, 1972, Invisible Cities)

You can’t rebuild an ecosystem, just like you can’t rebuild the Amazon rainforest. You can only grow with it, or bulldoze it and start over from zero.

Forking Like a State

And that’s exactly what happens when you try to rebuild an ecosystem. Fixing structural issues means breaking changes. Breaking changes mean forking, and forking has costs:

When you fork an ecosystem, you kill the existing ecosystem's momentum, and start from zero on a new ecosystem.

This doesn’t stop us from trying. Software history is littered with attempts to fix past mistakes in our ecosystems:

• Python3 forked the ecosystem by making breaking changes to fix a number of longstanding mistakes. Strings became unicode by default, print went from being a statement to a function, functions switched from using lists to generators. Good stuff! Yet these longstanding mistakes turned out to be structural, and the fixes difficult to adopt. Keystone frameworks like Django and NumPy lagged several years behind in adoption. It took even longer for adoption to propagate through the long tail of the ecosystem. Many developers remained stuck on Python2 due to dependency lock-in. Things remained bifurcated until Python2 was EOL’d in 2020, forcing a migration. The ecosystem finally caught up 12 years after Python3 was released.

• JavaScript forked the ecosystem by introducing a syntax-breaking module system, ES modules (import/export). ES modules made significant improvements on Node’s grassroots module system, CommonJS modules (require()). Bindings in the new module system became static, making tree shaking possible. The breaking syntax change was also used as a wedge to upgrade the language in other ways. Nevertheless, it took years for browsers to widely support ES module syntax. Node.js took even longer. Build tooling became necessary for shipping code to the browser. Keystone NPM packages continue to use CommonJS, creating practical difficulties with code re-use. ES Modules are widely supported in browsers today, and Node has patched up most of the compatibility issues, but has taken about 10 years, and build tools have become entrenched as a permanent feature of using the language.

• Deno forked the ecosystem by ditching node_modules and package.json. Deno aimed to simplify by shedding Node’s increasingly complex legacy baggage. They ditched build tooling and config by supporting TypeScript, ES Modules, URL-based imports, web standard APIs, and a sandboxed runtime. However, the lack of support for Node’s massive NPM ecosystem hindered adoption. Then Bun launched with full NPM compatibility, and focused on selling performance. It rapidly gained traction. Now Deno finds itself playing catch-up. Deno 2 introduced full NPM compatibility. It also launched JSR, a new open source and decentralizable module registry. This is wonderful, but it forks Deno’s ecosystem yet again, since developers now face a choice between NPM and JSR.

I’ve also attempted to fork, and for sillier reasons!

• Subtext rationalized Markdown as a simple block-based syntax, side-stepping syntax ambiguities, and making it easier to parse into useful data structures. Then, a few months later, ChatGPT happened, and Markdown was their lingua franca. Rationalizing Markdown became a pointless exercise. LLMs are trained on and will generate Markdown for eternity. It’s immortal. I should have just gone with Markdown.

What can we learn from all this? Python, ES Modules, Deno, JSR all feel like justified forks to me. They attempt to move the status quo forward in significant ways. And yet every fork is justified. They all happen for good reasons. This doesn’t change the fact that the costs of forking are high, very high.

It seems to take about a decade for an ecosystem to recover from a fork. Even so, a lot of shrapnel remains. When the ecosystem finally pieces itself back together, it seldom looks the way we envisioned.

These examples are comparative successes. More often, our schemes to fix ecosystems simply fail. Forks turn ecosystem tailwinds into headwinds. You find yourself pushing against the ecosystem, trying to halt its natural momentum so you can point it in a new direction. Even if you you succeed in slowing it down, you’ll have to keep pushing to get it going again. We may rationalize the ecosystem, and kill it in the process.

Living systems layer

So, if not fix the ecosystem, then what? Add more layers!

• Layer stuff on top

• Let things live side-by-side

• Allow opt-in

Rich Hickey has a nice bit about this: “Don’t be afraid of foo2()”.

foo2()?! Preposterous! But then again… is it? foo2() means foo() doesn’t have to break. They can live side-by-side. You can opt-in.

We have to resist the urge to remove the legacy foo(). Carrying forward old baggage offends our sense of aesthetics, but hey, that’s how evolved systems work. Chickens still carry around the gene for dinosaur teeth. This is because living systems have to be viable at every evolutionary stage. They can never pause, reset, or make breaking changes. The path of evolution is always through the adjacent possible.

Maintaining viability is another reason that systems tend to evolve into pace layers. Newer layers can be stacked on top of older ones without breaking them. Promises on top of callbacks, async/await on top of promises. Older, slow-moving code can remain in its layer, unbothered. Lizard brain, limbic system, neocortex. Layer on layer.

For a long time I worked on browsers—Firefox and Chrome—and people who work on these kinds of things have a saying: Don’t Break The Web.

Don’t Break The Web is the reason we have <marquee> and quirks mode. It is also why you can visit spacejam.com/1996, and it still works today.

We’ve been playing Don’t Break The Web for 30 years. We based it on another game called Don’t Break The Internet, which has been going on even longer.

Don’t Break is an infinite game. We win by keeping the game going, and we’re still going. Let's build more things like that.

Don’t fork the ecosystem

An ecosystem is the most valuable thing in the world. If you have an ecosystem, you have tailwinds behind everything you do. That’s because ecosystems are nonlinear systems. They refuse to fall into equilibrium. Living systems want to spiral upwards.

Life improves the closed system's capacity to sustain life. Life—all life—is in the service of life. Necessary nutrients are made available to life by life in greater and greater richness as the diversity of life increases.
(Frank Herbert, Dune)

Ecosystems are rare. They don’t emerge very often. Our ecosystem, the one on this planet—life—arose just once, as far as we know.

Evolution is no linear family tree, but change in the single multidimensional being that has grown to cover the entire surface of Earth. (Lynn Margulis)

So, when a living ecosystem does emerge, we have to cherish it, foster it, despite shortcomings, inelegance, ugliness. All living systems are ugly and a little bit eldritch… squishy. That’s how it is.

One nice trick is to break the big thing down into smaller things, until we have things that are small enough to fit into one brain. Once this is accomplished, we can begin to compose big things from these small things.

Compositionality is the principle that a system should be designed by composing together smaller subsystems, and reasoning about the system should be done recursively on its structure…

Compositionality is strictly necessary for working at scale. In a non-compositional setting, a technique for a solving a problem may be of no use whatsoever for solving the problem one order of magnitude larger.

(Jules Hedges, 2017, On Compositionality)

This approach has a number of advantages. When we break problems down into brain-sized pieces, we can grapple with them one at a time. We can even hand off different parts of the problem to different people.

Even better, when we divide a system into modules, we can forget about the insides of those modules. We can picture the module as a black box with inputs and outputs, and reason about inputs and outputs at this higher level of abstraction.

Clearly interfaces are a crucial aspect of compositionality, and I suspect that interfaces are in fact synonymous with compositionality. That is, compositionality is not just the ability to compose objects, but the ability to work with an object after intentionally forgetting how it was built. The part that is remembered is the ‘interface’, which may be a type, or a contract, or some other high-level description. The crucial property of interfaces is that their complexity stays roughly constant as systems get larger.

In software, for example, an interface can be used without knowing whether it represents an atomic object, or a module containing millions of lines of code whose implementation is distributed over a large physical network.

(Jules Hedges, 2017, On Compositionality)

Drawing lines allows for change

This divide-and-conquer approach works more often than you might expect. One reason is that nature evolves a lot of things that look kind of like modules.

Complex things, like animals, are recursively composed of simpler things, like organs, cells, DNA, genes, and basepairs. Why is this?

There once were two watchmakers, named Hora and Tempus, who made very fine watches. The phones in their workshops rang frequently and new customers were constantly calling them. However, Hora prospered while Tempus became poorer and poorer. In the end, Tempus lost his shop. What was the reason behind this?

The watches consisted of about 1000 parts each. The watches that Tempus made were designed such that, when he had to put down a partly assembled watch, it immediately fell into pieces and had to be reassembled from the basic elements. Hora had designed his watches so that he could put together sub-assemblies of about ten components each, and each sub-assembly could be put down without falling apart. Ten of these subassemblies could be put together to make a larger sub-assembly, and ten of the larger sub-assemblies constituted the whole watch.

(Herbert Simon, 1968. The Sciences of the Artificial)

Evolution favors systems that are made of free-standing sub-assemblies, sub-assemblies that can be put down, picked up, combined, and replaced at runtime without causing the whole system to fall apart. And this is another important thing about modules: they let us swap out parts of the system.

Lines are hard to change

When we draw a boundary, we restructure the connections between parts of a system. Boundaries sever connections, resulting in densely-connected islands, with loosely-connected bridges at the interfaces.

Relationships within each subsystem are denser and stronger than relationships between subsystems. Everything is still connected to everything else, but not equally strongly.
(Donella Meadows, 2008. Thinking in Systems)

The behavior of a system is defined by the structure of its connections, be it ant trails, neurons, or circuits. So, modules shape behavior by changing the structure of the system.

It matters where we draw the line.

Roads, once laid down, are rarely moved. Buildings go up. The city takes on the shape of the underlying boundaries. Boundaries set a system on a trajectory that is difficult to change.

Modularity is not without costs. An architecture’s visible information is not allowed to change during detailed design and is difficult to change later. Thus, modularity makes it more difficult to experiment on the architecture’s visible information (such as a module’s interfaces) in order to facilitate experimentation on the architecture’s hidden information (such as a module’s internals). In a way, the inflexibility of the visible information is the price for the flexibility with respect to the architecture’s hidden information.

(Barbara van Schewick, 2010. Internet Architecture and Innovation.)

So, where to draw the line?

Draw lines around uncertainty

We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.

(Parnas, 1972: "On the Criteria To Be Used in Decomposing Systems Into Modules")

Since modules are black boxes, we can use them to hide uncertainty from the rest of the system. Seen this way, a modular system can be understood as an assemblage of uncertainties that have been boxed up and wired together.

Draw lines across time

Systems tend to sort themselves into pace layers, with different layers evolving at different rates.

We can find natural boundaries by thinking about time. Which parts of the system change quickly? Which will change slowly?

Pieces that evolve at different paces can become different modules, with stable interfaces between.

Let the lines draw themselves

To draw a line around an uncertainty, we must be certain about what is uncertain. To draw a line across time, we must know what is likely to change, and at what rate. We also need certainty about the interfaces themselves. Not just where they go, but what their shape must be.

So, drawing a line requires a deep understanding of what matters, an understanding that can only emerge with time and use.

Conditions for modularity:

• Specifiability: The people or organizations working on both sides of an interface need to know which attributes of the component are crucial to the operation of the system, and which are not.

• Verifiability: They must be able to measure those attributes so that they can verify that the specifications have been met.

• Predictability: There can’t be any unpredictable interdependencies across the interfaces. People using the system need to get what they expect when interacting with the system.

(Modularity Theory, Christensen Institute)

Don’t force it! Forcing a boundary is costly. Tearing it up is costlier. Modules evolve quickly, but interfaces evolve slowly. Drawing a line means freezing a part of the system in time. If you draw the wrong line, you freeze the wrong part of the system. The parts of the system that need to evolve will no longer be able to evolve, making the whole system unadaptable.

This is why innovations tend to start out integrated, and get modularized over time. We draw the lines when we gain better understanding of where the lines should be.

• Smartphones started integrated, with the iPhone, and were modularized later, by Android.

• Cars started integrated, with the Ford production system, and were modularized later, by the GM production system.

• Steel mills started integrated, and were modularized later, by mini-mills.

In a functioning market, modular boundaries will begin to emerge by themselves. Interfaces will form around areas of certainty. They embody the commodity part of the problem. Modules contain the remaining uncertainty, and therefore all of the alpha.

Profit arises out of the inherent, absolute unpredictability of things, out of the sheer brute fact that the results of human activity cannot be anticipated.
(Knight, 1921. Risk, Uncertainty, and Profit)

Market forces will try to get at the alpha by unbundling those black boxes into more boxes with new interfaces. With time, these modules begin to sort themselves into pace layers.

Where to draw the line?

Reflecting on all of this, I am reminded of the story of The Dextrous Butcher:

Prince Wen Hui’s cook
Was cutting up an ox.
Out went a hand,
Down went a shoulder,
He planted a foot,
He pressed with a knee,
The ox fell apart
With a whisper,
The bright cleaver murmured
Like a gentle wind.
Rhythm! Timing!
Like a sacred dance,
Like “The Mulberry Grove,”
Like ancient harmonies!

“Good work!” the Prince exclaimed,
“Your method is faultless!”
“Method?” said the cook
Laying aside his cleaver,
“What I follow is Tao
Beyond all methods!

“When I first began
To cut up oxen
I would see before me
The whole ox
All in one mass.

“After three years
I no longer saw this mass.
I saw the distinctions.

“But now, I see nothing
With the eye. My whole being
Apprehends.
My senses are idle. The spirit
Free to work without plan
Follows its own instinct
Guided by natural line,
By the secret opening, the hidden space,
My cleaver finds its own way.
I cut through no joint, chop no bone.

“A good cook needs a new chopper
Once a year — he cuts.
A poor cook needs a new one
Every month — he hacks!

“I have used this same cleaver
Nineteen years.
It has cut up
A thousand oxen.
Its edge is as keen
As if newly sharpened.

“There are spaces in the joints;
The blade is thin and keen:
When this thinness
Finds that space
There is all the room you need!
It goes like a breeze!
Hence I have this cleaver nineteen years
As if newly sharpened!

“True, there are sometimes
Tough joints. I feel them coming,
I slow down, I watch closely,
Hold back, barely moving the blade,
And whump! the part falls away
Landing like a clod of earth.

“Then I withdraw the blade,
I stand still
And let the joy of the work
Sink in. I clean the blade
And put it away.”

Prince Wan Hui said,
“This is it! My cook has shown me
How I ought to live
My own life!”

(“The Way of Chuang Tzu”, Translated by Thomas Merton 1965)

When drawing lines, take it easy. Understand the whole before you cut it to pieces. Pause, listen. Let yourself be guided by the natural line.

Questions to ask myself when drawing a line:

• Drawing a line around uncertainty: What is certain? What is uncertain?

• Drawing a line across time: What is changing quickly? What is changing slowly?

• Letting the lines draw themselves. Where should the lines go? Do I know? Am I forcing it? Can I pause and let the system tell me?

PLACES TO INTERVENE IN A SYSTEM
(in increasing order of effectiveness)

1. Constants, parameters, numbers (such as subsidies, taxes, standards).

2. The sizes of buffers and other stabilizing stocks, relative to their flows.

3. The structure of material stocks and flows (such as transport networks, population age structures).

4. The lengths of delays, relative to the rate of system change.

5. The strength of negative feedback loops, relative to the impacts they are trying to correct against.

6. The gain around driving positive feedback loops.

7. The structure of information flows (who does and does not have access to information).

8. The rules of the system (such as incentives, punishments, constraints).

9. The power to add, change, evolve, or self-organize system structure.

10. The goals of the system.

11. The mindset or paradigm out of which the system — its goals, structure, rules, delays, parameters — arises.

12. The power to transcend paradigms.

I love this passage. I find myself returning to it again. Meadows is a scientist, but in those last points she takes an abrupt turn toward the spiritual. When every outward-facing lever fails, the answers must necessarily be found within.

We must not use the word system, then, to refer to an object. A system is an abstraction. It is not a special kind of thing, but a special way of looking at a thing.
(Christopher Alexander, 1968. Systems Generating Systems)

The definition of a problem is subjective; it comes from a point of view.
(Hugh Dubberly on Horst Rittel’s problem theories)

All systems are fictions that we project onto our environment for our own instrumental purposes. Those purposes are determined by our mindset, by the way we see the world around us.

If the pursuit of our instrumental goals results in catastrophe, perhaps it is possible to change our mindset, the mindset or paradigm out of which the system — its goals, structure, rules, delays, parameters — arises?

If a factory is torn down, but the rationality which produced it is left standing, then that rationality will simply produce another factory.
(Robert M. Pirsig, 1974. Zen and the Art of Motorcycle Maintenance)

When this exists, that comes to be. With the arising of this, that arises. When this does not exist, that does not come to be. With the cessation of this, that ceases.
(Samyutta Nikaya 12.61)

A change of mindset, inner change, involves low, slow feedback loops. This change may not bear fruit immediately, or even within a lifetime. Perhaps this is why many spiritual traditions encourage us to practice without expectation of return?

Ecosystems can't possibly exist for a particular purpose.
(Hayao Miyazaki)

All systems are fictions that we project onto our environment for our own instrumental purposes. But reality doesn’t exist for our instrumental purposes. It just exists.

If systems are fictions, maybe we can learn to hold them loosely, to trade between them, or even to let them go, and allow reality to speak back?

In the quietness, with nothing to accomplish, there is only direct experience.
(Dogen Zenji)

This architecture grants the server total control over users. The server owns your data, owns your account, and owns the cryptographic keys used to secure it.

That last bit is obscure, but important. Cryptographic keys are how we enforce security, privacy, ownership, and control in software. Not your keys, not your data.

The architecture of apps is fundamentally feudal. Apps own the keys and use them to erect a cryptographic wall around the hoard of data us peasants produce. You “sign in” to cross the drawbridge, and the castle can pull up the drawbridge at any time, shutting you out.

"Centralization" is the state of affairs where a single entity or a small group of them can observe, capture, control, or extract rent from the operation or use of an Internet function exclusively.
(RFC 9518: Centralization, Decentralization, and Internet Standards)

Powerful network effects build up inside those castle walls. These network effects can be leveraged to generate further centralization, extract rents, and shut down competition.

We are seeing the consequences of this centralized architecture play out today, as platforms like the App Store enter their late-stage phase. When growth slows, the kings of big castles become bad emperors.

Federation: choose your server

The Internet has succeeded in no small part because of its purposeful avoidance of any single controlling entity.
(RFC 9518: Centralization, Decentralization, and Internet Standards)

So, apps are centralized. How might we fix this? Well, the first thing we could do is bridge the gap between apps.

This is called federation. Users talk to the server, and servers talk to each other, trading messages so you can talk to users on other servers. Now you have the benefit of choice: which castle do you want to live in?

Email works this way. So do Mastodon and Matrix. My email is @gmail.com, yours @protonmail.com. We live on different domains, use different apps run by different companies, yet we can freely email each other.

The great thing about federation is that it’s easy to implement. It’s just an ordinary client-server architecture with a protocol bolted onto the back. We don’t have to build exotic technology, just exapt existing infrastructure. That’s why Mastodon, for example, is just an ordinary Ruby on Rails app.

But there’s a wrinkle…

Federated networks become oligopolies at scale

Why does this happen? Well, networks centralize over time, converging toward an exponential distribution of size, power, wealth. This centralization is inevitable. You see it on the web, in social networks, airline routes, power grids, trains, banks, Bitcoin mining, protein interactions, ecological food webs, neural networks, and oligarchies. Network theory tells us why:

• Preferential attachment: more connections means more network effect means more connections, leading to the emergence of densely-connected hub nodes.

• N^2 scaling: if every fed has to talk to every other fed to exchange messages, the number of connections will scale exponentially with each additional node (n * (n -1)). This leads to the emergence of large hubs that aggregate and relay world state.

• Fitness pressure: Small nodes get taken down by large spikes in traffic, while large nodes stick around. Small nodes have fewer resources, large nodes have lots. Unreliable nodes attract fewer connections, while reliable nodes attract connections just by virtue of staying alive.

• Efficiency: exponentially-distributed networks are ultra-small worlds. You can get from anywhere to anywhere in just a few hops through hubs.

• Resilience: exponential networks survive random failures, because the chances are exponential that the node that fails will be from the long tail.

This is called the scale-free property, and it emerges in all evolving networks. Federated networks are no exception. Take email for example:

Email is not distributed anymore. You just cannot create another first-class node of this network.

Email is now an oligopoly, a service gatekept by a few big companies which does not follow the principles of net neutrality.

I have been self-hosting my email since I got my first broadband connection at home in 1999. I absolutely loved having a personal web+email server at home, paid extra for a static IP and a real router so people could connect from the outside. I felt like a first-class citizen of the Internet and I learned so much.

Over time I realized that residential IP blocks were banned on most servers. I moved my email server to a VPS. No luck. I quickly understood that self-hosting email was a lost cause. Nevertheless, I have been fighting back out of pure spite, obstinacy, and activism. In other words, because it was the right thing to do.

But my emails are just not delivered anymore. I might as well not have an email server.

(After self-hosting my email for twenty-three years I have thrown in the towel, Carlos Fenollosa, 2022)

We can see the outlines of a similar consolidation beginning to emerge in the Fediverse. In 2023, Facebook Threads implemented ActivityPub and it instantly became the largest node in the Fediverse. This made some people angry and lead to demands for defederation. But Threads is already over 10x larger than the rest of the Fediverse. Defederation is hardly an effective blockade. The network has consolidated. Network science strikes again.

At scale, federated systems experience many of the same problems as centralized apps. That’s because feds are still feudal. They own your data, they own your account, they own your keys.

Large feds occupy a strategically central location in the network topology, and they have powerful influence over the rest of the network. They can leverage their network effect to pull up the drawbridge, by inventing new features that don’t federate, or cutting off contact with other feds.

So, federated networks become oligopolies. We can choose our server, as long as it’s blessed by the oligopoly. Still, an oligopoly is better than a dictatorship, email better than Facebook. But can we do even better?

P2P: all peers are equal

Ok, forget servers. What if we could connect to each other directly? This is called peer-to-peer networking.

In a P2P network, each participant runs a peer that can find other peers and send them messages. Users own their keys, and use them to sign, verify, and encrypt messages. This is great! We have all the ingredients for credible exit and minimal user agency.

However, P2P presents some tricky engineering challenges. There is no central source of truth, so various peers will will have different points of view of the network state. That means we need to design for eventual consistency and the ability to merge potentially conflicting states. Other things, like timestamps, are also hard. Decentralized protocols are hard! All of this is headwind compared to ordinary app engineering.

We also run into some practical networking challenges. We no longer have centralized servers, so many requests take several hops, from peer-to-peer-to-peer, to get to their destination.

Also, peers are unreliable. They are bandwidth-constrained and blink in and out of existence. Close your laptop, your peer disappears. This adds a cost to peer discovery. You dial a previously available peer, but it’s gone now, so you dial another, and another. Unreliable peers plus multiple hops equals long delays, and occasionally, the inability to reach portions of the network.

…but some peers are more equal than others

The same evolutionary pressures that apply to other networks apply to P2P networks, and some of them, like fitness pressure on reliability, are exaggerated by peer availability. This leads to the evolution of superpeers: high-bandwidth, high-availability peers who’s job is to serve other peers on the network.

Peer-to-Peer (P2P) networks have grown to such a massive scale that performing an efficient search in the network is non-trivial. Systems such as Gnutella were initially plagued with scalability problems as the number of users grew into the tens of thousands. As the number of users has now climbed into the millions, system designers have resorted to the use of supernodes to address scalability issues and to perform more efficient searches.
(Hadaller, Regan, Russell, 2012. The Necessity of Supernodes)

Instead of connecting directly, we connect to one of the high-bandwidth, high-availability superpeers. Peer discovery is no longer a problem, and everything is just one or two hops away… an ultra-small world.

Wait… That just sounds like centralization with extra steps!

Like feds, superpeers occupy a strategically central location in the network topology, and have powerful influence over the rest of the network. Our P2P network has converged toward an exponential distribution. Network science strikes again.

Well, but on a P2P network we do own our keys, and this is a big improvement. Trustless protocols are better than trustful ones, and by owning our keys we have the foundations for minimal user agency.

Still, we’ve done a lot of hard engineering to support a flat P2P network that will never exist in the end. Is there a simpler way?

The many attempts of nature to evolve a relay

Let’s start at the end and work backwards.

• All networks require large servers at scale

• Not your keys, not your data

Can we design a distributed architecture that admits these two facts? What might such an architecture look like?

Take some ordinary, off-the-shelf servers. Treat them as dumb, untrusted pipes. Their job is just to relay information. They don’t own the keys—you own your keys. You sign messages with your key, then post them to one or more relays. Other users follow one or more relays. When they get a message, they use your key to verify you sent it. That’s it!

This is the Nostr protocol. I want to claim that Nostr has discovered a new fundamental architecture for distributed protocols. Not federated, not P2P… Relay.

Relays cut to the chase:

• Relays are simple. They use boring technology, like plain old servers. You benefit from all of the tailwinds of traditional app development.

• Relays take advantage of economies of scale. Big dumb servers in the cloud have high availability and high uptime, and they’re commodity infrastructure.

• Relays sidestep the N^2 scaling problem: Relays don’t talk to each other, and users only need to join a small number of relays to gain autonomy—at least two, and certainly less than a dozen. We never really hit the scale where the n^2 scaling problem matters.

• Relays support user-ownership. You own your data, your account, and most importantly, your keys. Relays are large, but they aren’t in charge. If a relay goes down or shuts you down, no problem! Your account doesn’t change, and your data is already mirrored to other relays. Credible exit!

…Most importantly, relays are what you would get in the end anyway. It’s fewer steps for the same result.

Welcome to zombocom… you can do anything at zombocom… anything at all… the only limit… is yourself…

This is the Zombocom Problem: sure, it can be anything, but first it has to be something specific.

Many attempts at no-code, low-code, nodes-and-wires, end-user programming, wikis, malleable software, moldable development, super apps, protocols, and platforms have failed because of the Zombocom Problem.

People don’t want “anything at all”. They want something specific. To succeed, you need to solve a specific problem for a specific user and find specific product-market fit.

Sure, Amazon is the everything store, but first it had to be the book store.

Three years ago I was in New York City working for a quantitative hedge fund, when I came across the startling statistic that web usage was growing at 2300% a year.

So I decided I would try and find a business plan that made sense in the context of that growth, and I picked books as the first best product to sell online after making a list of like 20 different products that you might be able to sell.

And books were great as the first best, because books are incredibly unusual in one respect: that is that there are more items in the book category then there are items in any other category by far.

Music is number two. There are about two hundred thousand active music CDs at any given time.

But in the book space there are more than three million different books worldwide active and printed at any given time across all languages. More than one and a half million in English alone.

So when you have that many items you can literally build a store online that couldn't exist any other way.

Books were the edge-of-the-wedge for Amazon. They were a great product, because they were shelf stable, easy to ship, easy to handle, and could compete on catalog size.

Books also offered an easy gradient into adjacent categories like music. First Amazon was the book store, then the books and music store, then the books and music and… Bezos landed, then expanded into adjacent market after adjacent market, until Amazon grew from the something store to the everything store.

The Zombocom problem explains why spreadsheets succeeded, where many other end-user-programming platforms failed.

The whole world runs on Excel. Name a data-intensive critical industry: deep-sea oil drilling? Power grid management? International finance? All powered by Excel at critical junctures.
(ng12 on HackerNews)

Spreadsheets are used by everyone for everything, but first they had to be used by someone for something specific. Spreadsheets had to find a first best customer.

This is VisiCalc, the first spreadsheet program:

Who was VisiCalc for? Who was the first best customer?

They knew exactly who: business owners and accountants. More specifically, small business owners who couldn’t afford a full-time accountant. This was the edge-of-the-wedge for spreadsheets.

“We’re building a platform, not a product”. If you hear this, run away. Platforms come from products, not the other way around.

People don’t buy platforms. They buy one product at a time that somehow differentiates itself from every other product in their life. And then they move onto the next one. And the next one. You need to make standalone, great products, and if they can eventually all talk to each other 10 or 20 years down the line, then great.
(Tony Fadell, founder of Nest, lead engineer who oversaw invention of the iPod)

A product solves a specific problem for a specific user. Platforms have to start here too. Otherwise, they’re DOA.

I’m interested in building software that is organic, open-ended, and evolving… squishy computers. A squishy computer is pliable, re-shapable, open-ended, true to its materials as a universal machine.

So but how do we build software that can be anything without falling into the Zombocom trap? I believe that Bezos interview shows us exactly how.

1. You start from a systems-level insight (the internet is growing rapidly)

2. Then work backwards to a first best customer who has a burning need (can’t find book) that is related to your superpower (internet allows unlimited shelf space).

3. This customer acts as the edge-of-the-wedge for expanding into adjacent use cases (next best customer is music)

Bezo’s approach is sublime. It holds two seemingly irreconcilable insights in tension and transcends either lesser alternative:

• A single-purpose product knows its customer, but tends to paint itself into a corner without systems-level insight. Instead of landing and expanding, it ends up going deeper and deeper into its vertical.

• A systemic platform has massive growth potential, but tends to flop without a first best customer. It’s sometimes possible to overcome this with a massive push distribution channel, but the truth is, if you build it, they won’t always come.

Starting from that systems-level insight and working back to the first best customer requires two different skillsets, two different ways of seeing.

• From the outside, it may look like you’re diving deep into a vertical and building a single-purpose product. Systems thinkers don’t like that. They want to generalize the system.

• From the inside, it may feel like you’re spending a lot of time on theory. Product thinkers don’t like that. They want to think about the customer.

But holding both of these contradictory perspectives in your head at once is a superpower. Doing the hard work of systems-thinking up front allows you to uncover exponential opportunities. Working back to a first best customer sharpens your edge-of-the-wedge.

It can be anything, but first it has to be something specific.

I’d like to capture these intuitions while they’re still raw. It’s n=1 samples, so hold it lightly. I’m writing this post for me!

Start with product and work backwards to technology

You’ve got to start with the customer experience and work backward to the technology. You can’t start with the technology then try to figure out where to sell it.
(Steve Jobs, 1997, Worldwide Developer Conference)

Prioritizing tech before product turns good problems to have into bad problems to have. You want to start with product, and work back to technology, taking the shortest path to market by doing things that don’t scale. This lets you iterate toward something that people actually want.

This is more important for startups than for open source or big tech. Big tech has big money. Open source has little money, but lots of time. Startups have little time and little money. If you can’t close the loop with the market, you won’t have the runway to do anything else. Product-market fit is everything.

Get to market as quickly as possible by building novel products with boring technology. Build novel technology only after running out of boring technology, and only when it generates an asymmetric advantage.

A startup pulls a thing from the future into the present

The future is here, it’s just not evenly distributed yet.
(William Gibson)

A startup’s job is to spot a thing from the future, then pull it into the present as quickly as possible.

Noticing things from the future is an act of intuition. It takes a somatic sensitivity to the present, and a willingness to trust your gut. Your unconscious mind can feel out the high-dimensional patterns that are unfolding in the environment around you. That’s what it’s there for.

Systems fool us by presenting themselves as a series of events.
(Donella Meadows, 2008, Thinking in Systems)

You can attune this intuition for the future by studying history, by scanning your environment, and by practicing structured methods like scenario planning.

With a sensitive intuition, it is possible to notice things from the future months, or years in advance. Occasionally, a person is so sensitive they can spot things decades ahead. This is a rare gift, and people like this are usually cursed to be Cassandras. They see too far, and no one listens. Many artists are like this.

Art at its most significant is a Distant Early Warning System that can always be relied on to tell the old culture what is beginning to happen to it.
(Marshall McLuhan, 1964, Understanding Media)

The sweet spot for startups is seeing 24 months into the future. This is a stone’s throw into the adjacent possible. It’s far-out enough to be asymmetric, familiar enough to be pitchable, and time enough to build.

…But you have to build fast! The frontier of the adjacent possible is always expanding.

It’s like fog of war in a Civ game. Others are also pushing into the frontier of the possible, coming at it from all directions. Within a couple of years, an idea can go from unthinkable to everywhere.

Time is your most valuable resource. Move quickly.

Draft off of ecosystem tailwinds

Sail with the prevailing winds of the ecosystem, and not against them. Every tech choice should be bog standard, except the one thing that gives you an asymmetric advantage.

Why? Tech is a Red Queen Race.

Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!
(The Red Queen in Lewis Carroll’s Through the Looking-Glass)

You can’t afford to not leverage the dominant platforms, even when the dominant platforms are inelegant, baroque, or ridiculous. React, Node, NPM, JavaScript build systems, Kubernetes, imperative programming, von Neumann Architecture, whatever. Use dominant platforms.

You can’t exit this Red Queen Race, in the same way that a whale can’t relitigate its evolutionary pathway. Gills would be great, but the whale works with what it has got—it holds its breath. Ineligant? Baroque? Ridiculous? Doesn’t matter! The path of evolution is always through the adjacent possible.

Dominant platforms set the table stakes. The relevant competition shifts to things on top. If you try to relitigate this tech stack, you’ll spend your runway just catching up to baseline. Meanwhile, your competition is drafting off of the tailwind. You aren’t building in a vacuum.

I have two anecdotes about this. The first is about building the text editor for Subconscious. Now, building a text editor is a nightmare on the web. I hoped iOS would be better, but while the low-level text APIs are better, you quickly run out of platform to do anything complex. After a couple months of struggling with low-level TextKit APIs, I npm installed ProseMirror. I made as much progress in two days as in two months. That’s the ecosystem tailwind.

Yes, text editing is a nightmare in browsers, but the Red Queen Race for rich text has been running for a long time on the web. This evolutionary arms race has resulted in an arsenal of tools for building web-based editors. iOS, meanwhile, has been insulated from this evolutionary arms race. It’s like an island populated by flightless birds.

Another anecdote: Copilot. Copilot is great! It helps you speedrun boilerplate, and rapidly orient within unfamiliar codebases. There are Copilot plugins for every major code editor, but if you’re building for iOS, you have to use Xcode. No Copilot for you. Stuck on iOS island, like a dodo.

Don’t get stuck on a tech island. Sail with the prevailing winds of the ecosystem.

A seed-stage startup gets to spend one risk token

Subconscious tried to innovate in two ways:

1. Technology: by building a decentralized knowledge graph protocol.

2. Product category: by inventing a new kind of tool for thought (not just another Roamlike).

That’s two innovation tokens:

new tech + new category = two risk tokens

In retrospect, I think we spent one innovation token too many.

During the seed stage, you probably have runway for just one innovation token. You must spend that innovation token unlocking your asymmetric advantage.

If you want to innovate on product category, you must spend your innovation token entirely on product creation. You must build, throw away, build, throw away, until you find the chemistry that makes your product go boom.

This means choosing a boring, battle-tested stack that solves 80% of the problem, so that building and throwing away is fast and cheap. If you’re innovating on product category, you can’t afford to innovate on tech, since you would have to throw it away anyway, while iterating toward product-market fit. On the other hand...

If you want to innovate on technology, you must spend your risk token on that technology. You need to be confident it’s a disruptive technology. The simple act of introducing this technology into an existing product category should be enough to make category go boom.

This means identifying an existing product category, with existing PMF, that is being held back by the limits of the current technological paradigm. If you’re innovating on technology, you can’t afford to innovate on product category, since your goal is to upend an existing value chain.

Roughly speaking, innovating on product maps to new market disruption, while innovating on technology maps to low-end disruption. These are different strategies, and a startup is pursuing one or the other. There are exceptions (OpenAI), but they are rare.

So, what could Subconscious have done differently? A one-ply take might look like this:

• Since we were pursuing a protocol strategy, we could have built a Roamlike. The designer in me balks at copying and commoditizing. However, in the time we were building, we saw Obsidian do exactly that, and achieve product-market fit. At the same time, I am not convinced “commoditize Roam” is a VC-scale opportunity. Obsidian has taken the right approach by bootstrapping.

• Flipping it around, we could have leaned into new product innovation using a standard SaaS stack, and drafted off of the ecosystem tailwinds of the web. This would have sacrificed our protocol story, but might have meant faster first-contact with the market, and a path to product-market fit.

However, the truth is more complex, and both of these fall flat. Ultimately, AI disrupted Tools for Thought as a coherent concept. LLMs have that signature quality of all disruptive technologies: they upend you incidentally.

So, know how you’re disrupting. Do just that.

Decentralized protocols are hard

The challenge emerges from two directions:

• Distributed systems are hard.

• Decentralized protocols are tech islands.

Berni Seefeld likes to say that there are two kinds of hard:

• Algorithm-hard: you need the right PhD to solve it.

• Coordination-hard: you need to align multiple stakeholders with different incentives.

It is well-known that distributed systems are algorithm-hard. However, the hardest thing about building a decentralized protocol is not the vector clocks or CRDTs, it is that you do not have 30+ years of ecosystem momentum behind you. Trying to manifest an ecosystem from scratch is a coordination-hard problem. As cdata says, “it’s network or nothing”.

Well, so, decentralizing the internet is difficult. I still think it is a worthwhile goal. We are building the foundations of the network society we’ll be living in for the next 100 years, and decentralization enables freedom, resilience, and permissionless innovation.

So, I’d like to decentralize the internet somewhat. What to do? Two potential approaches:

• Build centralized-yet-decentralizable SaaS. Do as much as you can using the traditional web stack, changing as little as possible, and only where it changes the power relationship to the server. Pulling this off is like performing a judo move, aligning forces so that the problem solves itself—lateral thinking with weathered technology.

• Look for places where decentralization is disruptive. As Cosma Shalizi puts it, “one of the lessons from the theory of natural selection is that a degree of isolation can be a great help to a new strategy in gaining a foothold.” Decentralized protocols are a tech island, but for this precise reason, they might just evolve new disruptive strategies. Look for those strategies, and focus on the ones that close economic loops, or change cost structures.

Recursively de-risk

The typical process for building something looks like this:

1. Understand the problem

2. Make a plan

3. Divide and conquer

4. Deliver to market

Let’s call this the top-down approach. We found that a startup benefits from inverting this process:

1. Sketch out the idea as quickly as possible

2. Identify the top risk, blocker, or unknown

3. Do the cheapest thing to de-risk it

4. Go to 2

Top-down planning is feed-forward. You won’t find out if your idea actually works until the very end. Recursive de-risking generates feedback quickly and cheaply, allowing you to find out early what works and what doesn’t.

Software economics is a barbell

Networked software has unusual economics:

• Fixed costs are cheap

• Labor is expensive

• ARPU is low

• Copying software is zero marginal cost

• Adding a user is zero marginal cost

• Network effects are powerful

• The entire world is your addressable market

• The entire world is competition

You can’t run networked software like a local cafe. Labor is too expensive and ARPU isn’t high enough for a small market. You have no local moat. Your ability to scale globally is limited by your cash on hand.

The most effective software economics are squished toward the extremes, like a barbell:

• Open source projects lean into the fact that software is zero-marginal cost to copy, by making it even easier to copy. Open souce factors out the cost of labor by shifting to voluntarist economy of free giving and free copying.

• Venture-funded startups accept that labor will be the dominant cost up front, but marginal in the long run as network effects and zero marginal cost take over. So, VC pulls money forward from the future, betting on that big payoff. Because of the weird physics of networked software, it either fails or succeeds big—10x or more.

The barbell economics of software allows open source and VC to take huge risks. Open source doesn’t have to justify itself to anyone. You do have to pitch VCs, but the courage of your average VC is far greater than the courage of big tech execs. That’s because they only need one in ten to be a home run. You’re a dandelion seed, VC is in the dandelion seed scattering business.

This higher risk-tolerance means more trial and error means more innovation. Both models allow for unbounded upside when a hit is discovered.

Startups are r-selected

A startup is a dandelion seed not an elephant, r-selected not K-selected.

R-selected species are explorers. They rapidly colonize new spaces. Picture an empty field. What fills it first? Weeds. That’s why we call them green fields.

Weeds inherit the earth. (Stewart Brand)

K-selected species emerge later. Once the niche begins to get crowded, it pays to grow tall, like a tree, instead of far and wide, like a dandelion.

Startups aren’t K-selected. They don’t compete for crowded niches. They expand into new frontiers. If they can’t find one, they create it.

There is a kind of wu-wei to admitting you are r-selected. Move fast, take risks, be opportunistic. Don’t get precious. Try a lot of things, and don’t be afraid to die.

A startup needs just one truly great asymmetric insight. Beyond this, 10D chess has diminishing returns. It’s guerrilla warfare, not siege warfare. Identify your angle, then move with speed, surprise, and violence of action to make contact with the market as quickly as possible.

Per ardua ad astra. -G

Subconscious is winding down, but I’m venturing forward to build something new (more about this in a future email). The newsletter is getting rebooted as my personal lab notebook, a place for me to post trail markers as I continue to navigate the idea maze around AI, malleable computing, tools for thought, and decentralized protocols.

So, why Squishy Computer?

I’m interested in software that is organic, open-ended, and evolving, software that fosters living ecosystems… squishy computers.

Ecosystems can't possibly exist for a particular purpose. (Hayao Miyazaki)

The internet is like this, so is the web. My question is, how can we make more software like this?

I like to look at software ecosystems through the lenses of evolution and ecology. There is so much we can learn by stepping out of top-down factory methods of production, and seeing software like biology.

We have to actually lose the idea of intelligent design, because that's actually what that is. The top-down theory is the same as intelligent design. And we have to actually stop thinking like that and start understanding that complexity can arise in another way and variety and intelligence and so on. So my own response to this has been, as an artist, to start to think of my work, too, as a form of gardening.  So about 20 years ago I came up with this idea, this term, 'generative music' […]

And essentially the idea there is that one is making a kind of music in the way that one might make a garden. One is carefully constructing seeds, or finding seeds, carefully planting them and then letting them have their life. And that life isn't necessarily exactly what you'd envisaged for them. It's characteristic of the kind of work that I do that I'm really not aware of how the final result is going to look or sound. So in fact, I'm deliberately constructing systems that will put me in the same position as any other member of the audience. I want to be surprised by it as well.  And indeed, I often am.

(Brian Eno, 2011. Composers as Gardeners.)

It is my belief that open-ended ecosystems are where innovation comes from. The innovation is the system surprising itself. When a system can’t surprise itself, it can’t innovate. Top-down planned systems are like that. We already know everything they will produce, since it was planned from the beginning. These kinds of systems don’t last for long.

If it is in equilibrium, it must be dead! (John H. Holland)

Only that which can change can continue. (James Carse)

I hope to understand and build more open-ended ecosystems through software. I’ll post here along the way, sharing project updates, ideas, design patterns, and snippets of books and papers.

Towards a squishy computer,
-Gordon

Today we’re sharing difficult news. Subconscious will be winding down active operations. I’m proud of what our team built on a technical level—a multiplayer graph protocol for notes. Despite this, we ran into difficult technical headwinds and missed a crucial market window. Ultimately, we did not find product-market fit.

I now believe we were aiming at the wrong target. The world changed in a fundamental way while we were building. Today, if you want to amplify intelligence, you probably wouldn’t build a decentralized notes graph, you would go to work on personal AI. Subconscious, though, isn’t the right vehicle to pursue this scale of opportunity. The shape is wrong, the runway too short, so we’re calling the ball.

That’s the hard news. But if you ask me, the dream of a bicycle for the mind, of software that amplifies intelligence, creativity, and agency, is more real than ever. AI has unlocked a wild new landscape of possibility. There is no time to lose. I’m venturing forward to build something new. I’ll keep you updated here on the journey.

To our beta testers

The Subconscious Beta TestFlight will expire after a few months. However, you can export all of your Subconscious data as useful plain text files, through the iOS file system and the Noosphere protocol.

Guide: exporting your Subconscious data.

Thank you for testing and offering feedback on the Subconscious Beta. Your feedback has been invaluable. We appreciate how thoughtful and kind you have been, and that you’ve taken the time and energy to test-drive early software.

This newsletter will continue

This newsletter will become my personal lab notebook. I’ll continue to post here, but under my own name, as I navigate the idea maze around AI, decentralized protocols, and tools for thought.

The Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? The Web, in comparison, is a joke. The Web was done by amateurs. (Alan Kay)

My motivating question is: how can we build more things like the internet? Or just grant me the amateurism to create things like the web! I would like to build software like this—software that is open-ended and evolvable, software that amplifies our agency.

What I think we got right

When we started building, I had a strong intuition that a moment of opportunity was coming to decentralize the social web. Here, I think my intuition was right.

My hypothesis was: make a multiplayer tool for thought by combining something like Roam with something like Twitter.

• Roam resurrects a vision of the web we never got—the JCR Licklider Memex Web, the Doug Engelbart Augment Web, the Ted Nelson Xanadu Web—hypertext, as it could have been.

• Twitter, at its peak, functioned as a kind of exobrain.

Combine these with a decentralized protocol, and maybe it could be the seed of a new web-like thing?

This was an unusual pitch in 2021. But then, in April 2022, Elon Musk bought Twitter. By summer 2023, a wave of protocols was washing over the internet in reaction.

Hot protocol summer!

• Farcaster launched a permissionless network

• Bluesky surpassed over 2 million users

• Nostr snowballed toward 18 million keypairs

• Threads implemented ActivityPub

• IETF released a standard for end-to-end encrypted messaging

The wildest part of our thesis was being vindicated by reality. The social web wanted to be protocols! Furthermore, these projects converged toward similar architectures, mostly using self-sovereign keys, decentralized data, and ordinary servers.

How is it that so many protocols were ready to take on Twitter, just months after Musk bought it? Why did we see convergent evolution around protocol architectures? Others had also sensed a shift in the Zeitgeist months in advance, and started building. These weren’t disconnected events. They were the result of structural forces playing out in a late-stage ecosystem.

The old web is dying, a new one struggles to be born.

Missing a window

While we were directionally correct, the unfortunate fact is that we missed a window while struggling through some difficult protocol integration challenges.

Hot Protocol Summer was a one-time event, a moment when the shock of Musk’s Twitter takeover enabled open competitors to bootstrap viable networks.

Ecosystems have overwhelming momentum. It’s only during these moments—when ecosystems collide, die, or are disrupted—that we have agency to tilt the trajectory of the future. These windows of opportunity are fleeting and contingent. They open up at the beginning and end of s-curves, after crashes, or during collisions between previously isolated ecosystems. Timing them correctly is crucial.

By Q1 2024, it was clear Farcaster, Bluesky, Nostr, and ActivityPub all found early product-market fit, and we hadn’t. We missed a critical window.

Chaos is a ladder. The ladder has been pulled up for the time being.

Aiming at the wrong target

Our goal with Subconscious was to amplify intelligence. The best way to do that in 2021 looked like building a multiplayer tool for thought. Combine something like Roam with something like Twitter, and if you manage to bootstrap a network, you might get collective intelligence.

Then ChatGPT launched, and within months, good-enough open source LLMs were everywhere. This upended our hypothesis.

Tools like Roam, Obsidian and Logseq are hired to amplify intelligence—that is the JTBD. So, but, if I’m looking to amplify my intelligence today, what am I going to reach for? Probably Claude. The basis of competition has shifted.

This makes me question many of my previous assumptions:

• Instead of evergreen notes, what if we hallucinated notes on demand?

• Instead of knowledge graphs, what if we generated embeddings?

• Instead of a multiplayer, what if we had hundreds of friendly NPCs?

• Do we need notes at all?

I don’t know? It’s a green field! LLMs change the way computers think, and the ways we can think with computers. Whole new classes of tools are possible.

In 2024, it is clear to me that if you want to amplify intelligence, you don’t build decentralized notes, you work on personal AI.

What’s next

LLMs are a big deal. They disrupt tools for thought, sure, but also the web, and culture at large. We’ve built much of our world around text. Now the text is speaking back. It has a mind of its own.

This changes things. Software is getting softer, and the dream of computers as personal dynamic media suddenly seems more tangible.

There’s lots more to say, and I would like to share more of what we learned while building Subconscious, but it will have to wait for a future post. For now, I’ll just say a heartfelt thank you for accompanying us on this journey.

Stay tuned.