Experiment 001 · geschlossen

Der Browser-Agent scheiterte nicht an fehlender KI-Schnittstelle. Er scheiterte an schlechtem HTML.

Vier Kontaktformulare, derselbe Auftrag, drei gültige Black-Box-Läufe. Unser erstes Experiment zum Agent-Ready Web endete an einer Stelle, die erstaunlich wenig nach Zukunft klingt.

Die Frage klang zunächst nach 2026: Braucht eine Website eine neue Schnittstelle, damit ein Browser-Agent sie zuverlässig bedienen kann? WebMCP verspricht strukturierte Werkzeuge für Agenten im Browser. Also wollten wir wissen, wie viel davon bei einer ganz gewöhnlichen Aufgabe überhaupt nötig ist.

Wir begannen nicht mit Checkout, Reisebuchung oder einem CRM. Wir begannen mit der vermutlich langweiligsten Interaktion des Webs: einem Kontaktformular.

Vielleicht beginnt das Agent-Ready Web nicht mit einem neuen Protokoll. Vielleicht beginnt es mit einem <label>.

Die Frage

Experiment 001 hatte genau eine Ausgangsfrage:

Das ist bewusst kleiner als die große Frage nach dem Agent-Web. Denn bevor wir neue Protokolle, Agent Cards, Tool-Registrierung oder Commerce-Schichten vergleichen, wollten wir erst wissen, was die vorhandene Web-Plattform bereits leistet.

Der Versuch

Wir bauten vier Kontaktseiten. Für einen Menschen sahen sie im Kern nach derselben Aufgabe aus. Technisch unterschieden sie sich deutlich.

Für jeden Lauf wurden die Varianten zufällig hinter neutralen URLs wie /trial/1 bis /trial/4 versteckt. Der Agent kannte die Zuordnung nicht. Er bekam jedes Mal denselben Auftrag: E-Mail und Nachricht eintragen und tatsächlich absenden.

Der Agent war Codex. Als Browserwerkzeug nutzte er Playwright MCP. Repository, Quellcode, Terminal und direkte Netzwerkaufrufe waren für die Lösung ausgeschlossen. Entscheiden durfte das Modell nur anhand dessen, was die Browser- und Accessibility-Struktur der Seite ihm anbot.

Der Server protokollierte unabhängig davon, welche Trial-Seite besucht wurde, ob ein POST stattfand, welchen Status er hatte und ob exakt die erwarteten Daten angekommen waren. Das Sprachmodell durfte also handeln. Die Bewertung durfte es nicht selbst erfinden.

Die fünf Läufe, die nicht zählen

Bis überhaupt ein echter Versuch zustande kam, produzierten wir fünf Läufe, die wir ausgeschlossen haben. Mal fehlte die Authentifizierung, mal war das Browserwerkzeug nicht freigegeben, mal suchte Playwright den falschen Browser.

Das ist keine Fußnote, die man verstecken sollte. Es ist der Unterschied zwischen einer Demo und einem Experiment: Wenn der Agent keine Testseite gesehen hat, ist das kein fehlgeschlagener Test der Website. Es ist ein fehlgeschlagenes Labor.

Ein Lauf zählte deshalb nur, wenn alle vier zufällig zugeordneten Varianten tatsächlich im Browser besucht worden waren. Von acht aufgezeichneten Agentenläufen erfüllten drei dieses Kriterium. Genau diese drei bilden das Ergebnis.

Das Ergebnis

Das Muster war in allen drei gültigen Läufen gleich. Die drei Varianten mit einer normalen semantischen Formularoberfläche wurden erfolgreich bedient. Die Variante ohne native Formularsemantik scheiterte jedes Mal.

Im ersten gültigen Lauf sah man den Unterschied sehr direkt: Auf den semantischen Seiten fand der Agent E-Mail-Feld, Nachrichtenfeld und Submit. Auf der bad-Variante versuchte er mehrfach, normale Formularfelder über die Browser- und Accessibility-Struktur zu erreichen. Er fand keinen eindeutigen Weg und brach ab, statt die Aufgabe mit JavaScript oder direkten Requests zu erzwingen.

Wir benutzen 2026 also eine bemerkenswerte Menge Rechenleistung, um wieder zu entdecken, warum ein Formularfeld ein Formularfeld sein sollte.

Was daran interessant ist

1. Semantik war in diesem Versuch nicht Dekoration

Semantisches HTML war hier kein SEO-Aufkleber und keine besonders tugendhafte Art, Markup zu schreiben. Es veränderte, was der Agent zuverlässig erkennen und bedienen konnte.

Das passt zu einer sehr alten Eigenschaft des Webs: Native Elemente tragen Bedeutung und Verhalten bereits mit sich. Labels benennen Felder. Input-Typen beschreiben Daten. Buttons sind Buttons. Browser und Accessibility-APIs können diese Struktur weiterreichen, ohne dass jede neue Maschine die Seite von Grund auf erraten muss.

2. WebMCP gewann nicht gegen gutes HTML

Die WebMCP-Variante war ebenfalls in 3/3 Läufen erfolgreich. Aber sie war in diesem Versuch nicht erfolgreicher als das normale semantische Formular.

Das ist kein Argument gegen WebMCP. Unser Agent benutzte Playwright MCP als Browser- und Accessibility-Werkzeug; er entdeckte die deklarativen WebMCP-Metadaten nicht als natives Tool-Protokoll. Der Versuch beantwortet deshalb nicht die Frage, ob WebMCP bei komplexeren Abläufen, expliziten Aktionen oder nativer Tool-Discovery Vorteile bringt.

Er beantwortet nur die kleinere Frage. Und die lautet bisher: Für dieses einfache Kontaktformular reichte gutes HTML.

3. Die API-Variante testete keine API-Discovery

Auch die API-Variante funktionierte in 3/3 Läufen. Aber der Agent entdeckte keinen Endpunkt und entschied sich nicht für einen eleganten Maschinenweg. Er bediente vorne weiterhin das semantische Formular. Erst dessen JavaScript schickte die Daten als JSON.

Das ist wichtig, weil sonst aus einem Transportdetail sehr schnell die Behauptung würde, Agenten bevorzugten APIs. Das haben wir nicht getestet.

Was wir nicht bewiesen haben

Damit bleibt vom großen Zukunftssatz erstaunlich wenig übrig. Und das ist gut. Ein Experiment sollte die Welt nicht größer machen als seine Daten.

Mein Fazit

Ich bin in das Experiment mit einer Frage nach einer neuen Agentenschnittstelle gegangen und bei einer alten Web-Grundlage gelandet.

Für Menschen bauen wir seit Jahren semantische Formulare, weil Browser, Tastatursteuerung, Screenreader, Validierung und Wartbarkeit davon profitieren. In diesem kleinen Versuch profitierte auch der Browser-Agent davon.

Human-first und agent-ready könnten bei den Grundlagen weniger Gegensätze sein, als es die neue Protokollwelt vermuten lässt.

WebMCP bleibt interessant. Vielleicht wird es genau dort wichtig, wo die normale Oberfläche mehrdeutig, zustandsreich oder transaktional wird. Aber bevor wir der Website eine weitere Schicht geben, lohnt sich eine unangenehm einfache Frage:

Ist die vorhandene Schicht eigentlich schon gut?

Damit ist Experiment 001 abgeschlossen. Die nächste sinnvolle Frage ist nicht automatisch „mehr WebMCP“, sondern: Ab welchem Punkt reicht semantisches HTML für einen Agenten nicht mehr aus?