Was Computer-Use-Agents technisch anders machen

Klassische Agenten sprechen mit Software über definierte Schnittstellen — APIs, Tool-Use, Function Calling. Die Anwendung weiß nicht, wer sie aufruft, sie verarbeitet ein klar typisiertes Datenpaket und antwortet ebenfalls strukturiert.

Computer-Use-Agents arbeiten anders. Sie sehen den Bildschirm — ein Screenshot, ein Browser-Inhalt, ein Anwendungsfenster — und entscheiden, wo sie als Nächstes klicken, was sie tippen, welches Menü sie öffnen. Die Anwendung dahinter merkt davon nichts. Sie wird bedient wie von einem Menschen, nur in Maschinen-Geschwindigkeit und mit Maschinen-Wahrnehmung.

Diese Architektur eröffnet eine Möglichkeit, die mit klassischem Tool-Use oder dem Model Context Protocol nicht erreichbar ist: die Bedienung von Software, für die es schlicht keine saubere Schnittstelle gibt. Das ist gleichzeitig der Grund, warum sich diese Klasse lohnt — und der Grund, warum sie mit Vorsicht eingesetzt werden muss.

Wo sich Computer-Use-Agents im Unternehmen wirklich rechnen

Drei Konstellationen tauchen in unseren Projekten besonders verlässlich auf, in denen die Bedienung über den Bildschirm gegenüber jeder API-Anbindung überlegen ist.

Die erste Konstellation sind Legacy-Systeme ohne API. Eine klassische Branchensoftware, ein altes ERP-Modul, ein Mainframe-Frontend, ein Spezial-Tool des Herstellers ohne offene Schnittstelle. Solche Systeme lassen sich häufig nicht modernisieren, ohne ein Großprojekt anzustoßen — aber sie lassen sich mit einem Computer-Use-Agent automatisiert bedienen. Das ist nicht elegant, kann aber wirtschaftlich genau richtig sein.

Die zweite Konstellation sind browserbasierte Workflows ohne Integration. SaaS-Tools, Lieferantenportale, Rechercheaufgaben in mehreren externen Quellen, Dateneingabe in fremden Anwendungen. Diese Aufgaben kosten in vielen Teams täglich Zeit, ohne dass eine API-Lösung in absehbarer Zeit verfügbar wäre. Ein Browser-Agent, der diese Vorgänge übernimmt, schließt eine reale Lücke.

Die dritte Konstellation ist die Brücke zwischen mehreren nicht verbundenen Anwendungen. Ein Vorgang, der typischerweise mit Copy-and-Paste zwischen drei Systemen abgewickelt wird, lässt sich von einem Computer-Use-Agent ohne Integration der Systeme bedienen. Das spart die Integration und ist insbesondere dann attraktiv, wenn die Integration teurer wäre als der Vorgang insgesamt rechtfertigt.

Wo Computer-Use-Agents nicht hingehören

Genauso wichtig wie die Frage nach guten Use Cases ist die Frage nach den Bereichen, in denen ein Computer-Use-Agent die teurere und schlechtere Wahl ist.

Alles, wofür eine ordentliche API existiert. Wenn ein System eine saubere Schnittstelle anbietet, ist die API-Anbindung in fast jedem Fall robuster, schneller, günstiger und besser testbar. Computer-Use-Agents über vorhandenen APIs zu bauen ist eine Form von Bequemlichkeit, die im Betrieb regelmäßig zurückschlägt.

Hochfrequente, sehr eng definierte Aufgaben. Sobald derselbe Vorgang tausende Male am Tag passiert, lohnt sich fast immer die Investition in eine saubere Anbindung — sei es per API, per RPA-Werkzeug oder per direkter Datenbankoperation. Der Computer-Use-Agent ist hier zu langsam und zu fehleranfällig.

Vorgänge mit hohem Schaden bei Fehlbedienung. Ein Klick zu viel im ERP, eine versehentlich angelegte Bestellung, eine falsch gespeicherte Datei in einem Vertragsverwaltungssystem. Computer-Use-Agents sind in dieser Klasse von Aufgaben kein leichtes Werkzeug — sie verlangen denselben Reifegrad wie jede andere schreibende Automatisierung, nur mit weniger eingebauten Schutznetzen.

Anwendungen mit aktiver Bot-Erkennung. Manche externe Plattformen wehren sich gegen automatisierte Bedienung, sei es vertraglich oder technisch. Das ist nicht nur ein Risiko der Sperrung, sondern auch eine Frage der Zulässigkeit. Bevor ein Browser-Agent auf einer fremden Plattform arbeitet, gehört diese Frage geklärt — wir gehen darauf hier rein architektonisch ein, eine seriöse rechtliche Prüfung im Einzelfall ersetzt das nicht.

