Inside Notion's AI Evolution: How Token Town, 100+ Tools, and MCP Are Redefining the Software Factory

When Notion's engineering team rebuilt their AI features five times in rapid succession, most observers would see chaos. I see something far more valuable: a masterclass in how elite product organizations navigate the fastest-moving technological shift in software history.

Simon Last and Sarah Sachs, leading Notion's AI initiatives, have transformed the company into what I'm calling a "software factory"—a new organizational model where AI tooling, rapid iteration, and architectural flexibility create compound advantages that traditional development processes simply cannot match.

This isn't just another AI integration story. This is about fundamental changes to how we build software, and the strategic decisions that separate winners from those left holding deprecated codebases.

The Five Rebuilds Nobody Talks About

Let's start with the uncomfortable truth: Notion has rebuilt their core AI features five times. Five complete rewrites in the span of months.

In traditional software development, this would be considered catastrophic. Technical debt accumulating, engineering resources burned, product velocity destroyed. But here's what makes Notion's approach different—and why it's actually a competitive advantage.

Each rebuild wasn't a failure. It was a deliberate response to the AI landscape shifting beneath their feet. When you're building on foundation models that improve every quarter, when context windows expand from 4K to 128K tokens, when new capabilities like structured output become available—standing still is the real risk.

The teams that win in AI-native products aren't those who build perfect, unchangeable architecture. They're the ones who build for rebuilding. This requires a fundamental shift in how we think about technical debt, abstraction layers, and the cost of change.

The key insight: In rapidly evolving domains, the ability to rebuild quickly is more valuable than building perfectly the first time. This inverts decades of software engineering wisdom, but the math is clear. If your foundation shifts every six months, a two-month rebuild cycle beats a six-month "perfect" build that's obsolete on delivery.

Token Town: The Internal AI Laboratory

Notion didn't just add AI features to their product. They created "Token Town"—an internal ecosystem of 100+ AI-powered tools that their teams use daily. This is where the software factory model becomes tangible.

Think about the implications. Most companies have a handful of AI experiments. Notion has industrialized AI tooling to the point where triple-digit tool counts are normal. This isn't about quantity for its own sake—it's about creating an organizational learning loop that compounds.

Every tool teaches them something about:

• What works in production AI systems
• How users actually interact with AI features
• Where the rough edges are in current models
• What abstractions hold up under real-world usage

This is dogfooding at scale, but it's more than that. It's a parallel product development track where the feedback loop is measured in days, not quarters. When your internal teams are power users of AI tooling, you develop intuitions about what works that external testing can never replicate.

The strategic advantage: Companies building AI products while using AI products internally create a flywheel effect. Better internal tools → better product intuitions → better external products → more learnings to feed back into internal tools.

MCP vs CLIs: The Architecture Decision That Matters

Here's where we get into the technical decisions that will define the next generation of AI tooling. Notion is betting heavily on the Model Context Protocol (MCP) over traditional Command Line Interfaces (CLIs). This isn't just a technical preference—it's a fundamental architectural choice about how AI agents should interact with software.

Let me break down why this matters for product builders.

The CLI Approach: Familiar but Limited

CLIs are comfortable. Every developer knows them. They're discrete, testable, and fit cleanly into existing mental models. When you build an AI agent that calls CLI commands, you're essentially wrapping familiar tools with natural language interfaces.

But CLIs were designed for human operators, not AI agents. They assume:

• Sequential execution
• Human interpretation of output
• Context maintained in the operator's head
• Error handling through human judgment

AI agents don't think sequentially. They don't maintain context the way humans do. And they're terrible at interpreting unstructured CLI output designed for human eyes.

The MCP Approach: Native AI Architecture

MCP, by contrast, is designed from first principles for AI-to-software interaction. It provides:

• Structured context: Rich metadata about available operations, their parameters, and their relationships
• Semantic understanding: Operations described in ways that language models can reason about
• Composability: Tools that chain naturally because they share context protocols
• Observability: Built-in logging and monitoring designed for agent behavior

The difference is like comparing a command-line interface to a GraphQL API. Yes, you can accomplish similar things with both, but one is optimized for the actual use case while the other is a retrofit.

For product builders, the lesson is clear: When building AI-native features, resist the temptation to wrap existing interfaces. Design new protocols that match how AI systems actually work. The short-term cost of creating new abstractions pays off in long-term flexibility and capability.

The Software Factory Model

What emerges from Notion's approach is what I'm calling the Software Factory model—a new organizational structure optimized for AI-era product development.

Traditional software development follows a craft model: skilled engineers carefully building features, with quality gates and deliberate architectural decisions. The pace is measured, the process is refined, and changes are costly.

The Software Factory model inverts this:

1. Rapid Iteration as Default

Instead of trying to get it right the first time, the factory assumes you'll get it wrong—and builds for fast iteration. This means:

