03 — Why 2100

2100 is not a prediction.
It is a design horizon.

We are not forecasting the next century. We are using it as a vantage point: if these systems were being designed for the world of 2100, what would we build today?

What a horizon does

A distant horizon changes what you are willing to consider.

Most design decisions are made inside a short frame, and the frame does most of the deciding. A two-year horizon makes the existing category the obvious container, the existing institution the obvious partner, and the existing process the obvious thing to accelerate.

Pushing the horizon out removes that gravity. It lets a question be asked that a nearer frame would rule out of order.

What a short horizon forces

  • Quarterly metrics decide the architecture
  • Existing categories define what is buildable
  • Legacy institutions define what is possible
  • Current org structure defines the problem boundary
  • Today’s technology limits define the ambition

What a long horizon permits

  • Asking what outcome the system should produce at all
  • Designing a category that does not exist yet
  • Treating institutions as inputs, not constraints
  • Structuring the company around the system, not the reverse
  • Building for capabilities that are arriving, not only those that have arrived
A caution we hold ourselves to

A long horizon is an invitation to be unserious. We treat it as the opposite: the further out the target, the more grounded each intermediate decision has to be. Nothing here is science fiction, and nothing here is a promise about a world we cannot see.

Why now

The capabilities arrived separately. They can now be assembled.

Nothing in the list below is new on its own. What is new is that all of it is simultaneously available, cheap enough, and reliable enough to build a system on.

AI+ Cloud+ Connectivity+ Digital identity+ Digital payments+ Smartphones+ Modern logistics+ Data infrastructure+ Automation

The technologies already exist. The opportunity is to assemble them into new economic systems.

Historically these capabilities emerged decades apart, and each was absorbed into whatever system existed when it arrived. A payments rail was added to a bank. A phone was added to a shop. A model was added to a process.

Convergence makes a different move available: not adding a capability to an inherited system, but designing a system that assumes all of them from the start. That is a narrower window than it appears — once new systems calcify around the old shapes, the cost of redesign rises again.

The working question

What we actually ask in the room.

If we were designing this system for the world of 2100,
what would we build today?

How that question is applied