Browser-basierte KI-Agenten für interne Anwendungen (ohne API)

Interne Tools sind der Ort, an dem Wert entsteht: Freigaben, Access Changes, Abstimmungen, Onboarding, Compliance-Evidence. Genau dort scheitert Automatisierung am häufigsten.

Typische Constraints:

• Keine stabilen APIs: Legacy-System, Vendor-Portal oder nur teilweise verfügbar.
• Zerklüftete Tool-Landschaft: ein Prozess läuft über HR, Finance, Ticketing, E-Mail und Dateien.
• Menschliche Freigaben: Controls sind real und müssen explizit sein.
• UI-Drift: Labels, Layouts und Selektoren ändern sich mit jedem Release.

Ein Browser-Agent löst ein sehr konkretes Problem: er kann die Oberfläche bedienen, die Operators heute schon nutzen. Der echte Gewinn ist aber nicht “schneller klicken”. Der Gewinn ist, wiederkehrende Arbeit in einen gesteuerten, beobachtbaren Workflow zu verwandeln: mit Ownership, Metriken und kontinuierlicher Verbesserung.

Wenn Sie UI-Automation als Skript behandeln, bricht sie. Wenn Sie sie als Workflow-Asset mit Governance, Memory und Traceability behandeln, skaliert sie.

Ein Browser-Agent ist ein Workflow-Executor, der:

• zu Seiten navigiert
• UI-Elemente anklickt
• in Felder tippt
• Tabs wechselt
• gängige Keyboard-Aktionen ausführt
• ein Task sauber abschließt und ein Ergebnis liefert

Was er nicht ist:

• kein unkontrollierter Bot, der “irgendwas” macht
• kein fragiles Makro, das nur auf einer Bildschirmgröße funktioniert
• kein Ersatz für Freigaben, Controls oder Accountability

In Process Designer ist ein Browser-Agent so gebaut, dass er zuerst deterministisch (auf Basis von Aufzeichnungen) läuft und dann bei Bedarf LLM-Fallback nutzt, wenn ein Step scheitert. Diese Kombination ist der Unterschied zwischen Demo und Betrieb.

Mentales Modell:

• deterministische Actions = Speed und Wiederholbarkeit
• LLM-Fallback = Robustheit gegen UI-Drift und kleine Überraschungen
• Governance + Telemetrie = Sicherheit, Audit und kontinuierliche Verbesserung

Zuverlässige Automatisierung für interne Tools braucht mehr als “einen Agent”. Sie braucht ein System, in dem die Komponenten zusammenarbeiten.

1) Workflow erfassen (Aufzeichnung)

Sie zeichnen einen echten Walkthrough auf: Klicks, Navigation und Eingaben über Tabs hinweg. Aufzeichnungen sind wertvoll, weil sie zeigen, was Operators heute wirklich tun.

2) Events in Actions überführen

Aufgezeichnete Events werden bereinigt (dedupliziert, sortiert, gemerged). Keystrokes werden zu sinnvollen Inputs zusammengefasst – der Workflow wird lesbar und ausführbar.

3) Deterministisch ausführen, dann recovern

Beim Run spielt der Agent die Actions deterministisch ab. Wenn ein Step failt (Selektor driftet, Page State anders), übernimmt ein eng begrenztes LLM-Fallback für diesen Step und führt sicher fort.

4) Ausführung beobachtbar machen

Jeder Run erzeugt Telemetrie: welcher Step lief, welche Action, Dauer, Failure Type. Das ist Audit Trail und Debugging-Substrat.

5) Mit Memory verbessern

Interne Arbeit wiederholt Muster: Felder, Regeln, häufige Ausnahmen. Persistentes Memory sorgt für Konsistenz über Sessions hinweg.

6) Change govern

Automatisierung ist ein lebendes Asset. Updates sollten vorgeschlagen, reviewed und mit nachvollziehbaren Diffs angewendet werden – damit Verbesserung nicht Production bricht.

Der schnellste Weg zur Automatisierung eines internen Tools startet bei dem, was schon funktioniert: ein Operator läuft den Prozess durch.

Warum Aufzeichnungen so stark sind:

• sie erfassen den realen Happy Path (nicht das Idealbild)
• sie zeigen Übergaben zwischen Systemen
• sie machen Ausnahmen sichtbar, die heute manuell gelöst werden

