KI-Agenten scheitern an der UI-Grenze: So geben Sie Coding-Agenten Zugriff auf Android, iOS, Web und Desktop ohne selbstgebautes Klebechaos

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau

Ich bin Denis Shokhirev, Agentic AI Systems Architect in Freiburg im Breisgau, Germany, und ich liefere mit DennisCraft AI Studio produktive KI-Systeme für DACH-B2B-Kunden auf Basis von Claude, Supabase, n8n, Doppler und self-hosted Postgres. Im Produktivbetrieb sehe ich immer wieder denselben Bruch: Der Coding-Agent schreibt brauchbaren Backend-Code, ergänzt Datenbankzugriffe und verbindet APIs, scheitert dann aber an der UI-Grenze, weil ihm ein kontrollierter Zugriff auf Android, iOS, Browser oder Desktop fehlt.

Genau an dieser Stelle kippen viele Agentenprojekte in eine Sammlung selbstgebauter Hilfsskripte. Ein wenig Playwright für das Web, etwas adb für Android, irgendwo Screenshots auf Dateiebene, dazu manuelle Zwischenschritte. Das reicht für eine Vorführung. Für einen erprobten Produktivbetrieb mit Nachvollziehbarkeit, Sicherheitsprüfung und sauberer Fehleranalyse reicht es nicht.

Das eigentliche Problem ist fehlende Steuerungsarchitektur

Viele Teams vermuten zuerst ein Modellproblem. In der Praxis liegt der Engpass oft woanders: Der Agent hat keinen einheitlichen Weg, Zustand zu beobachten, Aktionen auszuführen, Artefakte zu sichern und diese Informationen wieder in den Planungszyklus zurückzugeben. Ohne diesen Rahmen improvisiert das Modell auf lückenhafter Grundlage.

Das zeigt sich je nach Oberfläche unterschiedlich:

Ein produktiver Agent braucht daher keinen unbeschränkten Zugriff, sondern einen klar begrenzten Handlungskatalog mit verlässlicher Rückmeldung. Das ist eine Architekturfrage, keine Frage des Promptings.

Ein einheitlicher Aktionsvertrag schlägt selbstgebautes Klebechaos

Kein direkter Shell-Zugriff für das Modell

Ich empfehle, dem Agenten nicht ungefiltert Shell-Werkzeuge zu geben. Besser ist eine schmale Aktionsschicht mit festen Operationen wie observe, act, artifact und state. Browser, Android, iOS und Desktop werden darunter als Adapter umgesetzt, aber aus Sicht des Agenten gilt immer derselbe Vertrag.

import subprocess
from typing import TypedDict

class ToolResult(TypedDict):
    ok: bool
    stdout: str
    stderr: str

def adb_tap(serial: str, x: int, y: int) -> ToolResult:
    cmd = ["adb", "-s", serial, "shell", "input", "tap", str(x), str(y)]
    proc = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
    return {"ok": proc.returncode == 0, "stdout": proc.stdout.strip(), "stderr": proc.stderr.strip()}

def adb_screenshot(serial: str, path: str) -> ToolResult:
    cmd = ["adb", "-s", serial, "exec-out", "screencap", "-p"]
    with open(path, "wb") as f:
        proc = subprocess.run(cmd, stdout=f, stderr=subprocess.PIPE, timeout=10)
    return {"ok": proc.returncode == 0, "stdout": path, "stderr": proc.stderr.decode().strip()}

Entscheidend ist nicht das einzelne Werkzeug, sondern die Begrenzung. Der Agent erzeugt nicht bei jedem Schritt neue Shell-Befehle, sondern ruft bekannte Funktionen mit Protokollierung, Zeitbegrenzung und einheitlicher Fehlerbehandlung auf.

Ein gemeinsames Ereignisprotokoll für alle Oberflächen

Ein weiterer häufiger Fehler ist die verteilte Ablage von Nachweisen. Screenshots liegen im Objektspeicher, DOM-Snapshots in temporären Verzeichnissen, Protokolle auf dem Worker, menschliche Kommentare in Chat-Tools. Für Betriebsanalyse und Kundennachweise ist das unpraktisch.

create table agent_ui_events (
  id bigserial primary key,
  run_id uuid not null,
  step_index int not null,
  surface text not null,
  action text not null,
  status text not null,
  artifact_path text,
  log_excerpt text,
  created_at timestamptz default now()
);

Ich bevorzuge eine zentrale Ereignistabelle in Postgres, ergänzt um Artefaktverweise. Damit werden Wiederholbarkeit, Prüfung und Übergabe vom Agenten an einen Menschen deutlich einfacher.

Sicherheitsprüfung und Regulierung sind hier besonders wichtig

Sobald ein Agent klicken, tippen und navigieren kann, entstehen andere Risiken als bei reiner Codegenerierung. OWASP nennt in der LLM Top 10 für 2025 ausdrücklich Prompt Injection und Excessive Agency als relevante Risiken für agentische Systeme: https://genai.owasp.org/llm-top-10/. Auf der UI-Ebene werden solche Risiken unmittelbar betrieblich wirksam.

