A few months ago, I shared a lecture at a doctoral symposium. The idea was simple enough: what if we stopped thinking of AI as "just another app" and started treating it as a new kind of computer?
To my surprise, that framing didn't just land—it stuck. It's already sparked a few dissertation topics and a lot of side conversations. And the more I've sat with it, the more I'm convinced this isn't just an academic curiosity. It's a preview of where modern organizations will be living in the next 3–5 years.
Here's the short version:
- We're quietly standing up a new computer on top of the old one.
- In this new computer, LLMs are the CPU, tokens are the bytes, and the context window is the RAM.
- Our data platforms, SaaS apps, and APIs become the disk and devices this AI "machine" uses to think and act.
- The primary way people interact with it isn't through menus and screens, but through language, intent, and agents.
The Old Model We Still Instinctively Reach For
For most of the modern era of tech, we've carried around the same mental picture of how computing works:
- CPU executes instructions
- RAM holds working data
- Disk stores everything long term
- On top: OS → runtime → applications → users
We've organized data centers, cloud strategies, org charts, and careers around that diagram. It's the model we teach in school and the one we still use when we explain "the stack" to non-technical colleagues.
Even in the cloud era—where we "abstract away" servers—this hasn't really changed. We may not rack and stack machines anymore, but we still:
- Rent CPU, memory, and disk from cloud providers
- Pay for them on every invoice
- Hit limits on throughput, storage, and performance
The abstraction changed; the bill did not. CPU, RAM, and disk still matter a lot. What's shifting now is who is using them and how we reason about the system on top.
A Different Computer Is Emerging
Because at the logical level—the level where we design experiences, architect systems, and decide where to invest—there's a different "computer" emerging:
- CPU → Large Language Model (LLM)
- Bytes → Tokens
- RAM → Context Window
- Disk → Knowledge & Tools (RAG, SaaS, APIs)
- OS → Orchestration, Agents, Policies
We've put a new computer on top of the old one. And if we keep thinking only in terms of the old diagram, we will miss where the leverage is actually moving.
This isn't an AI add-on. It's a new computer organization that's going to change how we design applications, how people interact with technology, and how we architect for the business.
The LLM as CPU, Tokens as the New Bytes
In this new computer:
The LLM is the CPU. It's the execution engine. It decides which tools to call and how to combine results. We "program" it with prompts, system instructions, examples, and policies.
Tokens are the new bytes. The model doesn't see raw bytes; it sees tokens. Tokens are the unit of work, latency, and cost. We plan around max tokens, not just memory limits.
So the real levers have shifted. We still care about vCPUs, RAM, GPUs, and storage in the cloud, but on a daily basis we care more about:
- How many tokens per request?
- How many tokens per user journey?
- How many tokens per unit of business value?
Those tokens ultimately translate back into real CPU/GPU cycles and RAM usage in somebody's data center. The cloud just hides the iron. The LLM is happily burning compute; we're just paying for it in a different currency.
If we ignore that, we end up with AI experiences that are magical in demos and brutal in production.
Context Window as RAM: Working Memory for Intelligence
Every LLM has a context window: a hard limit on how much information it can "see" in one shot.
That context includes:
- System instructions and guardrails
- The user's current request
- Conversation or workflow history
- Retrieved documents, records, and policies
- Tool definitions and recent outputs
If something isn't in the context window, the model can't actively reason about it in that pass. It's effectively out of RAM.
So the question quietly becomes: "What deserves to be in the context window right now?"
We've been asking versions of this question for decades:
- In the old world: "What data and instructions should live in memory vs disk?"
- In the cloud world: "What should live in hot cache vs cheap storage?"
- In the new AI world: "What instructions, history, and knowledge should live in context vs external stores?"
This is why I've been talking about context engineering as a discipline. If the context window is the new RAM, context engineering is the new memory management:
- Selecting the right facts to bring in
- Summarizing and compressing history
- Avoiding overloading the model with noise
- Being intentional about what you don't include
We used to worry about thrashing the CPU cache. Now we worry about thrashing the context window.
The organizations that treat context like a first-class resource will get AI that looks "smart." Everyone else will blame the model for what is, in reality, a memory-management problem.
Disk Becomes Knowledge + Tools
Below the context window, we have a new "disk and I/O" layer:
- Knowledge stores – data warehouses, lakes, document repositories, wikis
- Vector stores – embedding spaces for semantic retrieval (RAG)
- Operational systems – CRM, ERP, ticketing, DCIM, billing, monitoring
- Tools and APIs – things the system can do in the real world
The LLM doesn't read your entire data estate or SaaS portfolio raw. It sees:
- Snippets fetched via RAG and injected into context
- Tool results that appear as function outputs or text
So the shape of the stack starts to look like:
- LLM (CPU)
- Context Window (RAM)
- Knowledge + Tools (Disk / Devices)
- Humans & Agents (Users)
Your existing systems and SaaS products are still critical—now they're the peripherals and storage this AI computer uses.
The big change is that they're no longer the only place users go. They're the places an AI front end goes on behalf of your users.
Why This Isn't Just a Cute Metaphor
You could look at all of this and say, "Okay, nice analogy, but so what?"
Here's why it matters:
The bottlenecks move. In the old model: CPU, RAM, I/O. In the cloud: quota limits, instance sizes, throughput caps. In the new model: context window, token budgets, retrieval quality. If we don't design for the new bottlenecks, our AI efforts will hit invisible ceilings.
The levers move. We used to tweak configs, indexes, and hardware. Now we tweak prompts, context building, and tool design. That requires new skills, new metrics, and new responsibilities.
The center of gravity moves. Instead of "users in apps," we're headed toward "users with agents." The primary client of your systems becomes an AI front end. That changes how we think about software, support, and architecture.
The experience layer moves up. The real "experience" becomes the conversation layer. Everything below is judged by how well it supports that experience.
Where This Is Pointing
If we accept that AI models are becoming the new CPU, the context window is the new RAM, and our data and systems are the new disk and devices, then the natural next questions are:
- What does "software" become in that world?
- What happens to traditional applications when the front end is a conversation?
- How do SaaS products need to evolve when agents, not humans, are their primary "users"?
- What kind of architectures let us exploit this shift instead of being disrupted by it?
That's where we'll go in Part 2: When AI Is the Front End.
Because if AI is now the computer, then everything we currently call "software" is about to get redefined as the tooling and memory that computer relies on.