In der Praxis entstehen Aufzeichnungen oft in Enablement-Sessions: Screen-Share, Training-Call oder Projekt-Meeting, in dem jemand den Prozess zeigt. Eine Aufzeichnung wird zum Blueprint.

Was erfasst wird

Eine gute Aufzeichnung erfasst UI-Intent:

• wohin navigiert wird
• was geklickt wird
• was eingetippt wird
• zu welchem Tab der Step gehört

Was generiert wird

Aus der bereinigten Aufzeichnung kann Process Designer eine ausführbare Action-Sequenz erzeugen (Tab öffnen, Tab wechseln, klicken, Text eingeben, Keys senden) und ein sauberes Abschluss-Ergebnis.

Wie Aufzeichnungen wiederverwendbar werden

Damit es nicht bei “funktioniert nur einmal” bleibt, standardisieren Sie Inputs:

• fixe Werte durch Variablen ersetzen (zum Beispiel Request ID, E-Mail, Cost Center)
• Validierungsregeln nahe am relevanten Step halten
• Freigaben explizit modellieren, damit Menschen accountable bleiben

Aufzeichnungen sind nicht nur ein Shortcut. Sie sind ein wiederholbarer Intake-Prozess für Automatisierungsarbeit.

Interne Apps ändern sich. Ein zuverlässiger Browser-Agent rechnet damit.

Selbstheilende Selektoren

Wenn ein fragiler Selektor failt, kann der Agent aus stabileren Attributen (zum Beispiel data-testid, aria-label, element id) einen besseren Locator ableiten und persistieren. So entsteht über Zeit ein kleines Selektor-Memory: Repairs, die künftige Runs stabiler machen.

Progressive Context und Compaction

Browser-Automation erzeugt viel Kontext (Screenshots, DOM State, Action History). Wenn man alles an jeden LLM-Call hängt, eskalieren Kosten und Timeouts. Progressive Context löst das:

• nur ein Sliding Window der letzten Actions bleibt 1:1
• ältere History wird zusammengefasst
• Step-spezifischer Kontext wird on-demand gebaut
• Checkpoints machen lange Runs resumable

Deterministisch zuerst, LLM-Fallback danach

Ein sicherer Agent startet nicht mit “raten”. Er führt bekannte Actions deterministisch aus. Wenn ein Step failt, ist Fallback eng: Step recovern, dann weiter.

Exception Queues und Human Repair Loops

Keine Automatisierung ist zu 100% autonom. Das korrekte Design ist:

• Exceptions in eine Queue routen
• Kontext und Logs mitgeben
• Owner zuweisen
• lösen und Workflow fortsetzen

Zuverlässigkeit ist kein Zauber. Es sind Bausteine, die Sie bewusst betreiben.

Browser-Agenten sind am wertvollsten, wenn Connectoren fehlen. Connectoren bleiben aber die beste Option, wenn sie existieren.

Eine pragmatische Enterprise-Architektur ist hybrid:

• Connectoren für Systems of Record (E-Mail, Kalender, Dateien, Chat, Meeting-Plattformen)
• Browser-Agenten für interne UIs (Legacy-Portale, Vendor-Konsolen, Custom Admin Tools)

Warum hybrid gewinnt:

• APIs bewegen Daten effizient und stabil
• Browser-Agenten schließen Gaps ohne Projekt-Blocker
• Freigaben und Controls bleiben konsistent – unabhängig vom Ausführungspfad

So vermeiden Sie eine falsche Wahl zwischen “erst Connector bauen” und “aufgeben”. Sie automatisieren jetzt und reifen Integrationen später sauber nach.

Automatisierungsarbeit beginnt oft lange vor einer technischen Spezifikation. Sie beginnt in Meetings: jemand erklärt den Prozess, teilt einen Screen oder beschreibt ein wiederkehrendes Problem.

Process Designer unterstützt einen Asset-first Ansatz:

• Meeting-Artefakte ingestieren (Nachrichten, Dateien, Transkripte, Recording-Links)
• daraus eine durchsuchbare Knowledge Base machen
• einen kompakten Project Knowledge Digest erzeugen
• Muster erkennen, die Automatisierung nahelegen

