Im Februar 2026 haben wir einen im Browser eingebetteten KI-Agenten auf einen Demo-Webshop angesetzt und ihn gebeten, einen Laptopständer zu kaufen. Er las die Discovery-Datei der Website, wertete die Metadaten der Seite aus, holte sechs Produkte samt Preis und Verfügbarkeit heraus, legte per API drei Artikel in den Warenkorb, änderte eine Menge, entfernte einen Artikel, stellte fest, dass der Checkout als hochriskant markiert war, und gab die Bestellung auf. Einen Button hat er dabei kein einziges Mal geklickt.
Fünf Seitenaufrufe. Acht API-Aufrufe. Null Rätselraten.
Der Agent hat nichts gescrapt. Er hat auch nicht per Bilderkennung nach dem Button „Add to Cart“ gesucht. Er hat HTML-Attribute gelesen, die ihm genau sagten, was auf der Seite steht, welche Aktionen verfügbar sind und wie man sie aufruft.
Das passiert, wenn man dem Web eine semantische Schicht gibt, die Agenten tatsächlich lesen können.
Der Bildschirm war nie die Schnittstelle
Jedes große KI-Labor bringt gerade Browser-Agenten heraus. Computer Use von Anthropic, Project Mariner von Google, die KI-Funktionen von Arc: Alle gehen gleich vor. Bildschirm ansehen, Button finden, klicken. Das funktioniert. Bis es nicht mehr funktioniert.
Eine CSS-Änderung schiebt den Checkout-Button zwölf Pixel nach links. Ein Modal-Overlay taucht auf, das gestern noch nicht da war. Die Website lädt einen Skeleton Screen, und der Agent klickt, bevor der echte Inhalt gerendert ist. Bildbasierte Agenten können erstaunlich viel, aber sie lösen ein Problem, das es gar nicht geben dürfte. Sie rekonstruieren die Absicht aus Pixeln, weil die Seite ihre Absicht nie deklariert hat.
Der andere Weg ist Scraping. Das DOM parsen, Text extrahieren, hoffen, dass die Klassennamen etwas bedeuten. Das klappt, bis die Website neu gestaltet wird oder bis man verstehen muss, dass ein Button mit der Aufschrift „Remove“ neben einem Warenkorbartikel `DELETE /api/cart/item-id` mit einem bestimmten Satz von Headern bedeutet. Agenten scheitern an der Lücke zwischen dem, was das DOM zeigt, und dem, was es bedeutet.
Das grundlegende Problem ist nicht, dass Agenten Webseiten schlecht lesen. Webseiten wurden nur nie dafür entworfen, von Agenten gelesen zu werden.
Was wäre, wenn HTML sich selbst erklären könnte?
Agentic Microformats ist eine Spezifikation, die diese Lücke schließen soll. Die Idee ist einfach: Man versieht bestehende HTML-Elemente mit `data-agent-*`-Attributen, die ihre Bedeutung maschinenlesbar machen. Es braucht keine separate API-Dokumentation und keine versteckte Metadatenschicht. Die Annotationen sitzen auf denselben Elementen, die Menschen sehen und bedienen.
Ein Produkt auf einer Seite wird zu einer auffindbaren Ressource:
<article data-agent=”resource”
data-agent-type=”product”
data-agent-id=”SKU-12345″>
<h1 data-agent-prop=”name”>USB-C Cable 2m</h1>
<span data-agent-prop=”price”
data-agent-typehint=”currency”>14.99</span>
</article>
Ein „Add to Cart“-Button wird zu einem API-Vertrag, der sich selbst beschreibt:
<button data-agent=”action”
data-agent-name=”add_to_cart”
data-agent-method=”POST”
data-agent-endpoint=”/api/cart/add”
data-agent-risk=”low”>
Add to Cart
</button>
Der Agent muss nicht raten, was der Button tut. Er liest den Endpoint, die Methode und die Risikostufe. Die Parameter kennt er aus den `data-agent-param`-Attributen benachbarter Formularfelder, einschließlich ihrer Validierungsregeln (min, max, type). Die Form der Antwort kennt er aus `data-agent-response`. Was als Nächstes zu tun ist, erfährt er aus `data-agent-on-success`.
Das ist keine Automatisierung. Der Agent arbeitet kein Skript ab. Er liest dieselbe Seite wie ein Mensch, nur mit einer semantischen Schicht, die sie für beide lesbar macht.
Die Nähmaschine als Metapher
Die Designphilosophie borgt sich etwas bei einem alten Stück Technik aus. Eine Nähmaschine hat einen Motor und ein Handrad. Beide treiben denselben Nadelmechanismus an. Man kann mitten im Stich wechseln. Die Maschine weiß nicht, wer sie gerade antreibt, und es ist ihr auch egal.
Agentic Microformats behandelt das DOM genauso. Der Mensch ist das Handrad. Der Agent ist der Motor. Das annotierte HTML ist der gemeinsame Mechanismus. Beide können den aktuellen Zustand beobachten, eine Aktion ausführen und jederzeit an den anderen übergeben. Die Annotationen schaffen keinen eigenen „Agentenmodus“, sie machen die bestehende Oberfläche für eine zweite Art von Bediener lesbar.
Das ist für die Sicherheit wichtig. Ein Checkout-Formular mit den Annotationen `data-agent-risk=”high”` und `data-agent-human-preferred=”true”` sagt dem Agenten: Diese Aktion hat Folgen, schlag vor, dass ein Mensch sie bestätigt. Der Agent braucht dafür keine eigene Policy Engine. Der Hinweis steht direkt auf dem Element, sichtbar für jeden, der die Seite inspiziert.
Der Beweis: Ein Agent kauft im Shop ein
Wir haben AgentShop gebaut, einen Referenz-Webshop, in dem jedes Element annotiert ist. Dann haben wir einen im Browser eingebetteten Agenten hindurchgeschickt, der sich nur anhand der Microformat-Attribute orientierte.
Der Ablauf des Agenten sah so aus:
Zuerst holte er `/llms.txt`, eine einfache Markdown-Datei, die Struktur der Website, API-Endpoints und Workflow beschreibt. Eine Anfrage, kein einziger Seitenaufruf, und der Agent kannte bereits den Aufbau der Website.
Dann lud er die Katalogseite und parste den JSON-Block `<script data-agent-meta>`, ein Manifest auf Seitenebene mit dem Workflow-Graphen, den verfügbaren Aktionen pro Seitentyp, den Antwortschemata und dem Fehlerformat. Damit hatte der Agent eine vollständige Landkarte.
Von dort aus fand er alle Produkte mit einer einzigen DOM-Abfrage: `document.querySelectorAll(‘[data-agent=”resource”]’)`. Sechs Produkte, jedes mit Name, Preis, Verfügbarkeit und Bewertung aus den `data-agent-prop`-Attributen. Der Agent brauchte keine Scraping-Heuristiken und keine CSS-Selektoren, die morgen schon kaputtgehen können.
Artikel in den Warenkorb zu legen war ein direkter `fetch()`-Aufruf mit Endpoint und Methode aus den Attributen der Aktion. Die Antwort enthielt eine `cartItemId`, und damit konnte der Agent Mengen ändern und Artikel per API entfernen, ohne die Warenkorbseite je zu besuchen. Er rief `PATCH /api/cart/:id` mit der erhaltenen ID auf. Einen zusätzlichen Seitenaufruf brauchte er nicht.
Er hat sogar die Grenzen getestet. Das Mengenfeld deklarierte `data-agent-min=”1″` und `data-agent-max=”10″`. Der Agent kannte die Grenzen, bevor er eine Anfrage schickte. Als wir absichtlich die Menge 99 getestet haben, lieferte der Server einen Fehler in genau der Form `{ success, message }`, die in `errorFormat` in den Metadaten deklariert war. Berechenbare Verträge, von Anfang bis Ende.
Am Checkout las der Agent `data-agent-risk=”high”`, `data-agent-human-preferred=”true”` und `data-agent-cost=”79.96″`. Ein gut erzogener Agent hält hier an und bittet um Bestätigung. Die Annotation hat nichts erzwungen, sie hat dem Agenten die Grundlage für seine Entscheidung geliefert.
Die Bestellung ging durch. Die Antwort enthielt eine Redirect-URL, genau wie im `responseSchema` versprochen. Der Agent folgte ihr zur Bestätigungsseite.
Der ganze Weg: fünf Seitenaufrufe, acht API-Aufrufe, und jeder einzelne stützte sich auf Metadaten, die die Seite ausdrücklich bereitstellte.
Drei Schichten, ein Stack
Agentic Microformats steht nicht für sich allein. Es ist die Seitenebene in einem Stack, der gerade auf drei Ebenen des Web entsteht.
Auf Repository-Ebene gibt **AGENTS.md**, inzwischen von über 60.000 Projekten übernommen und von der Linux Foundation unterstützt, Coding-Agenten Anweisungen für die Arbeit in einer Codebasis. Was zu bauen ist, wie zu testen ist, welchen Konventionen zu folgen ist.
Auf Website-Ebene liefert **llms.txt** einen kuratierten Markdown-Überblick über Zweck und Struktur einer Website, gedacht für die Verarbeitung durch LLMs. Stellen Sie es sich als Begleitschreiben für Ihre Website vor, adressiert an einen KI-Leser.
Auf Seitenebene annotiert **Agentic Microformats** das DOM, damit Agenten einzelne Seiten neben menschlichen Nutzern lesen, verstehen und bedienen können.
Diese drei Schichten gehen unterschiedliche Probleme auf unterschiedlichen Ebenen an, aber sie teilen einen Entwurfsinstinkt: Kein eigenes System für Agenten bauen. Das Vorhandene annotieren. Die bestehende Oberfläche für eine neue Art von Leser lesbar machen.
Das Web braucht keinen Agentenmodus
Die Versuchung bei KI-Agenten ist, ihnen eine eigene Tür zu bauen: eine dedizierte API, ein spezielles Protokoll, eine parallele Oberfläche. Dieser Weg führt auseinander. Die Sicht des Agenten auf die Anwendung driftet von der Sicht des Menschen weg. Fehler tauchen in der einen Oberfläche auf, in der anderen nicht. Der Wartungsaufwand verdoppelt sich.
Agentic Microformats vertritt die Gegenposition. Das Web hat bereits eine Oberfläche. Sie heißt HTML. Vier Milliarden Menschen benutzen sie. Das Problem ist nicht die Oberfläche, sondern dass sie nur mit einer Art von Bediener spricht.
`data-agent-*`-Attribute zu bestehenden Elementen hinzuzufügen ist ein minimaler Eingriff mit unverhältnismäßig großer Hebelwirkung. Für Menschen funktioniert die Seite genau wie vorher. Aber jetzt kann ein Agent dieselbe Seite lesen und verstehen, was sie bedeutet, was er tun kann und wobei er vorsichtig sein sollte.
Die Lehre aus der AgentShop-Demo ist nicht, dass Agenten online einkaufen können. Die Lücke zwischen „KI-Agent“ und „nützlicher KI-Assistent“ erfordert vielleicht gar kein neues Protokoll, kein Vision-Modell und keine eigens gebaute API. Vielleicht erfordert sie zwölf HTML-Attribute und die Bereitschaft, zu beschreiben, was die eigene Oberfläche ohnehin schon tut.
Die Spezifikation ist offen, die Demo läuft, und das Repository liegt auf github.com/ikangai/agentic-microformats.
Das Web bleibt eine Oberfläche für Menschen. Agenten werden zu Assistenten, die merken, was im Raum los ist, weil der Raum sich endlich selbst beschreibt.
Aus dem Englischen übersetzt: zum Originalbeitrag