• Modular architecture that allows component swapping
• Abstraction layers that isolate foundation model dependencies
• Testing frameworks that work even when underlying behavior shifts
• Deployment systems that make rollbacks trivial

2. Internal Tools as R&D

The 100+ tools in Token Town aren't just productivity boosters—they're research experiments. Each tool is a hypothesis about what AI can do, tested with real users (internal teams) in real workflows.

This creates a portfolio approach to innovation. Most tools might be incremental improvements. A few will reveal breakthrough capabilities. And the cost of experimentation is low enough that you can afford to be wrong frequently.

3. User Feedback at AI Speed

When your internal teams are using AI tools daily, feedback cycles compress dramatically. You don't wait for quarterly user research. You observe patterns in real-time usage, identify friction points immediately, and iterate within days.

This is particularly powerful for AI features, where the gap between "technically working" and "actually useful" is often wide and unpredictable.

4. Architectural Flexibility as Core Competency

The ability to rebuild five times isn't just about willingness to change—it's about building systems that can change. This requires:

• Clear separation between interface and implementation
• Comprehensive testing that validates behavior, not implementation
• Documentation that assumes components will be replaced
• Team structures that expect and plan for rewrites

What This Means for Product Builders

If you're building AI-native products, Notion's approach offers several actionable frameworks:

1. Build Your Own Token Town

Start creating internal AI tools immediately. Don't wait for the "perfect" use case. Build a dozen small tools and see what sticks. The goal isn't productivity gains (though you'll get them)—it's learning.

Every internal tool teaches you:

• How to prompt effectively for your domain
• What your users will struggle with
• Where current AI capabilities fall short
• What abstractions make sense for your product

2. Design for Rebuilds

Stop trying to build AI features that will last forever. Instead:

• Isolate AI components behind clean interfaces
• Make swapping models or approaches as easy as possible
• Build monitoring that shows when performance degrades
• Create decision frameworks for when to rebuild vs. iterate

3. Choose Protocols Over Wrappers

When integrating AI into your product, resist wrapping existing interfaces. Ask: "If I were designing this interaction for an AI agent from scratch, what would it look like?"

This might mean:

• Creating new APIs specifically for AI access
• Designing structured output formats that models can consume
• Building context management systems that maintain state across interactions
• Developing error handling that AI agents can reason about

4. Compress Your Feedback Loops

The companies winning in AI aren't those with the best initial ideas—they're those who can iterate fastest. This means:

• Shipping incomplete features to learn from usage
• Building telemetry that shows how AI features are actually used
• Creating channels for rapid user feedback
• Developing intuitions about what works through high-volume experimentation

The Strategic Implications

Notion's approach reveals something deeper about competitive dynamics in AI-native products. The traditional moats—brand, network effects, switching costs—still matter. But a new moat is emerging: organizational learning velocity.

Companies that can learn faster about AI capabilities, user behaviors, and effective architectures will compound their advantages. Each iteration teaches lessons that inform the next. Each internal tool reveals insights that shape external products. Each rebuild makes the next rebuild faster.

This creates a peculiar strategic landscape where being "behind" in AI features might not matter if you can iterate faster. A company that ships a mediocre AI feature but learns quickly can overtake a competitor with a better initial launch but slower iteration.

The implication for product strategy: Optimize for learning velocity over feature completeness. Ship faster, rebuild more often, and create organizational structures that turn rapid iteration from a cost into a capability.

The Future of Software Factories

Looking ahead, I expect the Software Factory model to become standard for AI-native companies. The specific tactics will vary—not everyone needs 100+ internal tools—but the principles will hold:

• Rapid iteration as competitive advantage
• Internal tooling as R&D investment
• Architectural flexibility as core competency
• Learning velocity as strategic moat

The companies that adapt to this model fastest will define the next generation of productivity software. Those that cling to traditional development processes—careful planning, stable architectures, infrequent releases—will find themselves perpetually behind.

Notion's five rebuilds aren't a cautionary tale. They're a playbook. The question isn't whether you'll need to rebuild your AI features multiple times—it's whether you've built an organization that can do so efficiently.

Practical Takeaways

If you're building AI products today, here's what to do:

1. Start your internal tool ecosystem this week. Don't wait for perfect use cases. Build something small, learn from it, build the next thing.

2. Audit your architecture for rebuild-ability. How hard would it be to swap out your AI components? If the answer is "very hard," that's your highest priority refactor.

3. Choose MCP-style protocols over CLI wrappers. Design for AI-native interaction patterns, even if it means more upfront work.

4. Measure learning velocity, not just shipping velocity. Track how quickly you can go from insight to implementation.

5. Build teams that expect change. Hire people comfortable with ambiguity and rapid iteration. Create processes that assume components will be replaced.

The AI revolution isn't just about what models can do—it's about how organizations adapt to building on shifting foundations. Notion's approach, messy rebuilds and all, shows us what winning looks like in this new landscape.

The software factory is here. The question is whether you're building one or being left behind by those who are.