Darauf aufbauend kann eine Knowledge-Graph Analyse Automatisierungs-Chancen vorschlagen: wiederholte Übergaben, manuelle Data Flows und Integrations-Choke Points. Diese Chancen werden zu konkreten Agent-Proposals: Browser-Agent erstellen, ändern oder ausführen – mit dem richtigen Kontext.

Der Punkt ist nicht “AI macht alles”. Der Punkt ist eine Pipeline, die echte operative Evidence in sichere, gesteuerte Ausführung übersetzt.

Reale Automatisierungen brauchen mehrere Skills. Ein Agent allein reicht selten.

A2A-Orchestrierung bedeutet: ein Workflow läuft als koordinierter Satz von Agent-Rollen:

• deterministischer Executor für aufgezeichnete Steps
• dynamischer Browser-Agent für Recovery und UI-Drift
• Tool-Agenten für Connector-Aktionen und Datenzugriff

Was das in der Praxis möglich macht:

• geteilter Execution Context (Variablen und Zwischenergebnisse)
• progressive Kontextverwaltung (der LLM sieht nur, was er braucht)
• Memory, das wiederverwendbares Wissen persistiert
• einheitliche Telemetrie über den gesamten Run

Statt einen Monolithen zu bauen, komponieren Sie Bausteine, die testbar, tracebar und unabhängig verbesserbar sind.

Viele interne Prozesse hängen von Kontext ab:

• wie Ihre Organisation Systeme und Teams nennt
• welche Felder zählen und wo sie stehen
• welche Ausnahmen häufig sind und wie man sie repariert
• was “gutes Ergebnis” bedeutet

Long-term Memory löst ein operatives Problem: es verhindert, dass Agenten sich bei jedem Run wie ein neuer Mitarbeiter verhalten.

In Process Designer kann Memory als strukturierter Inhalt mit Memory-Type (context, episodic, long-term) und Retention Policy persistiert werden. Das ermöglicht:

• Kontinuität über Sessions hinweg
• Wiederverwendung über Workflows hinweg
• sicherere Automatisierung (bekannte Ausnahmen und Controls dokumentiert)

Memory ist nicht nur Modell-Feature. Es ist Teil des Operating Models: Ownership, Retention und Governance.

Wenn Sie nicht erklären können, was der Agent getan hat, können Sie ihn nicht betreiben.

Production-Grade Automatisierung sollte liefern:

• Step-by-step Events (Phase, Timestamp, Dauer)
• Action Type und Outcome (ok oder failure)
• Failure Classification (was brach, wo)
• Selector-Repair Events (was wurde repariert, warum)
• Context-Stats (wie Kontext reduziert und zusammengefasst wurde)

Mit Trace-Logs können Teams:

• Failures schnell debuggen
• Compliance nachweisen (wer genehmigte was, was änderte sich)
• Zuverlässigkeit und Kosten messen
• erkennen, wo bessere Inputs oder Exception Paths nötig sind

Trace-Logs verbinden Automatisierung mit Governance: Reviews werden konkret, Verbesserungen messbar.

Interne Anwendungen enthalten oft sensitive Daten. Browser-Agenten müssen mit Constraints laufen.

Typische Guardrails:

• side-effectful Actions standardmäßig begrenzen
• Execution Sessions isolieren und Trigger transparent machen
• Freigaben für riskante Steps explizit halten
• Run Traces so sanitizen, dass keine großen Binärdaten persistiert werden
• Retention Policies für Memory und Traces durchsetzen

So behalten Sie Speed, ohne eine unkontrollierte Risk Surface zu schaffen.

Browser-Agenten sind nicht für alles. Ideal sind UI-lastige Aufgaben mit klaren Outcomes.

Beispiele:

• Access Requests: Request validieren, Zuweisungen im Admin-Portal setzen, Freigaben routen, Evidence loggen.
• Purchase Approvals: Angebote sammeln, PO im ERP UI anlegen, Freigabe, Dokumente anhängen, Eingang bestätigen.
• Customer Onboarding: interne Tools öffnen, Accounts anlegen, Rechte konfigurieren, Welcome auslösen, Abschluss dokumentieren.
• Finance Ops: Reports ziehen, Zahlen abstimmen, Dashboards aktualisieren, Abweichungen eskalieren.
• Compliance Evidence: Vendor-Konsolen bedienen, Logs exportieren, Artefakte hochladen, Audit Trail erzeugen.

