The Race to Build the Next WordPress
Igor Zalutski · April 19, 2026
WordPress still serves roughly 40% of all Internet traffic. It's more than 20 years old. It is old and clumsy and doesn't scale well and it couldn't care less about all the distributed system cloud goodness that we are all accustomed to. WordPress runs on servers. It reads and writes files. Managed VMs weren't around when WordPress was created, not speaking of containers and serverless and CDNs and the rest of modern cloud infrastructure. And yet, it remains one of the most popular pieces of infrastructure software ever, handling more traffic than most countries.
The quiet giant
WordPress powers more of the web than the next five platforms combined — despite being built before modern cloud existed.
I think that with LLM-based agents we are in a place similar to the Internet in the early 2000s. It is very clear that it's revolutionary tech and going to change everyone's life in a big way. But how exactly and when and what exactly is missing is not so clear. As before, builders in Silicon Valley stay ahead of the curve and try to create the tooling that'd become the foundational tech for the decades ahead. It involves a lot of trial and error and the right shape of tooling will only be obvious in hindsight. But we can draw some parallels to make educated guesses on where things are headed.
Earlier I called one of the missing concepts The Agentic Workload, and today came across Sandboxes are the Servers of the Agent Era by Aparna Dhinakaran. It's a great feeling to see other people thinking along similar lines. Earlier I also thought, what would be the piece of software from the early days of the internet that'd be the perfect analogy to this missing "workload" piece? I thought of Apache, itself a fork of httpd, but reading Aparna's article made me realise that an even better analogy is WordPress.
The difference is subtle but significant. Apache is a web server — it can host and run any web application, for example one written in PHP. Whereas WordPress sits a layer above; in fact it typically runs on Apache. What makes it a better analogy for the "agentic workload" is what you do with it — or rather, who and how uses it.
The layer that matters
Web, early 2000s
WordPress
the thing users actually wanted
Apache
the runtime under it
Linux / VM
server & OS
Agents, 2026
Agent Harness
the thing users actually want
Sandbox / Runtime
the workload underneath
Cloud / microVM
isolation & infra
The harness is the WordPress layer — the one users touch, fork, plug into, and build businesses on top of.
In the early days of the Internet it was quickly obvious that every person and every business would need some presence. Everyone would want a website. But making one wasn't easy. You'd need some engineering skill to create one and make it work so that everyone on the Internet could see it. Those who knew how to do it made lots of "easy money" in those days, just like people who know how to build AI agents today. Those same people started creating tools to make their life easier (and make more money to be able to serve more customers). This is how we got CGI scripts and then web servers like Apache and then engines like WordPress that are actively used for new projects to this day.
Apache became a foundational piece of "system software" that WordPress could rely on; but WordPress itself became an ecosystem of plugins and extensions and in effect created an entire industry that is booming to this day — all because lots of businesses need a website or an online store, which WordPress can support via plugins.
Agent harnesses are much more like WordPress than they are like Apache, simply because people want to have their own agents — just like everyone wanted their own website in the early 2000s. Looking at OpenClaw / Hermes one can see some striking similarities. These are rather monolithic pieces of software, ignoring many of the principles of good distributed system design — on purpose. Because building something like OpenClaw for scale, which I'm sure was done hundreds of times before Peter made the Clawdbot, would also make its application limited — very few people would have time and skill to make it work, which would defy the purpose of such software.
WordPress wasn't the best-designed CMS — Drupal was. It wasn't the most performant or reliable either. It won because it was the easiest to use.
Same principles made WordPress popular back in the day. It wasn't the most well-designed CMS — Drupal was. It wasn't the most performant or reliable either. But that didn't stop WordPress from becoming the de-facto standard for building websites and the largest ecosystem — all because it was the easiest to use. The demand for websites was seemingly insatiable; so the tool that allowed to get up and running with the lowest barrier of entry became a life-changing opportunity for so many young entrepreneurs. They were able to quickly learn just enough to make some money by building WordPress websites, and contributed back to the ecosystem by creating a myriad of extensions.
Where we are now
It seems to me that we are in a very similar place with agent harnesses today (April 2026). The demand for agents is seemingly insatiable; big labs are racing up the stack by subsidising usage and copying success stories at the application layer in a bid to retain customers who exhibit very little loyalty otherwise. Code generation is the main battleground and "every agent is a coding agent" seems to be the current consensus — surprisingly many problems that on the surface have little to do with code are solvable by agents generating and running some code. But everyone using "Anthropic agents" or "OpenAI agents" that are managed end-to-end by the big labs does not seem like a realistic scenario. I'm struggling to pinpoint exactly why, but it feels odd — a bit like people building websites using the ISP's software back in the 2000s.
History doesn't repeat, but it rhymes
ISP-bundled tooling, ~2000
- ×GeoCities (Yahoo!)
- ×AOL Hometown
- ×Tripod, Angelfire
Users were locked into the ISP's stack. When standalone tools emerged, they left.
Dedicated tooling, ~2003+
- →WordPress
- →Drupal, Joomla
- →Movable Type
Portable. Host-agnostic. Each built for one job and got best-in-class attention.
“Anthropic agents” and “OpenAI agents” look structurally a lot like GeoCities did in 2000.
ISPs tried actually — there was GeoCities and a similar platform by AOL. But these products didn't stick around for long. The reason is that as soon as a credible alternative that isn't locking the user into the ISP existed, there was no reason to not use a dedicated service for that. Plus the usual law of specialisation — a big ISP or a big AI lab only has so much attention to spare, whereas every product focused on a use case gets dedicated attention and eventually becomes best-in-class.
A Cambrian explosion of harnesses
If this analogy is right, then we will likely see sort of a "Cambrian explosion" in agent harnesses purpose-built for running server-side; and the few that win this race will become as ubiquitous as WordPress. Just like with websites earlier, every organisation on earth wants to have their own agents. They don't mind paying the AI labs for tokens, but the agent itself they'd much rather have outside of the labs' infrastructure.
What “purpose-built harnesses” might look like
Server-side agent harness
the generic “runtime”
Coding agent
PRs, reviews, migrations
Ops agent
oncall, incidents, runbooks
Sales agent
outbound, CRM, research
Research agent
deep reads, synthesis
Finance agent
close, reconciliation
Support agent
tickets, refunds, logs
Legal agent
contracts, diligence
... the rest
every vertical, eventually
One runtime, many harnesses. Each owned by the team that lives inside that problem space.
They don't mind paying the AI labs for tokens — but the agent itself, they'd much rather have outside of the labs' infrastructure.
I'm building opencomputer.dev — a sandbox built for running agents inside it.
Written by a human.