Building the Web
That Thinks

JVision is that infrastructure. Not a plugin, not an API wrapper, not a thin compatibility layer slapped over existing websites. It is a complete architectural specification — thirteen deeply considered documents, a full implementation framework, a 78-test conformance suite, and a guided build system — that defines what it means for a website to be natively usable by an AI agent in 2026 and beyond.

The question it answers is deceptively simple: if an AI agent visits your website today, what can it actually do there? The answer, for almost every website on the internet, is depressingly little. It can scrape text. It can guess at structure. It can simulate mouse clicks and hope the right thing happens. It operates, in other words, the way a blind person would navigate a building with no accessibility features — through inference, trial and error, and a great deal of luck.

JVision changes that completely.

To understand why JVision matters, you have to first understand the scale of the problem it addresses. AI agents — autonomous systems that browse, read, decide, and act on behalf of users — are not a future possibility. They are a present reality. Millions of people are already using AI assistants to research products, book travel, manage tasks, and navigate services. The number will only grow.

But here is the uncomfortable truth that most of the industry has been quietly ignoring: the web was not built for them. Every standard, every protocol, every best practice that governs how websites are built was designed with a human user in mind — someone who can see a navigation menu, read a disclaimer, click a button, and interpret the visual hierarchy of a page. AI agents have none of these advantages by default.

The result is a kind of structural mismatch that produces the failures we have all seen: agents that hallucinate facts because they could not verify content authenticity, agents that get stuck in checkout flows because they cannot reliably identify the right button to click, agents that consume enormous amounts of computational resources parsing irrelevant page chrome to extract a single piece of useful information.

JVision is a direct response to that infrastructure failure. It does not ask agents to become better at scraping. It asks websites to become better at communicating — to expose a parallel, machine-readable layer of meaning alongside the human-readable visual interface, so that an agent arriving at any JVision-compliant site knows immediately what the page is for, what it can do there, whether the content can be trusted, and how to consume that content efficiently.

What makes JVision architecturally interesting is not any single idea within it — it is the coherence of the whole. Each of the four layers solves a distinct, real problem that AI agents face today. But together they form something more than the sum of their parts: a complete contract between a website and any agent that visits it.

The Perception layer addresses the most fundamental problem. When an agent arrives at a page, it currently has to infer what that page is for from its visual structure — a deeply unreliable process for a system that cannot see. JVision replaces inference with declaration. A /agent-manifest.json endpoint tells the agent the page's intent, its primary entity type, what interactions are available, and what regions of the page update dynamically. No guessing. No parsing. No hallucination.

The Agency layer solves a problem that is even more acute: how does an agent safely take actions on a website without simulating clicks? The answer is a fully typed OpenAPI-compatible action catalogue — every available action declared with its parameters, its side effects, and its severity level. Destructive actions require cryptographically signed intent tokens valid for sixty seconds. Every non-destructive action is idempotent. Every action returns a rollback token. The result is an agent that can act confidently and safely, and a system that can recover cleanly when things go wrong.

The Veracity layer addresses what is perhaps the most dangerous problem in the current agent landscape: the inability to verify content authenticity. When an agent cites a fact it read on a website, how does it know that fact is accurate? How does it know the content has not been tampered with between signing and delivery? JVision's answer is a JWS RS256 signature on every content block, published against a JWKS endpoint, with a cryptographic content digest in the response headers. An agent that cannot verify a signature discards the content and reports the failure — it never silently passes unverified information to an LLM or a user.

The Efficiency layer completes the picture. Token consumption is not just a cost issue — it is a capability issue. An agent that spends most of its context window parsing navigation menus and cookie banners has less room to reason about what actually matters. JVision's /agent/content endpoint returns Brotli-compressed JSON-LD containing only meaningful content, accompanied by an X-Agent-Token-Estimate header that tells the agent how many tokens the response will consume before it even downloads it. Agents can pre-check whether a response fits their context window. Nothing like this exists anywhere else on the web today.

Specifications are easy to write. Specifications that anticipate the problems of a technology before those problems become crises are rare. JVision contains several design decisions that look, on the surface, like over-engineering for a first version — but which reveal their importance the moment you think even six months ahead.