Die besten Use Cases haben drei Merkmale:

1. wiederholbarer UI-Pfad
2. klare Exception Patterns
3. hoher Bedarf an Traceability

Machen wir es konkret.

Scenario

Ein Mitarbeiter braucht Zugriff auf ein internes System. Es gibt keine API. Der einzige Weg ist ein Admin-Portal im Browser. Der Prozess muss compliant bleiben.

Workflow-Design (was die Automatisierung enthalten muss)

1. Request Intake: Identität, System, benötigte Rolle, Begründung, Manager.
2. Validierung: Pflichtfelder, gültige System/Rollen, keine Doppelanfrage.
3. Freigabe: Manager genehmigt (optional Security für privilegierte Rollen).
4. Ausführung (Browser-Agent): Portal öffnen, User suchen, Access-Page öffnen, Rolle/Gruppe hinzufügen, bestätigen.
5. Evidence: Outcome der Freigabe + Execution Result erfassen (Timestamp, Zielrolle, wer/was ausführte).
6. Benachrichtigung: Requester und Owner informieren.

Wo Zuverlässigkeit bricht (und wie Sie designen)

• UI-Drift: der Button “Rolle hinzufügen” ist woanders. Selector-Repairs auf Basis stabiler Attribute persistieren.
• Anderer State: User hat Rolle schon. Check einbauen und sicher verzweigen.
• Portal Timeouts: Timeouts als recoverable behandeln; retry oder re-auth.

Warum Trace-Logs Betrieb möglich machen

Ein Run Trace sollte beantworten:

• welche Freigaben erteilt wurden
• welche UI-Steps ausgeführt wurden
• was failte und welche Recovery versucht wurde
• welche Evidence erfasst wurde

Das ist der Unterschied zwischen “geht manchmal” und “läuft 500x pro Woche zuverlässig”.

Nutzen Sie dieses Framework, um den passenden Ausführungspfad zu wählen.

Connector wählen, wenn

• das System stabile APIs hat
• Datenvolumen hoch ist (Bulk Reads/Writes)
• Sie transaktionale Guarantees brauchen
• der Vendor versionierte Interfaces liefert

Browser-Agent wählen, wenn

• keine API existiert oder sie unvollständig ist
• die Arbeit UI-only ist (Admin-Portale, Legacy-Konsolen)
• der Workflow von interaktiven Screens/Freigaben abhängt
• Sie Value jetzt brauchen und nicht auf Integrationsprojekte warten können

Hybrid wählen, wenn

• Sie Daten per API holen können, aber finale Steps nur in der UI gehen
• Sie Connectoren für read-heavy Steps nutzen und den Gap per Browser-Agent schließen
• Sie resiliente Fallback-Pfade brauchen, wenn ein System unavailable ist

Pragmatisches Pattern: Connectoren für Datenbewegung, Browser-Agenten für die “Last Mile” in internen Tools, Freigaben für High-Risk Entscheidungen.

Browser-Agenten laufen am zuverlässigsten, wenn die UI auf Stabilität ausgelegt ist. Die gute Nachricht: dafür brauchen Sie kein Redesign.

6 Signale für eine “automatisierungsfreundliche” UI

1. Stabile Attribute für zentrale Elemente existieren (z. B. data-testid, aria-label, stabile IDs).
2. Formulare sind eindeutig: Label passt zum Feld, Pflichtfelder sind klar, Validierung ist sichtbar.
3. Navigation bleibt konsistent: dieselbe Aufgabe liegt nach Releases am selben Ort.
4. Zustände sind explizit: Erfolg/Fehler werden klar angezeigt (nicht nur “irgendwie anders”).
5. Fehler sind reparierbar: die UI zeigt, was schief lief und wie man es behebt.
6. Rollen sind real: Berechtigungen passen zu operativen Rollen, keine geteilten Admin-Accounts.

Checkliste für Ihr internes App-Team

