founder@buildonto.dev

Bengaluru, India

I am RaviRavi Pratap Singh

Founder · Onto · Open Dev Society

← Writing

5 min read

Why we don't need to rebuild software for AI agents

On the compatibility layer thesis and the inevitable lag between new users arriving and infrastructure acknowledging them.

Every few years a new kind of user shows up on the internet, and the industry's first instinct is to rebuild everything for them. Mobile users arrived and we got a decade of mobile-first rewrites. Now AI agents are arriving, and the same reflex is kicking in: agent-native APIs, agent protocols, a parallel web built for machines.

I think that's mostly wasted motion. Not because the instinct is wrong about the importance of agents, but because it's wrong about how infrastructure actually catches up to new users.

The new user nobody provisioned for

An AI agent is just a user with unusual constraints. It can read, but it reads tokens, not pixels. It can navigate, but it has no patience for a cookie banner or a 2 MB JavaScript bundle. It arrived faster than any user class in history — from zero to millions of daily sessions in under two years — and almost nothing on the web was built with it in mind.

The gap between a new user arriving and the infrastructure acknowledging them is always there. It was there for mobile, for screen readers, for the first search crawlers. What's different this time is the speed. Agents showed up before anyone had time to rebuild for them.

The rebuild reflex

When the gap appears, two camps form. One says: rebuild the web. Ship agent-native endpoints, structured feeds, a new protocol that every site adopts. The other says: meet agents where the web already is. Translate what exists into what they can use.

The rebuild camp loses almost every time, and the reason is boring. Rebuilding requires millions of site owners to do work that benefits someone else's robot. That coordination never happens on the timeline that matters. The web didn't get rebuilt for mobile; it got responsive CSS and a viewport tag. A compatibility layer beat a rewrite.

Why compatibility layers win

Compatibility layers win because they move the work to one place instead of a million. Instead of asking every publisher to expose a clean feed, you put a layer in front of the existing web that does the cleaning, structuring, and serving on demand. One team solves it once; everyone benefits immediately.

They also win on incumbency. The content agents actually need already lives on the human web — documentation, pricing pages, changelogs, forums. You don't get to ignore that and start fresh. You get to translate it.

What this means for the context layer

This is the bet behind Onto. Agents don't need a new internet; they need a layer that reads the current one for them — fetch any URL, strip the noise, return clean structured context an agent can actually use. No publisher coordination required, no protocol everyone has to adopt first.

The web will not be rebuilt for agents. It will be translated for them.

The companies that matter in this shift are the ones building the translation, not the ones waiting for the rewrite.