IronBee baut einen Browser-Agenten, der das LLM überspringt und die Bestellung selbst prüft

Die Demo ist klein und konkret. Laut IronBees eigenem Blogbeitrag meldete sich Express an, legte ein Produkt in den Warenkorb, trug eine Adresse und eine Karte ein und wartete, bis auf der Bestellseite COMPLETED stand: neun Aktionen, 6,7 Sekunden.

Die Entscheidungsmaschine dahinter heißt Jev, ein Modell von TypeSafe, das typisierte Multiple-Choice-Fragen beantwortet. IronBee zufolge läuft dabei kein LLM mit. Jeder Schritt ist ein Aufruf an Jev, der die gewählte Option, eine Wahrscheinlichkeit für jede Option und einen Konfidenzwert zurückgibt. Es wird kein Text erzeugt und kein Screenshot gelesen. Eine Entscheidung dauert von der Türkei aus etwa 300 ms, wovon der größte Teil auf die Reise zum Server entfällt. Mit dem Kostenwert verkauft das Unternehmen sein Produkt. Die Eingabe kostet 0,042 US-Dollar pro Million Token, die Ausgabe ist gratis. Damit kam ein vollständig nachgespielter Checkout samt Bewertung und Review auf 0,00054 US-Dollar, so IronBee. Die Antwort kann nur ein Schlüssel aus der Liste sein, die der Testrahmen mitgeschickt hat. Modellausgaben werden also nie zu einem Selektor, einer Koordinate oder einem Skript. Ein Lauf kann nur anklicken, was ohnehin auf dem Bildschirm stand.

Das ist eine engere Wette als bei den screenshotgesteuerten Agenten, die anderswo auf den Markt kommen. Ob der Ansatz auch Seiten übersteht, die keine saubere nummerierte Liste von Bedienelementen anbieten, bleibt abzuwarten.

Der Fehlschlag, der das Design verkaufte

Geschwindigkeit lässt sich leicht filmen. Der nützlichere Lauf im Beitrag ist ein Checkout, der schiefging. Die Seite zeigte "Order placed successfully!", und die Bestell-API antwortete mit 200, doch die Nutzlast in dieser Antwort lautete FAILED. IronBees Agent markierte den Lauf nach 7,57 Sekunden, 8 Aktionen und 9 Entscheidungen als fehlgeschlagen. Er verwies auf die API-Antwort und dann auf die Logzeile im Backend: notification-service, Order #131 Could Not Be Processed, Reason: Insufficient inventory.

Die Seite sagte "Order placed successfully!". Die Bestell-API antwortete mit 200, aber die Bestellung darin lautete FAILED.

Für all das hat niemand eine Assertion geschrieben, heißt es in dem Beitrag. Der Bewertungsschritt ist selbst eine Jev-Frage: Hat das Ziel gehalten, und welche Belege stützen das. Alle Zahlen im Bericht stammen aus IronBees eigenen Läufen zwischen dem 21. September und dem 1. Oktober 2026. Die erste Version lief am 24. September. Sie meldete sich an und legte in 3 von 3 Versuchen ein Produkt in den Warenkorb, in 2,85 bis 3,05 Sekunden.

Diese Vorsicht ist angebracht, denn das meiste Material über Browser-Agenten, das diese Woche erschien, ist kein neutraler Benchmark. Eine Referenzimplementierung mit 400 Zeilen von xhluca zeigt die entgegengesetzte Architektur. Sie gibt Gemini 3.8 Flash Screenshots und Browser-Steuerung in 394 Zeilen Python, inklusive eines aufgezeichneten Laufs, der eine Werkstatt bucht und die Bestätigung prüft. Beide Ansätze behaupten, das Ergebnis zu prüfen. Nur einer davon zahlt pro Screenshot.

Verifikation ist das Thema der Woche

Dasselbe Argument taucht bei Coding-Werkzeugen auf. Dotpals, ein quelloffener Desktop-Begleiter für Claude Code, Codex und Cursor, liest Testergebnisse aus der Befehlsausgabe statt aus dem Wort des Agenten. Scheitern Tests, schickt es den Agenten zurück, und es erwischt auch einen Test, der nur bearbeitet wurde, damit er durchgeht. Ian Maurers Text nennt das OpenClaw-Team, das rund 400.000 Zeilen eigener Tests löschte, ohne dass die Abdeckung sich groß änderte. Er plädiert für Outside-in-Tests, die Nutzerverhalten beschreiben, statt für einen wachsenden Haufen Unit-Tests. Threadnote führte eine kleine gepaarte Studie auf fünf öffentlichen Repositories durch. Sie meldet 65,62% weniger Lifecycle-Token pro verifizierter Fertigstellung und 46,14% weniger Zeit mit einem gespeicherten Handoff, wobei die Verifikation bei 5 von 5 Aufgaben bestand, gegenüber 4 von 5 bei Dateien allein. Das Unternehmen sagt ausdrücklich, dass dies seine eigene Studie mit einem einzigen Modell auf Build 5.1.0-beta.2 ist und keine unabhängige Evaluierung.

Sein Satz zum Problem ist deutlich: "Done" ist ein Satz, den ein Agent erzeugen kann, und kein Testergebnis.

Auch die Dauerhaftigkeit bekommt Aufmerksamkeit. Pi Durable, ein experimentelles Framework von Arendelle, zusammen mit Pi 1.0 veröffentlicht, speichert Gespräche als Checkpoints, damit ein neuer Prozess sie fortsetzen kann. Einen unterbrochenen Tool-Aufruf wiederholt es nur, wenn das Tool sich als replay-sicher erklärt, denn eine Zahlung zweimal zu senden ist nicht dasselbe wie eine Suche erneut auszuführen. Ostoyae, ein Graph-Runner für Coding-Agenten, führt jeden Job in einem eigenen Git-Worktree aus. Arbeit zählt erst, wenn ein Prüfbefehl auf einem frischen Checkout durchläuft.

Warum Unternehmen stecken bleiben

Die Lücke zwischen Demos und Produktivbetrieb ist messbar. Eine Umfrage von MIT Technology Review Insights unter 300 Daten- und Technologieverantwortlichen ergab, dass im Schnitt nur etwa 34% der Agentic-AI-Projekte der Unternehmen die Produktion erreichen. Die Umfrage entstand in der Custom-Content-Abteilung, nicht in der Redaktion. Datenfragmentierung war mit 55% das am häufigsten genannte Hindernis beim Ausbau des Wissenszugangs für Agenten.

Auf der Forschungsseite stellt ein am 1. Oktober überarbeitetes Paper StructMemEval vor, einen Benchmark dafür, ob Agenten langfristiges Gedächtnis organisieren und nicht nur Fakten abrufen. Die Autoren berichten, dass retrieval-augmentierte LLMs mit Aufgaben wie Transaktionsbüchern und To-do-Listen schwer zurechtkommen. Sie ergänzen, dass moderne Modelle die nötige Struktur nicht immer erkennen, wenn man sie nicht dazu auffordert.

Nichts davon macht einen Checkout in 6,7 Sekunden zum schwierigen Teil. IronBees eigener Beitrag verbringt den größten Teil seiner Länge mit Dingen, die kaputtgingen. Seine zentrale Behauptung ist eng: aus einer Liste wählen, die Wahl prüfen und den Lauf anhand von Belegen bewerten statt anhand des Erfolgsbanners der Seite. Das ist ein kleineres Versprechen als ein Agent, der das Web liest, und ein besser prüfbares.