• data-testid auf primäre Buttons, Absenden-Aktionen, Suchfelder und Bestätigungsdialoge.
• aria-label für Icon-Buttons (stabil halten).
• Keine zufällig generierten IDs für wichtige Aktionen.
• Eindeutige, stabile Feldlabels (nicht wechselnde Texte).
• Fehler müssen im DOM sichtbar sein (nicht nur kurzlebige Toasts).
• Ein stabiles Bestätigungs-Element nach schreibenden Aktionen (gespeichert/erstellt/aktualisiert).
• Konsistentes Verhalten für “Zurück” und “Abbrechen”.

Diese Verbesserungen helfen nebenbei auch Accessibility und E2E-Testing. Viele Teams können das in einem Sprint liefern — und reduzieren damit den Wartungsaufwand für Automatisierung massiv.

Interne Automatisierung scheitert oft an denselben Gründen: fehlende Daten, unterschiedliche Berechtigungen, UI-Drift und inkonsistenter State. Wenn Sie Ausnahmen bewusst designen, werden Failures zu einem gemanagten Workflow.

5 Patterns, die den Großteil der Realität abdecken

1. Pre-flight Validierung

   • Pflicht-Inputs prüfen, bevor die UI geöffnet wird
   • Rollen-/Berechtigungskontext früh verifizieren

2. Idempotenz-Checks

   • vor “Create”: existiert das Objekt schon?
   • vor “Add Role”: hat der User die Rolle bereits?

3. Timeouts + Retries (mit Backoff)

   • nur retryen, wenn der Fehler wahrscheinlich transient ist
   • jeden Versuch loggen, klare Grenze setzen

4. Re-Auth und Session Drift

   • Login-Screens und abgelaufene Sessions erkennen
   • re-auth oder in den Human Repair Loop routen

5. Sicherer Stop + Repair Loop

   • bei High-Risk Changes “fail closed”
   • Evidence erfassen (was versucht wurde, wo es failte)
   • in eine Exception Queue mit Owner routen
   • nach Repair mit ursprünglichem Kontext fortsetzen

Wie “gutes Scheitern” aussieht

Ein guter Failure ist nicht still. Er ist ein strukturiertes Ergebnis: Grund, Evidence, nächste Aktion und Ownership.

Trace-Logs und Telemetrie machen Ausnahmen zu einem Backlog, den Sie fixen können — und zu Zuverlässigkeitsverbesserungen, die messbar sind.

Teams, die Automatisierung skalieren, standardisieren, wie sie bauen und betreiben. Nutzen Sie diese Vorlagen als Startpunkt.

Vorlage 1: Automation Intake (eine Seite)

• Prozessname:
• Owner (Fachbereich):
• Owner (IT):
• Trigger (was startet es):
• Definition of Done (was gilt als abgeschlossen?):
• Inputs (Variablen):
• Betroffene Systeme (UI + Connectoren):
• Freigaben (wer, wann, welche Evidence):
• Top-Ausnahmen (und Repair):
• KPIs (Durchlaufzeit, Exception Rate, Rework):

Vorlage 2: Recording-Skript (das Wesentliche aufnehmen)

• Happy Path Walkthrough
• 2–3 Exception Walkthroughs
• Notizen für Variable-Placeholders
• Notizen für “State Checks” (existiert schon? bereits genehmigt?)

Vorlage 3: Betriebs-Runbook (damit es skaliert)

• Monitoring: wie “healthy” aussieht
• Eskalation: wer besitzt Failures
• Release-Check: was nach UI-Änderungen validiert wird
• Telemetrie-Review Rhythmus (wöchentlich/monatlich)
• Retention-Regeln für Memory und Traces

Evidence-Checkliste (für Audits)

• Freigabe-Outcome + Identität des Approvers
• timestamped Execution Result
• was wurde geändert (Rolle/Gruppe/Wert)
• Link zum Run Trace der Session

Vorlagen bremsen nicht — sie reduzieren Unklarheit und machen Zuverlässigkeit über Workflows hinweg wiederholbar.

Ein typischer interner Workflow spannt Systeme, die nie für Orchestrierung gebaut wurden.

Scenario

Ein Team muss Software oder Equipment einkaufen.

• Request startet in Chat oder E-Mail.
• Angebot liegt in Drive/OneDrive.
• Freigaben sind nötig (Manager + Finance).
• Der finale Schritt ist UI-only im ERP/Procurement-Portal.

