How we thought about software
For the past 40 years, software worked like this:
- You build it once
- You maintain it for years
- You protect the investment
- The system becomes the asset
- Stability is success
This made sense. Building software was expensive. Changing it was risky. The longer a system lasted, the better your ROI.
You built for permanence.
Companies hired teams to maintain legacy systems. They celebrated "battle-tested" architectures. They avoided rewrites because they were expensive and dangerous.
The incentive structure was clear: build something that lasts.
AI breaks all of this
Models improve every 6 months. What required a complex multi-agent system in January can be done with a single model call by June. The prompts that worked yesterday might be obsolete tomorrow. The architecture you built isn't an asset - it's a snapshot of what was possible at the time.
Look at what keeps happening:
- You built a RAG system → models got 200k context windows (Claude, GPT-4, Gemini with 1M+ tokens) → now direct context is simpler for many use cases
- You built multi-agent orchestration → models got better at reasoning (Claude 4's extended thinking, GPT-4.5) → now single-agent is sufficient
- You built elaborate prompt chains → models got better at instruction following → now simple prompts work
Context windows have evolved dramatically: from GPT-3's 2,048 tokens to 200K+ tokens for Claude and 1 million tokens for Gemini - all in just a few years.
Every 6 months, something you built becomes unnecessary.
Disposable Intelligence is about building what you can rebuild.
What you actually protect
Think of it in three layers:
Disposable layer:
- The specific model (Claude, GPT, Gemini)
- Your prompt engineering
- Your architecture choices (RAG vs long-context, single-agent vs multi-agent)
This changes every 6 months. Let it go.
Portable layer:
- Your data structures and schemas
- Your integration patterns (MCPs, APIs, abstractions)
- Your input formats that work across models
This is your flexibility. This is why MCPs (Model Context Protocol) matter - they let your data talk freely to any AI without rebuilding integrations. Anthropic launched MCP in November 2024, and it's since become the de-facto standard with over 97 million monthly SDK downloads and adoption across major AI platforms.
Durable layer:
- Your business logic and domain expertise
- Your evaluation framework
- Your proprietary data
- The outcome you're optimizing for
This is your actual asset. Everything else exists to serve this.
What about RAG vs Long Context?
Here's where it gets interesting: RAG isn't obsolete just because context windows got bigger.
Research from Li et al. (2024) found that while long-context models can outperform RAG in quality when given unlimited resources, RAG's cost advantage remains significant - it's 8-82× cheaper than long context approaches for typical workloads.
The key findings:
- RAG still excels for cost efficiency and retrieval precision
- Long-context is better when you need to see everything at once
- The best approach? A hybrid system that routes queries intelligently
The point isn't "RAG vs Long Context" - it's about building systems you can swap when something better arrives.
How to build for disposability
Once you understand the layers, building for disposability becomes clear:
Structure inputs for portability, not optimization.
Don't write prompts that only work with one model. Create data structures any model can consume. When a new model arrives, you should be able to test it in minutes, not months.
Abstract away the model layer.
Your application code shouldn't care if it's talking to Claude or GPT. Use API wrappers, routing layers, anything that lets you swap providers in one line of config. The model is infrastructure, not architecture.
Measure outcomes, not system metrics.
Stop tracking "system uptime" and start tracking "are we getting better results?" If a new model delivers 20% better outcomes, the rebuild cost is worth it. Always.
Build evaluation before building solutions.
You can't know if you should rebuild unless you know what "better" looks like. Clear metrics let you test new approaches cheaply. Without this, you're flying blind.
Treat architecture as hypothesis, not conclusion.
Your 5-agent system? That's a hypothesis about what it takes to get the outcome. When a better model arrives, test if a simpler approach works. If it does, switch. No ego. No attachment.
Kill your darlings quarterly.
Every 3 months, ask: "If we were starting today, would we build this the same way?" If the answer is no, you know what to do. The fact that you spent 6 months building it is irrelevant. The question is: is it the best way now?
What This Actually Looks Like:
Bad approach:
"We invested in building this 5-agent system with custom RAG and it works, so we're sticking with it."
Better approach:
"We built with MCPs so we can swap models easily, and our inputs are structured for portability."
Best approach:
"We built with MCPs and we have a weekly sprint where we test if a simpler architecture would work just as well with new models. Our evaluation framework makes it cheap to test this."
Here's what happens when you actually do this:
The teams that protect their systems spend 6 months defending why their approach still makes sense. They write documents. They explain context. They justify complexity.
The teams that protect their workflows spend 6 days testing if there's a better way. They run experiments. They measure outcomes. They switch when something's better.
One team is optimizing for construction. The other is optimizing for outcomes.
When everyone has access to the same models, your competitive edge isn't how clever your current architecture is. It's how fast you can adopt the next breakthrough.
Key Sources & Further Reading:
- Model Context Protocol (MCP) - Official Announcement
- MCP joins the Agentic AI Foundation
- Retrieval Augmented Generation or Long-Context LLMs? (Research Paper)
- Why RAG is Still Relevant in the Era of Long-Context Models
- Context Window Evolution Timeline
- RAG is Dead, Long Live RAG: Retrieval in the Age of Agents