# Why we built Onto · Onto Blog > The web was built for humans clicking buttons in browsers. Agents are reading it sideways. We built Onto to close that gap — Read, Serve, and Act through one engine. **Source:** /blog/why-we-built-onto **Extracted:** 2026-05-20T20:59:17.682Z --- The web wasn't built for agents. It was built for humans clicking buttons in browsers — a stack of CSS, JavaScript bundles, and tracking scripts wrapped around a few kilobytes of actual content. That stack works for people. It fails the moment a model tries to read it. Today's typical SaaS landing page weighs 400–800 KB of HTML. Of that, 2–5% is semantic text. The rest is presentation. When GPTBot, ClaudeBot, or PerplexityBot crawls one of these pages, they download everything — and burn most of their context window on utility classes and DOM noise looking for the few sentences that actually describe your product. The math doesn't get better when models get smarter. Even if a future model could understand 800 KB perfectly, sending it would still cost 100× more than sending the 8 KB it actually needs. ### The thesis Compatibility layers are how the web has always solved this kind of problem. JSON for APIs. Markdown for READMEs. Sitemaps for search engines. Each layer is a faithful representation of the same underlying thing, served in the format the consumer can actually use. Onto is the same idea applied to AI agents. Three things have to be true for the agent web to actually work: agents need to read pages cleanly, sites need to serve themselves cleanly, and agents eventually need to act on those sites without breaking when a CSS selector changes. We're calling these Read, Serve, and Act — and we're building all three on the same engine. ### Why one engine matters Most teams in this space pick a layer and ship it. Firecrawl is great at HTML-to-Markdown. Browserbase is great at browser automation. Each layer is real and useful on its own. But they compose into something the individual pieces can't deliver alone: an agent that can read a page, decide whether to trust what it read, and then act on the page with the same semantic understanding it used to read it. Action is the destination, but action depends on read. An agent clicking a "Subscribe" button needs to know what that button does — and that requires the cleaning + scoring engine read uses. Try to ship action without read and you get brittle automation that breaks the moment a class name changes. Try to ship read without scoring and your agent grounds on hallucinated facts. ### Where we are today Read is live. The [Read API](/read-api) takes a URL and returns clean Markdown plus a 0–100 [AIO score](/scoring) and per-field hallucination flags. `POST /v1/read`, bearer-token auth, sub-100 ms cache hits at the edge. Around 10× smaller payloads than raw HTML, typically. Serve is in alpha. [@ontosdk/next](/serve-sdk) is one line of middleware that detects AI crawlers and serves them clean Markdown built at deploy time, while humans continue to get the full HTML experience unchanged. We dogfood it on `buildonto.dev` — our own AIO score went from 50 to 80 the day we installed it, and Gemini stopped hallucinating our scoring formula. Act is 2027. The vision is that sites opt into making themselves agent-interactable, and agents navigate any UI through semantic intent instead of pixel coordinates. We'll ship it on the same engine that powers Read and Serve, because the cleaning + scoring work is the prerequisite — not a parallel project. ### What we're betting against We're betting that the cooperative agent web wins over the adversarial one. ScrapingBee and similar tools route around site preferences with proxy rotation and captcha bypass — valuable for general data scraping, the wrong shape for AI grounding. We honor robots.txt. We declare ourselves with a single user-agent. Sites that opt into Onto get analytics on the bots that visit them. The system only works long-term if everyone in it has reason to participate. We're also betting against models getting smart enough that this layer becomes unnecessary. They might — but tokens still cost money, and a model that can theoretically understand 800 KB of HTML is one your customers won't pay 100× to use. The economics make compatibility layers durable in a way that doesn't depend on capability stalls. ### What's next The Read API is feature-complete. The Serve SDK is filling in real-time injection and policy controls. Act starts mattering when sites that installed Serve want to let agents do things like book a demo or trigger a workflow — that's 2027 work, but the engine that powers it is shipping today. If you're building an agent that reads the web — try the [scanner](/scanner), drop in any URL, see what an agent actually receives from that page right now. If you're a site owner — install the SDK, watch your AIO score move, see which agents are crawling your content. We'll write more about each layer as it ships. Subscribe by emailing [founder@buildonto.dev](mailto:founder@buildonto.dev) if you want new posts in your inbox, or just check back here.