By Takeshi Yokoyama — Onecarat Labs
Hi. I'm Yokoyama, and I build a local-first AI text editor as a side project, along with a few other experimental tools. Working on them, I keep running into the same question about where the web is going. This post is one observation, plus a small experiment I built to test it — including a Chrome extension you can actually try.
The short version: I think websites will increasingly be read through AI agents, reshaped per reader, on the fly. And once that happens, there's a clear gap between sites that are easy for an AI to read and sites that aren't.
Until now, people read websites as websites. You open the top page, follow the menu, read the body, click a button — tracing the path the maker designed.
As local AI and AI agents become normal, that breaks. People stop opening the page directly. They tell an AI what they want — "Can I try this quickly?", "I just want to check it's safe", "Just the gist" — and the AI reads the web and reshapes it into the form that reader wants. What the reader receives is no longer the layout the maker built.
This isn't speculation. The idea that AI generates the interface for the reader already has a name — Generative UI — and it's one of the hottest areas in frontend right now, with Google, Vercel and others building toward it.
But notice who's holding the pen in almost every version of that story: the site, or an AI embedded in an app — something under the maker's control. What I'm looking at is one step past that: a local AI, in the reader's own hands, reshaping any site into that person's preferred form — with no involvement from the maker at all. The initiative moves from the maker to the reader.
I build software too. So this shift nags at me.
A site carries its maker's intent and rights. The order things appear in, what gets emphasized, the tone. Design, copy, flow — all of it is deliberate. Having an AI quietly reorder, rewrite, and re-tone that doesn't sit right with me.
But there's no escaping the other side of it: a site that AI can't read well might as well not exist. Once people search and decide through AI, a site the AI couldn't parse drops out of the running before the reader ever sees it. However carefully you wrote the HTML, if it's too noisy for the AI to read, that care turns into lost opportunity.
So there's a bind. Being reshaped without consent isn't what I want. But not being read means losing the chance entirely. Both are true at once.
I should be honest: I'm not the first to circle this. "Sites should carry machine-readable information for AI agents" is an active conversation abroad, under the name agentic web. Two reference points:
llms.txt (proposed by Jeremy Howard in 2024) — a Markdown file at your site root pointing AI at your important pages. As of 2026, adoption sits around 10%, and the major crawlers barely fetch it — yet it's increasingly framed as a "Business-to-Agent" play, and IDE agents like Cursor and Claude Code do read it routinely. Interestingly, several analyses expect the ecosystem to move from one site-level file toward per-page, machine-readable signals.
NLWeb (Microsoft, announced at Build 2025) — turns a site into something an AI can query in natural language, reusing the Schema.org structured data a site already has. Every NLWeb instance also acts as an MCP server.
So the broad direction — a human web and an AI-facing surface, side by side — isn't a hypothesis anymore. It's already moving.
Given all that, here are two gaps I don't think the existing efforts fill — and they're the point of this post.
First, the existing work is mostly about the "make me discoverable" side. llms.txt and NLWeb are largely about getting a cloud-side AI search or agent to find and cite your site — the owner pushing information out. What I'm looking at is the opposite end: a local AI in the reader's hands rebuilding the page's display for that one person's intent. The reader/viewer side. Most of the conversation leans toward "help agents discover the site"; the "the reader's local AI re-renders it per intent" side is still thin.
Second, there's almost no notion of how AI-driven reshaping coexists with the original's authority. In an era where AI summarizes, reorders, and re-tones a site, how do you preserve the maker's intent? That question is barely present in llms.txt or Schema.org. Everyone talks about how the view gets built; almost no one pairs it with "and the original stays sovereign."
My answer to the bind is to split the site into two layers — and hold them both at once.
The original (your HTML) is untouchable. The maker controls it completely. Rights and intent live here. If you want it as the maker intended, you read the original.
The derived view is the AI's to build freely. Reorder, summarize, change tone — fine. Because it doesn't touch the original. The original still stands, as the maker made it. The derived view is just one reader's way of looking, for themselves. Don't like it? Read the original.
Here's the thing that makes the free part okay: because the original is preserved, the derived view is free to be whatever it needs to be.
This is the practical bit. If the derived view is the AI's to build, the maker doesn't need to design that view. The maker does exactly one thing: make the site easier for AI to read.
Force an AI to parse human-facing HTML and you get misreadings, and instability. Better to hand over the site's information, up front, in a form the AI can read cleanly. So I describe each page as material — not layout — in a JSON file that sits beside the HTML. One extra line in the <head>
points to it:
<link rel="ai-source" type="application/json" href="index.ai.json" />
{
"version": "0.1",
"site": { "name": "Onecarat Labs", "url": "https://onecarat.dev", "purpose": "..." },
"page": { "path": "index.html", "title": "OnecaratEditor", "type": "product", "summary": "..." },
"sections": [
{ "id": "download", "title": "Download", "intent": ["try-now"], "content": "Plain-text summary..." }
],
"actions": [
{ "id": "download-latest", "label": "Download", "url": "...", "intent": ["try-now"] }
]
}
The point: this JSON is not an instruction telling the AI how to display anything. It's material, handed over so the AI can read cleanly. The freedom to summarize, reorder, re-tone stays with the reader's AI. The maker doesn't constrain it.
And the result: doing this makes the site easier for AI to read. Easier to read means less lost opportunity. The original HTML stays untouched; whoever wants it reads it. The maker only builds the on-ramp. How the view gets assembled is left to the AI.
It's closer to SEO than to a rendering engine. A site owner never tries to build Google's results page for it. They just want to be found, so they make the site easy to crawl. How the results page is assembled is Google's job. This is that — with an AI agent where the search engine used to be. (And note: the ecosystem is reportedly drifting from one site-level file toward per-page signals anyway — which is exactly the one-JSON-per-page shape here.)
Words only go so far. So I built something you can run: Onecarat Lens, a Chrome extension. It's open source.
🔗 https://github.com/onecarat-labs/onecarat-lens
Lens reads the ai-source
a site provides, and lets a local AI — Chrome's built-in Gemini Nano — assemble a view for the reader's intent, painted as an overlay on top of the original. Concretely it:
ai-source
link on the page (does nothing if there isn't one),On the same page, "I just want to try it" pushes the download and quick-start to the top; "I want to check it's safe" pushes the local-first, no-cloud, code-signing notes up instead. Same site, different shape — and the source is material the site offered, not a guess scraped from HTML.
What I want you to feel here isn't the polish of the view. It's the fact that the site got read — cleanly, on the reader's terms — and that the original is still right there, one toggle away.
I'll be honest about the rough edges. Gemini Nano is small, so when it's pushed it produces clumsy summaries, or falls back. Lens shows that fallback openly rather than hiding it. That's deliberate. The point of this experiment is honesty about what local AI can and can't do yet.
This whole idea came out of a wrong turn. An earlier version of Lens read a site's raw HTML and let the AI rebuild it directly. And it felt like overriding the maker's intent. The fix wasn't to make the AI more polite about it. It was to let the original stay sovereign, and have the site offer material for the AI on its own terms. That realization is what ai-source
is.
"HTML for humans, JSON for AI" is no longer just my hypothesis — it's already moving, as llms.txt and NLWeb. What I think is new is two things: not the discovery side but the reader's local AI re-rendering per intent, and a maker who declares nothing about the view but simply makes the site readable, paired with an original that stays sovereign.
Local AI will only get more practical. But it holds no fresh information, so it'll be asked to go and read the web. And today's human-facing web is too noisy for it. So the site offers something readable; the original stays whole; the reader sees it through their own local AI, in the shape that fits them.
Onecarat Lens is a small experiment to test that future. It doesn't replace the web. It adds an on-ramp for AI to the human-facing HTML — opened from the maker's side, deliberately, on the maker's terms.
If local AI agents become normal, sites will be read by AI too. Whether you've made yours readable, by then, is the thing that will matter.
Code: github.com/onecarat-labs/onecarat-lens · Built by Onecarat Labs