We’re living through the same chaotic fragmentation that web developers faced in the mid-2000s, just with AI agents instead of browsers.
Table of contents
Open Table of contents
The crisis text to my wife
Last week I spent three hours trying to connect an AI agent to Google Drive. Then another two hours connecting it to Slack. Then I stared at my screen and realized I’d need to do this same painful dance for every single tool I wanted to add.
This is the exact moment where I texted my wife “I’m having a crisis” and she responded “is it technical or existential” and honestly? Both.
This exact frustration - this “why is this so unnecessarily hard” feeling - I’ve felt it before. Not with AI, but with JavaScript in the mid-2000s when every browser was its own special snowflake and cross-browser compatibility was more prayer than engineering.
We’re watching the same movie again, just with different actors. And if the pattern holds, we’re about to see something change dramatically in how AI agents work. (Or we’re all going to burn out first. Could go either way.)
A history lesson I wasn’t around for
I need to be honest: I wasn’t around for the original browser wars. They kicked off in 1995, and unless you’re significantly older than me, you probably weren’t either. But I’ve read enough horror stories to know it was absolute chaos.
Developers had to write the same code three completely different ways because Microsoft, Netscape, and everyone else decided to implement JavaScript however they felt like it. Websites had “Best viewed in Internet Explorer 6” badges - not ironically, but because the site literally wouldn’t function anywhere else. It was like putting “Please use the blue front door, the red one leads to a different dimension” on your house.
The W3C would publish standards. Companies would ignore them. Why follow standards when you’re trying to win a war? (Spoiler: both sides lost. The real winner was frustration.)
It was the kind of mess that makes my current integration problems look quaint. Which is saying something, because my current problems make me want to throw my laptop into a lake.
Then jQuery changed everything
In 2006, John Resig released jQuery at BarCamp NYC. And look - it wasn’t magic. It didn’t convince Microsoft and Mozilla to suddenly agree on how JavaScript should work. (That would’ve required actual magic, possibly involving a time machine and some very stern conversations.)
What it did was way more practical: it abstracted away all the pain.
Instead of writing different code for every browser, you wrote jQuery once. One line of $('#element').hide() worked everywhere. No browser detection. No conditional logic where you sacrifice a rubber duck to the debugging gods. Just code that actually worked.
By 2022, jQuery is used by 77% of the 10 million most popular websites. People learned jQuery before they learned vanilla JavaScript. It became so dominant that “I know jQuery” was a legitimate resume bullet point. (Some hiring managers still think it is. We need to have a talk with them.)
But here’s what jQuery really was: incredibly good duct tape.
It didn’t solve the underlying standards problem. It didn’t make browsers agree on anything. It just made building for the web less miserable while the slower work of actual standardization happened in the background.
And you know what? That was enough. We built incredible things with that duct tape. Some of those things are still running in production today. (Please don’t look at my GitHub history from 2010. I’m begging you.)
Welcome to 2025: same energy, different stack
So here I am in 2025, staring at my AI agent code, feeling that same frustration. My coffee’s gone cold. My rubber duck looks judgmental. This is fine.
I pick a framework - LangChain because everyone uses it, or Vercel’s AI SDK because it seems straightforward. I get my agent running. Great! Then I need it to actually do something useful, which means connecting it to real tools.
Google Drive needs its own authentication flow. Slack needs different error handling. My database needs yet another approach. Every single integration is custom code from scratch. It’s like being asked to rewire your house using a different color wire standard for every room, except if you mess up, the house doesn’t just lose power - it emails your entire contact list about it.
It’s exhausting. And it’s exactly like writing cross-browser JavaScript in 2005, except now when your code misbehaves, it can send emails to your entire customer list or drop your production database.
This is usually the point in the project where I start wondering if I should have stuck with baseball card collecting as a career. Baseball cards don’t have API rate limits. Baseball cards don’t throw 429 errors. Baseball cards just sit there, appreciating in value, being peaceful.
MCP shows up to save us
This is where the Model Context Protocol comes in, and why I think we’re watching history repeat itself.
Anthropic released MCP in November 2024, and it does for AI agent integration what jQuery did for browser compatibility: provides a standardized layer that makes the pain manageable. (Will it also generate 10,000 Stack Overflow questions with accepted answers from 2026 that no longer work? Time will tell.)
The concept is straightforward. Instead of writing custom code for every single agent-tool combination, you write it once in the MCP standard. Build one MCP server for Google Drive, and every MCP-compatible agent can use it. Build one MCP client in your agent, and it can connect to every MCP server.
It’s like when USB-C finally became standard. Before that, every device needed its own special cable, and you’d inevitably grab the wrong one in the dark at 2am when your phone was dying. Now? One cable, everything charges. MCP is doing that for AI agents and tools. (Except hopefully without the “Is this cable data transfer or just charging?” confusion.)
OpenAI and Google saw the problem and adopted it. Anthropic released pre-built servers for Google Drive, Slack, GitHub, Postgres. Is the code perfect? No. Does it work well enough to ship with? Yeah, actually it does. Will I still spend three hours debugging why it’s not working only to discover I forgot to set an environment variable? Absolutely. That’s tradition.
Why this pattern feels so familiar
The more I think about it, the more MCP feels exactly like jQuery’s moment:
It’s pragmatic over perfect. MCP doesn’t solve every problem with agent orchestration. Security is still hard. Long-running workflows are still complicated. Error messages are still cryptic enough to make you question your life choices. But it makes the most painful part - connecting things - significantly less painful. That’s enough.
It solves the problem I have today. I don’t need a five-year vision of perfect AI infrastructure. I need to ship an agent that can read my emails and summarize my support tickets this week, ideally before my PM asks why it’s not done yet. MCP lets me do that. (The PM will still ask. That’s also tradition.)
It gets things shipping.Just like jQuery enabled a generation of web apps while browser vendors slowly figured out standards, MCP is letting us build real agents while the industry sorts out what these standards should actually look like. We’re shipping with duct tape while the architects argue about the blueprint. This is how software gets made.
And here’s what I keep coming back to: jQuery wasn’t a failure because it was temporary. It was a massive success because it enabled innovation while harder problems got solved in the background. We don’t really use jQuery anymore, but we built the modern web with it. (And yes, there are still production sites running jQuery 1.4.2. We don’t talk about those sites.)
But this time it’s faster (and the stakes are higher)
There are some key differences that make this both more exciting and more terrifying than the browser wars.
The timeline is compressed. The web took nearly two decades to go from fragmentation to reasonable standardization. HTML5 didn’t become official until 2014 - nineteen years after the first browser war started. My kids will probably learn about the browser wars in history class. ChatGPT launched in late 2022. MCP was announced in late 2024. We’re measuring this in months, not decades. At this rate, by the time you finish reading this article, there might be a new competing standard. (There won’t be, but it feels that fast.)
The consequences are real.When Internet Explorer crashed, you hit refresh. Annoying, sure, but not catastrophic. Maybe you lost your carefully crafted forum post because browsers didn’t auto-save back then, but that’s the worst of it. When an AI agent crashes, it might have already executed a bunch of financial transactions or deleted important data. The security model can’t be an afterthought this time. We can’t just put “Works best in Claude” badges on our agents and call it a day.
The war isn’t over. MCP isn’t the only protocol trying to solve this. Google’s working on Agent2Agent. There’s the Agent Communication Protocol. Various other frameworks claim different solutions. MCP has momentum, but nothing’s guaranteed. The ceasefire could end any day, and we’ll all be back to writing custom integrations while questioning our career choices. (I’ve already questioned mine twice today. It’s barely noon.)
Just ship it with duct tape
Look, this isn’t me saying MCP is perfect or permanent. It’s duct tape for AI agents. Eventually we’ll probably replace it with something better, the same way we replaced jQuery with modern JavaScript frameworks. (Then replaced those frameworks. Then replaced the replacements. Web development is just replacement turtles all the way down.)
But right now, I need to build things. You probably need to build things. We need our agents to connect to tools, to work with data, to integrate with whatever new service the product team just decided is essential after reading a single tweet.
MCP might be the answer. Or it might be a stepping stone. Either way, it’s helping us ship today while the industry figures out tomorrow.
And honestly? Sometimes duct tape holds up longer than you expect. Sometimes it becomes the foundation for something better. Sometimes it just gets you through to the next thing. And sometimes - and I say this as someone who once used actual duct tape to fix a production server issue at 3am - duct tape is exactly what you need.
I’m okay with all of those outcomes. Let’s build something. Just let me refill my coffee first.