Hybrid-Workflow (Design)

1. Intake + Normalisierung (Connector)

   • Requester, Vendor, Betrag, Cost Center erfassen
   • Pflichtfelder und Policy-Thresholds prüfen

2. Evidence einsammeln (Connector)

   • Angebotsdatei ziehen und an den Request-Kontext hängen
   • stabilen Link zum Source-Dokument speichern

3. Freigaben (Workflow Governance)

   • Manager Approval
   • ab Schwellwert zusätzlich Finance Approval
   • Outcome + Timestamp erfassen

4. Ausführung (Browser-Agent im ERP UI)

   • Portal öffnen
   • PO/Request anlegen
   • Vendor, Cost Center, Line Items befüllen
   • Evidence-Link anhängen oder Datei hochladen (je nach Portal)
   • abschicken und Confirmation ID erfassen

5. Post-Actions (Connector)

   • Requester/Owner benachrichtigen
   • Tracker aktualisieren (Spreadsheet, Ticket oder internes Dashboard)

Wo es in der Praxis bricht

• Vendor Name passt nicht: Lookup-Step + Human Review Pfad
• Session läuft ab: Login-Screen erkennen, re-auth oder Repair Loop
• Duplicate Request: vorhandene PO IDs prüfen, bevor erstellt wird

Was “done” bedeutet

• Freigaben erfasst
• ERP Confirmation ID erfasst
• Evidence-Link erfasst
• Trace-Log Link für Audit gespeichert

Genau hier helfen Browser-Agenten: der UI-only Step wird betreibbar, ohne auf ein ERP-Connector-Projekt warten zu müssen.

Browser-Agenten erschließen Automatisierung, wenn APIs fehlen. Aber sie sind nicht für jede Last das beste Werkzeug. Nutzen Sie diesen Abschnitt als praktischen Entscheidungsleitfaden.

Best-fit Szenarien für Browser-Agenten

• UI-only interne Tools (Admin-Portale, Vendor-Konsolen, Legacy-Apps)
• Klare, wiederholbare Pfade mit stabiler Definition von “done”
• Approval-lastige Workflows, bei denen Controls explizit bleiben müssen
• Last-mile Ausführung, wenn Daten per API kommen, der Abschluss aber nur in der UI geht

Szenarien, in denen Connectoren meist gewinnen

• Hohes Datenvolumen (tausende Records pro Run)
• Strenge SLAs, bei denen UI-Latenz nicht akzeptabel ist
• Transaktionale Integrität, die API-Level Guarantees benötigt
• Häufige UI-Redesigns, bei denen die Oberfläche wöchentlich driftet

Ein einfaches Entscheidungsraster

Der Hybrid-Pfad (so entwickeln sich die meisten Teams)

Starten Sie mit einem Browser-Agenten, um Value jetzt zu liefern, und ersetzen Sie anschließend schrittweise die schwersten Steps durch Connectoren, wenn Ihre Integrationsstrategie reift. Der Workflow bleibt derselbe — nur die Ausführungsblöcke ändern sich.

Ziel ist nicht “ein Agent, der klickt”. Ziel ist eine governed Automatisierungsfähigkeit, die messbar, auditierbar und resilient ist.

Ein guter Rollout ist iterativ.

Woche 1: auswählen und baselinen

• einen internen Workflow mit klarem Owner wählen
• Durchlaufzeit und Exception Rate baselinen
• definieren, was “done” bedeutet und welche Evidence nötig ist

Woche 2: aufnehmen und v1 shippen

• Happy Path und 2–3 Ausnahmen aufnehmen
• Aufzeichnung in Actions überführen
• deterministisch mit Trace-Logs ausführen
• Freigaben explizit halten

Wochen 3–4: härten

• Selector-Repairs für fragile Steps ergänzen
• Exception Queue + Repair Loop ergänzen
• Retries und Timeouts, wo relevant
• wiederkehrenden Kontext in Long-term Memory verschieben

Laufend: betreiben

• Failures monatlich reviewen
• häufige Ausnahmen in Workflow-Verbesserung übersetzen
• mit demselben Playbook auf weitere Prozesse ausweiten

Ergebnis ist kein Bot. Es ist eine Automatisierungsfähigkeit, die Ihr Team wiederholen kann.