Was im Betrieb wirklich anders ist

Computer-Use-Agents bringen Eigenschaften mit, die in API-basierten Setups unbekannt sind. Drei davon sind im täglichen Betrieb besonders sichtbar.

Erstens: Latenz. Jede Aktion folgt einem Zyklus aus Bildschirm wahrnehmen, Aktion entscheiden, Klick ausführen, neuen Bildschirm wahrnehmen. Im besten Fall sind das wenige Sekunden pro Schritt; in komplexen Vorgängen mit vielen Klicks summiert sich das schnell zu mehreren Minuten. Wer eine API-Echtzeitabwicklung gewohnt ist, erlebt einen Computer-Use-Agent als spürbar langsam.

Zweitens: Fehleranfälligkeit gegenüber UI-Änderungen. Eine verschobene Schaltfläche, ein neuer Modal-Dialog, eine geänderte Beschriftung kann den Agent stoppen oder in den falschen Zweig leiten. Anwendungen entwickeln sich weiter, Designs werden überarbeitet, A/B-Tests verändern Layouts. Was per API stabil bleibt, kippt per Bildschirm-Bedienung mit jedem UI-Update.

Drittens: Kosten. Computer-Use-Agents nutzen meist große multimodale Modelle, die Bildschirminhalte verarbeiten — und das pro Schritt. Was ein klassischer API-Aufruf in Cent-Beträgen erledigt, kostet beim Computer-Use-Agent häufig ein Vielfaches, weil pro Schritt ein Bild verarbeitet wird. Diese Kostendimension ist in den allgemeinen Beobachtungen aus LLM-Kostenoptimierung besonders ausgeprägt und sollte vor dem Roll-out durchgerechnet sein.

Sicherheit, Berechtigungen und Sandbox-Strategien

Ein Agent, der Software wie ein Mensch bedient, bekommt typischerweise auch Berechtigungen wie ein Mensch. Diese Eigenschaft macht Computer-Use-Setups in Sicherheitsfragen besonders anspruchsvoll.

Drei Punkte gehören in jede ernsthafte Einführung. Erstens: eigene Identität. Der Agent arbeitet nicht unter dem Account einer realen Person, sondern unter einem dedizierten Account mit ausdrücklich zugewiesenen Berechtigungen. Das ist Voraussetzung für Audit-Trails und für eine saubere Trennung zwischen menschlicher und automatisierter Aktion.

Zweitens: klar abgegrenzte Umgebung. Der Agent läuft idealerweise in einer dedizierten virtuellen Umgebung oder einem isolierten Browserprofil. Was er sieht und worauf er klicken kann, ist auf das beschränkt, was er für seinen Vorgang wirklich braucht. Allgemeiner Browser-Zugriff oder eine offene Desktop-Sitzung sind im Unternehmenseinsatz selten der richtige Rahmen.

Drittens: kritische Aktionen mit Bestätigung. Schreibende Operationen, irreversible Schritte, sensible Datenfreigaben — solche Aktionen sollten nicht ohne menschliche Freigabe stattfinden. Ein Agent, der ungeprüft alles auslösen darf, was der Bildschirm hergibt, ist im Unternehmen kein Effizienzwerkzeug, sondern ein Risiko. Der gleiche Grundsatz gilt im Übrigen auch für andere Automatisierungen — wie wir im Beitrag zu KI-Agent oder fester Workflow ausgeführt haben, ist die Mischung aus Workflow-Steuerung und punktuell freier Entscheidung in produktiven Szenarien fast immer überlegen.

Tests, Beobachtbarkeit und der Audit-Trail

Computer-Use-Agents bringen einen unerwarteten Vorteil mit: Ihr Verhalten ist buchstäblich sichtbar. Bildschirm-Aufnahmen, Klick-Logs und Aktions-Protokolle zeigen genau, was der Agent getan hat — oft besser nachvollziehbar als bei manchen klassischen Tool-Use-Setups.

Diese Sichtbarkeit ist ein zweischneidiges Schwert. Sie eröffnet die Möglichkeit eines vollständigen Audit-Trails — Bildschirm-Mitschnitt pro Vorgang, abrufbar für spätere Prüfungen. Sie verlangt aber auch, dass dieses Material sauber aufbewahrt, geschützt und ausgewertet wird. Ein Mitschnitt-Archiv ohne klare Regeln ist eher Risiko als Schutz.

