For decades, software has been built roughly the same way: a presentation layer (the buttons and screens you click), a logic layer (the code that decides what happens when you click), and a data layer (the database where stuff gets stored). This "three-tier architecture" has been the default blueprint for everything from banking apps to e-commerce sites. This paper argues that we're now living through a fundamental break from that pattern — and that the new blueprint has only three parts, but they're radically different.

The authors frame software history as three eras:

• Software 1.0: Humans write explicit instructions. Behavior is determined by code.
• Software 2.0: Humans provide data and let machine learning models figure out the rules. Behavior is determined by training data.
• Software 3.0: Humans provide context and goals, and reasoning models figure out what to do. Behavior is determined by context and reasoning.

In this new world, they claim the three-tier stack collapses into a new trio:

• A generalized database — not just a table of rows, but a unified store for everything the system remembers: files, vector embeddings, past conversations, world state. Memory becomes a first-class primitive rather than an afterthought.
• A large model — the reasoning engine that replaces most hand-written business logic. Instead of coding "if user does X, then Y," you describe the goal and the model reasons about it.
• Agents — the actors that take goals, call tools, invoke the model, read and write memory, and actually get things done in the world.

The key insight is that the interface between components has shifted from function calls to natural language and context. In the old architecture, layers communicated through rigid APIs — a frontend calls a specific backend endpoint with specific parameters. In the new one, components exchange goals, memories, and reasoning traces. This changes almost everything downstream: how you version software (prompts and context, not just code), how you test it (behavior is probabilistic), how you debug it (traces of reasoning, not stack traces), and how you architect it (storage and memory design become as important as model choice).

It's a position paper, not an experimental one — the authors aren't proving the shift with benchmarks, they're naming a pattern they see forming across the industry and arguing developers should design for it explicitly rather than accidentally.