Kurzfassung: KI-Agenten werden für Automatisierung interessanter, weil sie nicht mehr nur Text erzeugen oder APIs aufrufen. Computer-Use-Ansätze und Browser-Agenten können sichtbare Oberflächen bedienen: klicken, lesen, Formulare ausfüllen, Webseiten prüfen und Arbeitsabläufe nachvollziehbar ausführen. Genau darin liegt der Nutzen – und das Risiko.
Was ist passiert / was ist neu?
OpenAI beschreibt im Computer Use Guide ein Werkzeug, mit dem Modelle über Screenshots und Aktionen mit grafischen Oberflächen arbeiten können. Anthropic dokumentiert ebenfalls ein Computer-Use-Tool für Agenten, die Bildschirmzustände interpretieren und Bedienhandlungen ausführen.
Parallel dazu wächst ein Open-Source-Ökosystem rund um browserbasierte Agenten. Das Projekt browser-use verbindet Sprachmodelle mit Browser-Steuerung. Microsofts Playwright MCP Server bringt Browser-Automatisierung in MCP-fähige Agenten-Setups. Der gemeinsame Nenner: Agenten bekommen einen kontrollierbaren Weg, nicht nur Datenquellen, sondern Arbeitsoberflächen zu nutzen.
Technisch passt das zur MCP-Richtung. Die MCP-Spezifikation zu Tools beschreibt Werkzeuge als klar definierte Fähigkeiten, die ein Modell nicht beliebig, sondern über eine Host-Anwendung angeboten bekommt. Für Browser- und Computer-Use ist diese Trennung wichtig: Das Modell entscheidet nicht allein über die Welt, sondern arbeitet in einem begrenzten Werkzeugrahmen.
Warum relevant?
Viele reale Prozesse haben keine saubere API. Ein Lieferantenportal, ein Behördenformular, ein internes Admin-Panel oder ein altes CRM lässt sich nicht immer elegant per Schnittstelle automatisieren. Klassische RPA konnte solche Oberflächen schon lange bedienen, war aber oft starr und fehleranfällig. KI-Agenten ergänzen hier eine neue Schicht: Sie können Bildschirminhalte semantisch einordnen, Zwischenschritte planen und mit unvollkommenen Oberflächen umgehen.
Für Agentenkompass ist deshalb nicht die Demo spannend, in der ein Agent irgendwo klickt. Spannend ist die Frage, ob daraus ein verlässlicher Arbeitsablauf wird: mit klarer Aufgabe, begrenzten Rechten, Protokoll, Testumgebung und menschlicher Freigabe an den kritischen Stellen.
Praxis-Einordnung
Browser-Agenten eignen sich vor allem dort, wo ein Mensch heute wiederholt dieselben Web-Oberflächen nutzt: Recherche, QA von Webseiten, Formularvorbereitung, Datenabgleich, interne Prüfpfade oder Monitoring von Portalen. Der Agent muss dafür nicht „vollautonom“ sein. Oft reicht ein Assistenzmodus: vorbereiten, prüfen, dokumentieren – und erst nach Freigabe absenden oder ändern.
Ein brauchbarer Aufbau trennt mindestens vier Ebenen:
- Auftrag: Was soll der Agent genau erledigen – und was ausdrücklich nicht?
- Werkzeugrahmen: Welcher Browser, welche Domains, welche Aktionen und welche Zugangsdaten sind erlaubt?
- Kontrolle: Welche Schritte werden geloggt, gescreenshotet oder vor Ausführung bestätigt?
- Abbruch: Wann stoppt der Agent, statt weiter zu improvisieren?
Gerade für kleine Teams ist das ein realistischer Einstieg: nicht gleich komplette Prozessketten ersetzen, sondern erst einzelne, sichtbare Routineaufgaben in einem begrenzten Browser-Kontext testen.
Risiken und Grenzen
Computer Use ist kein Freifahrtschein. Oberflächen ändern sich, Captchas blockieren Abläufe, Fehlklicks können Daten verändern, Session-Cookies enthalten sensible Informationen und ein Agent kann eine Webseite falsch interpretieren. Dazu kommen Kosten und Latenz: Screenshot-basierte Steuerung ist oft langsamer und teurer als eine direkte API.
Besonders kritisch sind produktive Systeme mit Zahlungs-, Lösch-, Versand- oder Freigabefunktionen. Dort sollte ein Agent nicht eigenständig handeln. Sinnvoller sind Leserechte, Staging-Umgebungen, Domain-Whitelists, zeitlich begrenzte Zugangsdaten und verpflichtende Human-in-the-Loop-Schritte vor irreversiblen Aktionen.
Fazit
Browser-Agenten und Computer Use schließen eine praktische Lücke zwischen Chatbot und klassischer Automatisierung. Sie werden dort wertvoll, wo APIs fehlen oder Oberflächen Teil des Prozesses bleiben. Produktiv wird das aber erst, wenn Agenten nicht nur klicken können, sondern sauber begrenzt, beobachtet und freigegeben werden. Die richtige Frage lautet deshalb nicht: „Kann der Agent die Webseite bedienen?“ Sondern: „Darf er das in diesem Prozess – und wie merken wir, wenn er falsch liegt?“