HTML Is the Interface

Lately I have been asking AI agents to operate web pages for me. Find a record, fill in a form, locate an item in a list: the tasks are simple. What consumes the effort is everything around them. A button has no name, the content exists only on a canvas, a link is not really a link, and the result of a submission flashes in a corner and disappears. A person takes one look and knows what to do. An agent has to infer it from visual cues and a pile of DOM nodes.

That has made me imagine a more restrained kind of web page. Use basic HTML and put the content and operations directly in the document. Let CSS keep it readable and JavaScript provide optional enhancements. People can still browse, click, and fill things in, but without elaborate animation, drag-only interactions, and layers of dialogs. An agent using a tool such as BrowserMCP no longer has to understand an interface designed around visual effects before it can get the job done.

This is not a proposal for a separate agent web. It is the opposite: do not add another special-purpose protocol; treat HTML itself as the interface. Do not build a second page for agents; make the same page direct for both people and agents.

Agents should not have to guess better

Using a browser to complete a task is a loop: observe the current state, choose a step, perform it, and inspect the result. The more a page depends on position, color, hover states, and transient controls, the more guessing that loop contains. Experience tells a person what an icon-only button probably means. A button without text or an accessible name leaves an agent with only a suggestion: guess what this picture usually does.

We can, of course, make models better at screenshots, layout, and mouse movement. But using a stronger model to compensate for an ambiguous interface shifts a design cost onto every visit. Every visit must recognize the interface again, and every visit has another chance to click the wrong thing. The cheaper approach is for the page to state what this is, what it can do, and what happened after it was done.

Agent-friendly therefore does not mean stuffing a page with special machine-readable annotations. The basic requirement is much more ordinary: let the observation, the action, and the result all be read unambiguously from the document.

Content should be a document, not a picture

Such a page starts with a plain structure. It has a clear title, its body sits in a main, sections use headings in a sensible hierarchy, navigation uses links, lists are ul or ol, and tabular data goes in a table. Important information exists as text in the HTML, not only in an image, on a canvas, or inside a script's state after the page has run.

These elements are not there to pass a conformance check. They remove ambiguity. A heading says what the page is about, a list says these items belong together, and table headers explain the columns. A person sees the formatted result; an agent reads the same structure. There are not two separate understandings of the page to maintain.

Links should be real links too. A resource has a stable URL, so opening, refreshing, bookmarking, and handing it to someone else all refer to the same thing. The next page is an a href, not a div that changes internal state when clicked. Infinite scrolling can remain as a convenience, but there should at least be a paged route through the collection. Otherwise an agent cannot readily tell whether it has seen the whole list or return to its place after an interruption.

Actions should return to links and forms

Read-only pages are the easy part. Operations reveal the real difference. Many modern interfaces scatter an action across a chain of script events: click this region, drag that card, wait for a menu, then choose among unexplained options. This may feel smooth to a person. To an agent, every step is another piece of state and another point of failure.

In the main flow I imagine, an ordinary form says enough:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>New task</title>
  </head>
  <body>
    <main>
      <h1>New task</h1>
      <form method="post" action="/tasks">
        <p>
          <label for="title">Title</label><br>
          <input id="title" name="title" required>
        </p>
        <p>
          <label for="description">Description</label><br>
          <textarea id="description" name="description"></textarea>
        </p>
        <button type="submit">Create task</button>
      </form>
      <p><a href="/tasks">Back to tasks</a></p>
    </main>
  </body>
</html>

This code has no visual ambition, but it already describes the interface. The label says what to enter, name says what will be submitted, the button says what will happen, and action and method say where the operation goes. A person can use it in a browser, and so can an agent. The main task still works if JavaScript never loads.

Searches can use ordinary GET forms where possible, leaving their conditions in the URL. Creation and editing get explicit forms and submit buttons. A destructive action should not be disguised as an ambiguous click. There is no new technology here, only a constraint: do not use an apparently flexible event system to reinvent what the browser already knows how to do.

The result has to remain

Finishing an operation is only half the flow. An agent also needs to know whether it succeeded and, if not, where it failed. A toast that vanishes after two seconds, a border that only changes color, and a spinner that never stops do not explain the result.

A more reliable approach makes the result part of the page state. After a successful creation, navigate to a detail page with a stable URL and show the new object in its heading and body. On failure, render the form again, preserve the input, and list the errors as text. A dynamic page can update the current document, but the state cannot live only in a script's memory, nor require the visitor to be watching at precisely the right second.

This helps people for the same reasons. They can refresh after a network failure, correct a form without starting over, and copy the link to a completed object for someone else to inspect. Reducing uncertainty for an agent usually reduces it for a person too.

Restraint is not crudeness

Keeping basic features does not mean going back to an era of default blue links and no concern for reading. A sensible line length, clear hierarchy, adequate contrast, visible keyboard focus, and controls large enough to use on a phone should all remain. Basic interaction means more than accepting a submission: a clear way back, correctable input, understandable pagination, and useful errors are part of it too.

What goes is unnecessary indirection. If a link can provide navigation, do not require a gesture. If a button can perform an action, do not make dragging the only option. If an explanation can be visible, do not hide it behind hover. If an ordinary page can handle confirmation, do not bury it inside three dialogs. CSS and JavaScript can still improve these flows, but removing them should not leave behind a pile of meaningless containers.

This is not reducing what a page can do. It is giving those capabilities a dependable base: make the HTML complete first, then give enhancements somewhere to happen.

Do not open a separate agent edition

An obvious alternative is to keep the existing page and offer a simplified entry point such as /agent or ?format=agent. That may help during a migration, but I would not want it as the end state. Two versions drift apart. The simplified one eventually loses fields, falls a release behind, or becomes read-only. Once again, agents get the second-class version.

A better arrangement is one semantically complete HTML document, with visual presentation and optional enhancements for people. A person sees a designed page; an agent reads the same resource, the same operations, and the same result. Keeping the base unified means the site does not have to maintain two versions of the truth.

None of this replaces APIs. High-frequency calls, batch processing, and durable system integrations still belong behind an explicit API contract. The web fits a different case: an occasional, variable task where an agent uses an existing account and permissions under human supervision. Tools such as BrowserMCP matter because a site need not publish a dedicated interface for every possible task. Semantically clear HTML makes that general path less dependent on guesswork.

Accessible does not mean undefended

Making a page easy for an agent to understand does not mean allowing the agent to perform every action on it. Reading and writing need different permissions, sensitive operations need explicit confirmation, and the server must still check identity, authorization, and request origin. A simple form is no substitute for a security boundary.

Less script and decoration also does not solve prompt injection or make web content trustworthy. Text on a page remains external input, and an agent still has to distinguish what the page says from what it should obey. Restrained HTML provides clarity, not immunity.

Design the interface a little less

What attracts me most to this idea is how little it asks us to invent. Headings, paragraphs, links, lists, tables, forms, and stable URLs were part of the web early on, and they can already describe most reading and operations. The abstractions added since have real value, but they also routinely wrap the simplest task in the most elaborate representation.

If a page's main flow can again become an operable document, people need not learn a redundant set of gestures, and agents need not reproduce every visual judgement a person makes. For the agent era, a radical kind of web design may be to design a little less: make content directly readable, actions directly performable, and results directly visible. The browser can take care of the rest.