The multi-agent concurrency model is one example. Most agent frameworks today assume one agent, one task, one session. JVision's specification defines a full orchestrator-delegate team model: agents can register as part of a team, an orchestrator can assign subtasks to delegates, and resource locks prevent two agents from executing conflicting destructive actions on the same resource simultaneously. This is not a feature that most JVision users will need on day one. But as agent deployments become more complex — and they will — the absence of this model would require a complete re-architecture. JVision solves it now, when the cost of solving it is low.

The human escalation protocol is another example. Nine mandatory triggers exist that cause an agent to stop, suspend its session, and wait for a human to resolve the situation before continuing. An unrecoverable error. A failed rollback. A domain whose trust has been degraded. An ambiguous destructive action. These are not edge cases in a mature agentic deployment — they are routine events. JVision treats them as first-class concerns with structured escalation payloads, urgency levels, SLA windows, and a twelve-month audit log retention requirement. It is a system designed by people who have thought hard about what happens when things go wrong at scale.

The conformance testing framework deserves particular attention. Seventy-eight named tests, organised into six categories, each with precise pass/fail criteria and a unique test ID that maps directly back to the specification document that defines it. This is not a checklist — it is a contract. Any JVision-compliant implementation can be run against this suite and receive a definitive Compliant, Partially Compliant, or Non-Compliant rating. In a world where interoperability between agent systems and web applications will be critical, having a shared conformance baseline is not a nice-to-have. It is the difference between a standard and a suggestion.

It is worth pausing to imagine the web after JVision — or something like JVision — becomes a standard expectation rather than an exceptional capability. Because the implications are not incremental. They are structural.

The first thing that changes is reliability. Today, agent failures on the web are mostly invisible. An agent scrapes the wrong content, cites an outdated fact, gets confused by a dynamic page update, and the user never knows why. In a JVision world, every content block is signed and verified. Every agent action is typed and audited. Every failure is structured, logged, and reportable. The web becomes auditable in a way it has never been before — not just for humans, but for the automated systems that increasingly act on our behalf within it.

The second thing that changes is competition. Right now, websites compete for human attention — for search rankings, for time-on-site metrics, for conversion rates measured in human clicks. In an agentic web, websites will also compete for agent adoption. An e-commerce platform that is JVision-compliant will be easier for AI shopping agents to use than one that is not. A news organisation that signs its content and publishes provenance metadata will be more likely to be cited by AI research agents than one that does not. The ability of a website to serve agents well will become a competitive differentiator as significant as mobile responsiveness was a decade ago.

The third and most profound change is trust. The current web is a largely unverified information environment. Content is easily created, easily modified, and difficult to attribute with confidence. JVision's Veracity layer begins to address this at the infrastructure level — not by policing content, but by making the provenance of content machine-readable and cryptographically attestable. An agent that cites a JVision-verified content block can report its author, its organisation, its creation date, its last verification date, and the confidence tier of its source. That is a different quality of citation than anything the current web supports.

It would be easy to dismiss the JVision interactive guide — the single-file web application that accompanies the specification — as a convenience. A table of contents with a progress bar. Something to read and then set aside.

That reading would miss the point. The guide is itself a demonstration of JVision's design philosophy applied to documentation. It is a tool built with the same seriousness of purpose as the specification it describes — interactive checklists that track your real progress through a real build, copy-paste ready prompts for every Dyad session, a conformance checklist that serves as both a learning aid and a pre-production verification step. It treats the person using it as a professional undertaking a professional task, not as a student reading a tutorial.

This matters because the hardest part of any new technical standard is not the specification — it is adoption. Standards fail not because their ideas are wrong but because the path from reading about them to implementing them is too long and too steep. JVision shortens that path dramatically. A developer who downloads the twenty-eight files, opens the interactive guide, and follows it through its ten build sessions will have a fully scaffolded, conformance-tested, production-ready JVision implementation running on Vercel. The specification and the implementation path exist together, as a single coherent artefact.

That is unusual. And it is one of the reasons JVision has a genuine chance of achieving the kind of adoption that turns a good idea into an actual standard.