Ein KI-Agent, der deinen Computer bedienen soll, schaut heute oft auf Screenshots. Das klingt menschlich, ist aber technisch ziemlich dumm. Servus, ich bin Lissy. Heute geht es nicht um das nächste größere Modell und auch nicht um den nächsten Agenten mit noch mehr Buttons. Heute geht es um eine viel grundlegendere Frage: Worauf soll ein Agent eigentlich schauen, wenn er Arbeit erledigt? Auf Pixel, wie ein Mensch vor dem Bildschirm? Oder auf den Zustand des Programms, also Dateien, DOM, Datenbanken, Backends und Zwischenergebnisse? Ein neues Paper namens StateAct sagt ziemlich klar: Pixel sind die Oberfläche. Die eigentliche Arbeit liegt darunter. Und wenn das stimmt, dann bauen viele Computer-Use-Agenten gerade an der falschen Stelle ihre Muskeln auf.
Fangen wir mit dem Kern an. StateAct ist ein Gegenentwurf zu reinen Screenshot-Agenten. Die meisten Computer-Use-Demos wirken so: Das Modell bekommt ein Bild vom Bildschirm, erkennt Knöpfe, Menüs und Text, klickt irgendwo hin und schaut danach wieder auf den nächsten Screenshot. Das ist intuitiv, weil wir Menschen Computer so erleben. Aber ein Programm ist nicht seine Pixel. Ein Dokument ist nicht nur die gerenderte Seite. Eine Webseite ist nicht nur das Bild im Browser. Darunter liegen Dateien, DOM-Strukturen, Formularzustände, Logs, API-Antworten und gespeicherte Werte. Genau dort setzt StateAct an. Der Hauptagent soll primär mit Program State arbeiten. Also direkt lesen, was im System wirklich passiert, statt aus einem Screenshot zu raten. Nur wenn eine Aufgabe wirklich GUI-Interaktion braucht, kommt ein kleiner GUI-Subagent dazu. Das ist eine wichtige Verschiebung. Der Agent tut nicht mehr so, als wäre er ein Mensch mit Maus und Augen. Er arbeitet eher wie ein Entwickler mit Debugger, Dateisystem und Browser-Inspektor. Für mich ist das der stärkste Take des Tages: Wenn wir Maschinen bauen, die Maschinen bedienen, müssen sie nicht den menschlichsten Weg nehmen. Sie sollten den verlässlichsten Weg nehmen. Und der liegt oft eine Schicht tiefer als das, was auf dem Bildschirm hübsch aussieht.
Die Zahlen machen den Punkt greifbar. Auf OSWorld 2.0 steigt Claude Opus 4.8 laut Research mit StateAct von 20,6 Prozent auf 26,9 Prozent binäre Erfolgsrate. Partial Success steigt von 54,8 auf 61,6 Prozent. Das ist kein Durchbruch im Sinne von: Computer Use ist gelöst. 26,9 Prozent heißt immer noch, dass die meisten Aufgaben nicht komplett sauber erledigt werden. Aber die Richtung ist wichtig, weil die Verbesserung nicht aus einem größeren Screenshot-Modell kommt, sondern aus der besseren Schnittstelle zur Aufgabe. Noch interessanter: Der Ansatz soll pro Task ungefähr neunmal günstiger sein als ein reiner Screenshot-Agent. Und der GUI-Subagent wird nur selten gebraucht: 28 von 108 OSWorld-2.0-Aufgaben und 1,1 Prozent der Hauptagent-Schritte. Das heißt nicht, dass GUI-Wahrnehmung unwichtig wird. Ein code-only Agent ohne GUI-Subagent kommt laut Research nur auf 45,9 Prozent Partial Success und liegt damit unter der Screenshot-Baseline. Die ehrliche Einordnung ist also: StateAct ersetzt Pixel nicht vollständig. Aber es degradiert Pixel von der Hauptschnittstelle zur Spezialhilfe. Mei, das klingt nüchtern. Aber genau solche nüchternen Architekturentscheidungen entscheiden am Ende, ob Agenten bezahlbar und überprüfbar werden.
Für Produkte ist dieser Unterschied riesig. Eine Demo kann mit Screenshots leben. Ein echter Workflow nicht. Wenn ein Agent eine Rechnung in einem Webtool ausfüllt, reicht es nicht, dass er ungefähr erkennt, wo das Feld ist. Er muss wissen, welcher Wert gespeichert wurde, ob das Backend die Änderung akzeptiert hat, ob die Datei am richtigen Ort liegt und ob der Abschlusszustand wirklich stimmt. StateAct baut deshalb auch ein unabhängiges Finish-Gate ein. Also eine Prüfung, die nicht einfach glaubt, dass der Agent fertig ist, nur weil er sagt: erledigt. Diese Idee gefällt mir sehr, weil sie erwachsener ist als der übliche Agenten-Hype. Gute Automatisierung besteht nicht nur aus Aktionen. Sie besteht aus Wahrnehmung, Handlung und Verifikation. In der Biologie würdest du auch nicht nur beobachten, dass eine Zelle irgendwie reagiert, und dann schon die ganze Kaskade behaupten. Du brauchst Marker, Kontrollen und einen sauberen Endzustand. Bei Agenten ist es ähnlich. Der Endzustand zählt. Für Gründer heißt das: Wer Agenten-Produkte baut, sollte nicht zuerst fragen, wie gut das Modell Buttons erkennt. Die bessere Frage ist: Welche Zustände kann mein System direkt lesen? Welche Aktionen sind strukturiert? Und wie prüfe ich unabhängig, ob das Ergebnis stimmt? Genau dort entsteht der echte Vorteil.
Dazu passt eine Big-Tech-Meldung von Anthropic. Cognizant und Anthropic erweitern ihre Partnerschaft, um Claude breiter in Enterprise-Projekten einzusetzen. Das ist keine Meldung, bei der Endnutzer morgen ein neues magisches Feature sehen. Aber sie zeigt, wo der Markt hinläuft. KI landet nicht nur als Chatfenster neben der Arbeit. Sie wird in bestehende Unternehmenssysteme eingebaut, über Integratoren, Prozessberater, Datenzugänge und Sicherheitsfreigaben. Das ist weniger sexy als ein Frontier-Modell-Launch, aber wahrscheinlich viel näher an der Realität in großen Firmen. Und genau da wird StateAct plötzlich praktisch. Ein Enterprise-Agent darf nicht nur visuell durch SAP, Jira oder interne Dashboards stolpern. Er braucht strukturierte Zugänge, Rechte, Logs und Prüfungen. Sonst entsteht nur ein sehr überzeugender Praktikant mit verbundenen Augen und Admin-Rechten. Das ist keine gute Kombination. Für kleinere Anbieter liegt darin aber auch eine Chance. Big Tech liefert Modelle und Integrationspartnerschaften. Kleine Teams können die Betriebsschicht bauen: State-Zugriff, Audit, Finish-Gates, Kostenmessung, Approval-Flows. Also all das, was aus einem beeindruckenden Agenten einen verantwortbaren Mitarbeiter macht.
Im Grassroots-Research tauchen heute ein paar kleine Tools auf, die genau in diese Richtung zeigen. Approving ist ein neues Open-Source-Projekt mit laut Research 73 Sternen seit dem 24. Juli. Die Selbstbeschreibung ist schön konkret: coding agents sollen in visuelle, reviewbare und wiederherstellbare Delivery-Workflows verwandelt werden. Agents laufen in Docker-Sandboxes, tauschen strukturierte Artefakte aus und pausieren an kritischen Stellen für menschliches Approve. Das ist keine große Modellforschung. Aber es ist die Art Infrastruktur, die man braucht, wenn Agenten wirklich liefern sollen. OpenClaude Improved und Deer Workflow zeigen dieselbe Bewegung von unten: Leute bauen offene Agenten- und Orchestrierungsoberflächen, weil sie nicht nur in geschlossenen Chatprodukten arbeiten wollen. Ich würde diese Repos heute nicht überhöhen. Sterne sind kein Qualitätsbeweis, und neue Projekte können in drei Wochen wieder einschlafen. Aber als Signal sind sie spannend. Der Markt merkt: Agenten brauchen nicht nur Intelligenz. Sie brauchen Zustände, Sandboxes, Reviewpunkte und Wiederherstellung. Oder kurz gesagt: weniger Magie, mehr Werkstatt. Und ehrlich, als jemand, der lieber echte Werkzeuge als hübsche Versprechen mag, finde ich das ziemlich gesund.
Mein Take für heute ist deshalb ziemlich klar: Der nächste Agentenfortschritt kommt nicht nur aus besseren Modellen. Er kommt aus besseren Schnittstellen zur Wirklichkeit. StateAct zeigt das technisch: weniger Pixelraten, mehr Program State. Anthropic und Cognizant zeigen es im Enterprise-Markt: KI muss in echte Systeme rein, nicht daneben sitzen. Und die kleinen Open-Source-Tools zeigen, dass rundherum eine Kontrollschicht entsteht. Für mich ist das eine gute Richtung. Mächtige Agenten ohne Verifikation sind Spielzeug mit Risiko. Mächtige Agenten mit Zustandszugriff, Grenzen und Finish-Gates können echte Arbeit übernehmen. Wenn ihr selbst mit Agenten arbeitet, schaut heute mal auf eine konkrete Frage: Prüft euer System wirklich den Endzustand, oder glaubt es nur dem Modell? Schreibt mir gern eure Erfahrung, die Adresse steht in den Shownotes. Und wenn euch die Folge hilft, hinterlasst eine Bewertung auf Spotify oder Apple Podcasts. Das war die Daily AI News für heute. Danke fürs Zuhören. Pfiat euch, bis morgen, eure Lissy.