Tests folgen ähnlichen Prinzipien wie bei anderen Agenten: definierte Szenarien mit erwartetem Ergebnis, Stichproben aus dem Produktivbetrieb, Regressionsprüfung nach UI-Änderungen der Zielanwendung. Die Disziplinen aus dem Bereich LLM-Qualitätssicherung gelten unverändert — mit dem Zusatz, dass UI-Brüche eine eigene Klasse von Regressionsfällen sind.

Computer-Use, RPA und API-Anbindung — was wann passt

Computer-Use-Agents sind nicht das einzige Werkzeug für die Bedienung von Software ohne Integration. Klassische RPA-Lösungen (Robotic Process Automation) gibt es seit Jahren und verlangen vergleichbare Architekturentscheidungen. Eine bewusste Einordnung lohnt sich.

API-Anbindung ist die robusteste Wahl, wenn sie verfügbar ist. Schnell, günstig, gut testbar, stabil gegen UI-Änderungen.

Klassische RPA-Werkzeuge sind die richtige Wahl, wenn ein Vorgang sehr stabil ist, oft wiederholt wird und sich klar in feste Schritte zerlegen lässt. RPA ist günstiger im laufenden Betrieb als ein Computer-Use-Agent, aber unflexibler bei Variationen.

Computer-Use-Agents sind die richtige Wahl, wenn die zu bedienende Anwendung keine API hat, der Vorgang variabler ist, als RPA es leicht abbildet, und Volumen sowie Latenz die zusätzlichen Kosten rechtfertigen. Häufig ist die ehrlichste Lösung eine Kombination: ein Workflow steuert die Hauptstrecke, RPA erledigt die wiederholbaren Standardklicks, ein Computer-Use-Agent springt nur dort ein, wo Variabilität echtes Verstehen verlangt.

Typische Fehler in den ersten Computer-Use-Projekten

Der häufigste Fehler ist, einen Computer-Use-Agent zu wählen, weil das Werkzeug beeindruckend wirkt, obwohl eine API verfügbar wäre. Die saubere Anbindung ist in diesen Fällen jedes Mal überlegen — und wer den Agent vorzieht, sammelt Folgekosten in Latenz, Brüchen und Verbrauch.

Der zweite Fehler ist, den Agent ohne dedizierte Identität laufen zu lassen. „Wir nutzen den Account von Person X, ist ja egal" ist ein Audit-Albtraum und macht es im Vorfall unmöglich, sauber zu rekonstruieren, was menschlich und was automatisiert passiert ist. Eigene Identität ist Pflicht, nicht Komfort.

Der dritte Fehler ist, kritische Aktionen ohne menschliche Bestätigung freizugeben. Ein Agent, der eine Lieferantenbestellung absendet, einen Vertrag freigibt oder eine Auszahlung auslöst, ohne dass irgendwo ein Mensch noch einmal nickt, ist im Unternehmen sehr selten die richtige Wahl.

Der vierte Fehler ist, die UI-Brüchigkeit zu unterschätzen. Wer einen Computer-Use-Agent für einen produktiven Vorgang einsetzt, muss damit rechnen, dass die Zielanwendung sich ändert — und sollte einen Plan haben, wie das schnell erkannt und korrigiert wird. Ohne Monitoring auf Vorgangserfolg lebt ein Computer-Use-Agent in einem Dauerzustand zwischen „läuft" und „stoppt leise".

Der fünfte Fehler ist, Computer-Use als Universallösung zu denken. Diese Werkzeuge sind exzellent für eine bestimmte Klasse von Problemen — und schlecht für viele andere. Ein bewusster Use-Case-Zuschnitt ist hier wichtiger als bei flexibleren Werkzeugen, weil die Fehlbenutzung schneller teuer wird.

Wann externe Unterstützung sinnvoll ist

Ein erster Computer-Use-Pilot für eine eng geschnittene interne Aufgabe ist heute in wenigen Tagen aufgesetzt. Eine produktive Computer-Use-Architektur, die in sensiblen Vorgängen läuft, mehrere Anwendungen bedient und Audit-Anforderungen erfüllt, ist eine andere Größenordnung — sowohl in Architektur als auch in Betrieb. Spätestens dort lohnt sich ein Blick von außen, bevor sich Muster verfestigen, die später schwer zu drehen sind.

Wir arbeiten mit Unternehmen, die Computer-Use-Agents nicht aus Mode-Gründen einsetzen wollen, sondern weil ein konkreter Vorgang ohne saubere API-Anbindung entlastet werden soll. Wenn das zu Ihrer Situation passt, sprechen Sie uns an — am besten zu Beginn, wenn Use Case, Sandbox-Modell und Audit-Anforderungen noch gestaltbar sind. Den passenden Rahmen dafür bieten wir über KI-Agenten und Automatisierung sowie unsere Arbeit an AI Engineering.