Anthropic hat Claude Cowork einen eigenen Browser eingebaut, der innerhalb der Desktop-Anwendung läuft. Braucht eine Aufgabe eine Webseite, öffnet sich in einem Seitenfenster ein Browserbereich, in dem der Agent Seiten aufruft, deren Inhalte liest, klickt und Text eingibt.

Praktisch heißt das: Formulare ausfüllen, Werte aus einem Dashboard auslesen, sich durch mehrstufige Oberflächen bewegen. Und zwar auch dann, wenn das Zielsystem keine Programmierschnittstelle anbietet — also keine technische Zugangsmöglichkeit, über die andere Software Daten direkt abrufen oder schreiben könnte.

Warum das für Bestandssysteme interessant ist

In vielen mittelständischen Unternehmen scheitert Automatisierung nicht am Willen, sondern an fehlenden Schnittstellen. Lieferantenportale, Behördenoberflächen, Buchungsplattformen, ältere Branchenlösungen im Browser: Wer hier Daten braucht, arbeitet mit Copy-and-paste oder mit Screenshot und Nacherfassung.

Bisher gab es dafür zwei Wege. Entweder klassische Robotic Process Automation, also Skripte, die aufgezeichnete Klickpfade wiederholen — robust, solange sich am Layout nichts ändert, und pflegeintensiv, sobald doch. Oder ein Integrationsprojekt, das eine Schnittstelle erst schafft, was beim fremden Portal meist gar nicht in der eigenen Hand liegt.

Ein Agent, der die Oberfläche liest und daraus ableitet, wo er klicken muss, verschiebt diese Grenze. Er braucht keinen exakt vorab definierten Pfad, sondern ein Ziel. Das macht ihn toleranter gegenüber kleinen Änderungen — und gleichzeitig weniger vorhersehbar als ein Skript.

Was das an Sorgfalt verlangt

Ein Agent, der in echten Oberflächen tippt und klickt, handelt im Namen des angemeldeten Nutzers. Wer solche Abläufe produktiv einsetzen will, sollte einige Punkte vorab klären:

  • Zugangsdaten und Berechtigungen: Mit welchem Konto arbeitet der Agent, und was darf dieses Konto? Ein eigener Zugang mit minimalen Rechten ist besser als der Admin-Login der Fachabteilung.
  • Schreibende Aktionen: Lesen ist harmlos, Absenden nicht. Bei Buchungen, Bestellungen oder Statusänderungen braucht es eine Bestätigung durch Menschen oder eine klar begrenzte Aufgabenstellung.
  • Nachvollziehbarkeit: Was hat der Agent wann getan? Ohne Protokoll ist eine Fehlersuche nach einer Woche kaum noch möglich.
  • Datenschutz und Nutzungsbedingungen: Personenbezogene Daten, die durch einen Agenten laufen, brauchen dieselbe Betrachtung wie jede andere Verarbeitung. Und manche Portale untersagen automatisierten Zugriff.
  • Verlässlichkeit: Ein Agent, der in neun von zehn Fällen richtig liegt, ist für eine Recherche brauchbar und für eine Rechnungsfreigabe nicht.

Die andere Richtung: eigene Anwendungen agentenfreundlich bauen

Spannender als die Frage, was Agenten mit fremden Portalen machen, ist für viele Projekte die Umkehrung: Wie baut man eine Webanwendung, die von Menschen und von Software gut bedient werden kann? Denn wenn Agenten künftig häufiger Oberflächen benutzen, wird die eigene Anwendung zum Gegenüber.

Vieles davon ist keine neue Disziplin, sondern solides Handwerk, das nun einen zweiten Nutzen bekommt:

  • Semantisches HTML und saubere Formulare: Beschriftete Felder, sinnvolle Feldtypen, echte Buttons statt geklickter Divs. Was ein Screenreader versteht, versteht auch ein Agent.
  • Stabile Struktur: Wenn sich Bezeichnungen und Reihenfolgen bei jedem Release verschieben, bricht jede Automatisierung — die maschinelle wie die im Kopf der Nutzer.
  • Vorhersehbare Zustände: Klare Rückmeldungen bei Erfolg und Fehler, eindeutige Ladezustände, keine stillen Weiterleitungen.
  • Weniger Kunstgriffe: Endlos nachladende Listen, aufwendige Drag-and-drop-Interaktionen und rein visuelle Hinweise sind für Agenten schwer zu greifen.
  • Trotzdem eine Schnittstelle: Wo es eine API gibt, ist sie der bessere Weg. Ein Agent, der Oberflächen bedient, ist der Ausweg für alles, was keine hat — nicht der Ersatz für eine ordentliche Integration.

Für TYPO3-Projekte heißt das konkret: Redaktionsprozesse, Freigaben und Importe lassen sich in Teilen durch Agenten unterstützen, wenn die Backend-Abläufe klar strukturiert sind. Und im Frontend gilt, was ohnehin gilt — barrierefreie, semantisch korrekte Ausgabe ist der beste Ausgangspunkt für alles, was danach kommt.

Realistische Einstiegsszenarien

Wer solche Automatisierung ausprobieren möchte, sollte klein anfangen und dort beginnen, wo ein Fehler wenig kostet. Gut geeignet sind Aufgaben, die heute manuell und regelmäßig anfallen, aber nicht zeitkritisch sind: Kennzahlen aus mehreren Portalen zu einem Wochenüberblick zusammenziehen, Datenbestände zwischen zwei Systemen gegenprüfen, Statusabfragen bündeln.

Weniger geeignet ist alles, was direkt Geld bewegt oder rechtlich bindet, solange die Abläufe nicht abgesichert und protokolliert sind. Ein sinnvolles Zwischenmodell: Der Agent recherchiert und schlägt vor, der Mensch bestätigt. Damit sinkt der Aufwand deutlich, ohne dass die Verantwortung verrutscht.

Einordnung

Ein Agent mit eigenem Browser senkt die Einstiegshürde für Prozessautomatisierung dort, wo Schnittstellen fehlen — und genau das ist im Mittelstand der Normalfall, nicht die Ausnahme. Für Web- und Softwareprojekte verschiebt sich damit ein Qualitätsmerkmal: Saubere Semantik, stabile Strukturen und dokumentierte Schnittstellen sind nicht mehr nur eine Frage von Barrierefreiheit und Wartbarkeit, sondern entscheiden mit darüber, ob sich eine Anwendung überhaupt in automatisierte Abläufe einbinden lässt. Wer heute neu baut, sollte beide Nutzergruppen mitdenken — Menschen und Software.

Quellen