Für DACH-Unternehmen kommt hinzu, dass Nachvollziehbarkeit und Begrenzung auch regulatorisch helfen. Im Umfeld von DSGVO, ISO 27001, NIS2 oder künftig dem EU AI Act ist es leichter, einen begrenzten und protokollierten Werkzeugsatz zu vertreten als einen Agenten mit pauschalem Shell-Zugriff auf Produktivumgebungen.

Ich setze in der Praxis meist vier Leitplanken:

• eine Positivliste für Geräte, Domains und Anwendungen;
• harte Zeitbegrenzungen und Schrittlimits je Sitzung;
• Pflicht zur Sicherung von Artefakten vor und nach kritischen Aktionen;
• statische Prüfung generierten Codes vor der Ausführung.

#!/usr/bin/env bash
set -euo pipefail

bandit -r ./generated_code -f json -o bandit-report.json
gitleaks detect --source ./generated_code --report-format json --report-path gitleaks-report.json
semgrep --config auto ./generated_code --json --output semgrep-report.json

echo "Prüfungen abgeschlossen"

Bandit, gitleaks und semgrep beseitigen nicht jedes Risiko. Sie helfen aber, offensichtliche Schwachstellen zu erkennen, bevor der Agent Ausführungsrechte erhält.

Ein praktikables Muster für Android, iOS, Web und Desktop

Eine Steuerungsebene, vier Adapter

Sie brauchen keine vier unabhängigen Automatisierungswelten. Sie brauchen eine Steuerungsebene, die Aufgaben annimmt, Zustand verwaltet, Ereignisse speichert und dem Agenten einen normalisierten Werkzeugkatalog anbietet. Darunter sitzen Adapter für die jeweilige Oberfläche.

tools:
  - name: browser_open
    surface: web
    requires_artifact: true
  - name: android_tap
    surface: android
    requires_artifact: true
  - name: ios_screenshot
    surface: ios
    requires_artifact: true
  - name: desktop_type
    surface: desktop
    requires_artifact: true

Im Web kann das über Playwright laufen. Für Android über Emulatoren oder reale Geräte mit adb. Für iOS über Simulatoren und Systemwerkzeuge. Für Desktop-Anwendungen über kontrollierte virtuelle Maschinen. Wichtig ist nicht der jeweilige Transport, sondern dass der Agent immer dieselbe Fähigkeitssprache und dasselbe Antwortschema sieht.

Das senkt auch die Betriebskosten. Wenn eine neue Oberfläche hinzukommt, ersetzen Sie nur einen Adapter statt die gesamte Orchestrierung. Falls Sie bereits n8n einsetzen, lässt sich dieses Muster gut in eine ereignisgesteuerte Pipeline überführen: Werkzeugaufruf, Adapterausführung, Artefaktspeicherung, erneute Planung, bei Bedarf Übergabe an einen Menschen.

FAQ

Reicht beim Web der DOM-Zugriff aus?

Für manche Web-Abläufe ja. Für mobile und Desktop-Oberflächen in der Regel nicht. Dort brauchen Sie zusätzlich Screenshots oder Zugänglichkeitsdaten, sonst fehlt dem Agenten wesentlicher Kontext.

Kann Playwright alle Oberflächen abdecken?

Nein. Playwright ist sehr gut für Web-Automatisierung, ersetzt aber weder Android- noch iOS- oder Desktop-spezifische Steuerung. Dafür sind eigene Adapter notwendig.

Warum nicht einfach Shell-Zugriff geben und alles protokollieren?

Weil Protokollierung keine unkontrollierte Handlungsfreiheit korrigiert. Ein begrenzter Werkzeugsatz ist leichter zu prüfen, leichter zu testen und gegenüber Kunden leichter zu vertreten.

Was ist wichtiger: Screenshots oder Systemprotokolle?

Beides. Screenshots zeigen, was der Agent gesehen hat. Systemprotokolle zeigen, was intern tatsächlich passiert ist. Für eine zügige Fehleranalyse brauchen Sie beide Sichtweisen.

Womit sollte ein kleines Team beginnen?

Beginnen Sie mit einer Oberfläche, meist Web oder Android, und definieren Sie zuerst ein stabiles Antwortschema für Werkzeuge. Wenn Ereignisprotokoll und Artefaktspeicherung sauber stehen, lässt sich der Ausbau auf iOS und Desktop deutlich kontrollierter vornehmen.

Wenn Sie bereits Coding-Agenten im Produktivbetrieb einsetzen: An welcher Stelle entstehen bei Ihnen derzeit die teuersten Ausfälle — beim Browserzustand, bei der Geräteansteuerung von Android, bei der Orchestrierung von iOS-Simulatoren, bei Desktop-Interaktionen oder bei der Rückführung von Artefakten in die Planungslogik? Mich interessiert ehrlich, wo in Ihrer Pipeline die meisten Probleme im Betrieb entstehen.

I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.