Bleibt Ihr KI-Agent ohne Menschen stehen? Hintergrundschleifen führen Aufgaben zu Ende und eskalieren nur unklare Entscheidungen
von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau Ich bin Denis Shokhirev, Agentic AI Systems Architect aus Freiburg im Breisgau, Germany, und ich betreibe bei DennisCraft AI Studio produktive KI-Systeme auf Basis von Claude, Supabase, n8n, Doppler und selbst gehostetem Postgres. Der häufigste Ausfall, den ich im Produktivbetrieb sehe, ist unspektakulär: Der Agent erledigt den Großteil einer Aufgabe, stößt auf einen unklaren Zwischenschritt und wartet dann stundenlang auf ei
von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau
Ich bin Denis Shokhirev, Agentic AI Systems Architect aus Freiburg im Breisgau, Germany, und ich betreibe bei DennisCraft AI Studio produktive KI-Systeme auf Basis von Claude, Supabase, n8n, Doppler und selbst gehostetem Postgres. Der häufigste Ausfall, den ich im Produktivbetrieb sehe, ist unspektakulär: Der Agent erledigt den Großteil einer Aufgabe, stößt auf einen unklaren Zwischenschritt und wartet dann stundenlang auf einen Menschen, obwohl die restlichen sicheren Schritte im Hintergrund weiterlaufen könnten.
Das ist in der Regel kein Modellproblem, sondern ein Architekturproblem. Wenn Ihr Ablauf aus genau einem Modellaufruf und einer pauschalen Freigabe besteht, bauen Sie keinen autonomen Prozess, sondern einen Chat mit Zusatzkosten. In produktiven Umgebungen ersetze ich dieses Muster durch Hintergrundschleifen: Der Agent arbeitet sichere Teilschritte selbstständig ab, speichert seinen Zustand in Postgres, wiederholt externe Aufrufe kontrolliert und eskaliert nur dort, wo eine Entscheidung unklar, irreversibel oder regulatorisch sensibel ist.
Warum KI-Agenten im Produktivbetrieb stehen bleiben
Viele Teams beginnen mit einem synchronen Anfrage-Antwort-Muster, weil es sich schnell zeigen lässt. Eine Aufgabe wird übergeben, das Modell plant, ruft ein Werkzeug auf, erzeugt ein Ergebnis und ein Mensch gibt frei. Das reicht für eine Vorführung. Sobald die Aufgabe aber mehrere Systeme berührt, auf eine API warten muss oder zusätzliche Daten anfordert, fehlen dauerhafter Zustand, Wiederholungslogik und klare Regeln für selbstständige Entscheidungen.
Typische Anzeichen
| Symptom | Ursache | Abhilfe |
|---|---|---|
| Aufgabe scheitert nach einem API-Fehler | Keine Wiederholungslogik | Teilschritte in Schleifen mit begrenzten Versuchen ausführen |
| Menschen geben triviale Schritte frei | Keine Risikoklassifizierung | Sichere, prüfpflichtige und gesperrte Aktionen trennen |
| Fortschritt geht nach Neustart verloren | Zustand nur im Arbeitsspeicher | Zustand in Postgres oder Supabase speichern |
| Niemand weiß, warum die Aufgabe anhält | Kein Ereignisprotokoll | Statuswechsel und Begründungscodes speichern |
Die eigentliche Frage lautet daher nicht, ob Menschen beteiligt sein sollen. Die Frage lautet, an welchen genauen Entscheidungspunkten menschliche Prüfung den zusätzlichen Zeitbedarf rechtfertigt. Datenerfassung, Feldnormalisierung, Entwurf einer Antwort oder Wiederholung eines fehlgeschlagenen Aufrufs benötigen meist keine Freigabe, wenn die Grenzen technisch sauber gesetzt sind.
Das Muster der Hintergrundschleife
Mit Hintergrundschleife meine ich kein eigenes Produkt, sondern ein Betriebsmuster. Eine Aufgabe existiert als Datensatz in der Datenbank. Ein Worker übernimmt die Aufgabe, führt genau einen Schritt aus, speichert das Ergebnis, aktualisiert den Status und plant den nächsten Lauf. Bei Unsicherheit oder hohem Risiko landet die Aufgabe in einer Warteschlange für menschliche Prüfung. Dieses Muster ist nachvollziehbar, wiederaufnehmbar und auditierbar.
Eine einfache Zustandsmaschine
Ich beginne meist mit queued, running, waiting_external, waiting_human, done und failed. Ergänzt werden attempt_count, next_run_at, risk_level und reason_code. Damit wandert Geschäftslogik aus dem Prompt in überprüfbare Systemzustände.
import os, psycopg
from anthropic import Anthropic
db = psycopg.connect(os.environ["DATABASE_URL"])
client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])
with db.cursor() as cur:
cur.execute("""
select id, prompt, attempt_count
from agent_tasks
where status in ('queued','running')
and next_run_at <= now()
order by created_at
limit 5
for update skip locked
""")
rows = cur.fetchall()
for task_id, prompt, attempts in rows:
msg = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=500,
messages=[{"role": "user", "content": prompt}]
)
text = msg.content[0].text
status = "waiting_human" if "NEEDS_APPROVAL" in text else "done"
with db.cursor() as cur:
cur.execute(
"update agent_tasks set status=%s, result=%s, attempt_count=%s where id=%s",
(status, text, attempts + 1, task_id)
)
db.commit()Wesentlich ist dabei nicht der einzelne SDK-Aufruf, sondern die Begrenzung des Arbeitsschritts. Jeder Schleifendurchlauf erledigt genau eine kontrollierbare Einheit. Benötigt das Modell weitere Daten, folgt ein weiterer Durchlauf. Trifft es auf eine Richtliniengrenze, wird an einen Menschen eskaliert.
Wo Selbstständigkeit enden sollte
Ich bewerte Aktionen nach Risiko und Reversibilität. Ein stabiler Agent kann reversible und risikoarme Schritte eigenständig ausführen. Rechtlich, finanziell oder datenschutzrechtlich sensible Aktionen bleiben prüfpflichtig.
| Aktion | Eigenständig | Menschliche Prüfung |
|---|---|---|
| Interne APIs lesen | Ja | Nur bei Zugriffsfehlern |
| Eingehende Anfragen klassifizieren | Ja, mit Protokollierung | Bei niedriger Sicherheit |
| Kundenantwort entwerfen | Ja | Bei rechtlichen oder vertraglichen Formulierungen |
| Postgres-Datensätze ändern | Ja, über SQL-Positivliste | Bei Massenänderungen |
| Zahlungen, Verträge, Löschung von Daten | Nein | Immer |
Gerade im DACH-Markt ist dieser Punkt nicht theoretisch. DSGVO, NIS2, ISO 27001, BSI Grundschutz und der EU AI Act verlangen keine magischen KI-Lösungen, sondern nachvollziehbare Kontrollen. Wenn ein Agent personenbezogene Daten verarbeitet oder operative Entscheidungen vorbereitet, müssen Zuständigkeiten, Protokollierung und Freigaberegeln klar definiert sein.
#!/usr/bin/env bash
set -euo pipefail
bandit -r app/ -f json -o bandit.json
gitleaks detect --source . --report-format json --report-path gitleaks.json
semgrep --config p/owasp-top-ten --json --output semgrep.json
if jq -e '.results | length > 0' semgrep.json >/dev/null; then
echo "Semgrep found issues"
exit 1
fi
echo "Prüfungen bestanden"Solche Prüfungen nutze ich nicht nur in der CI-Pipeline, sondern bei Bedarf auch vor der Ausführung von durch das Modell erzeugtem Code oder SQL. OWASP nennt im LLM Top 10 für 2025 unter anderem excessive agency, prompt injection und insecure output handling als relevante Risiken: https://genai.owasp.org/.
Beobachtbarkeit ist wichtiger als ein schöner Prompt
Wenn ein Team sagt: „Der Agent hängt manchmal“, frage ich zuerst: Bei welchem Schritt? Mit welchem Begründungscode? Nach wie vielen Wiederholungen? Wenn diese Antworten nicht ohne Container-Logs verfügbar sind, fehlt keine Formulierung im Prompt, sondern die Betriebsbeobachtung.
Was zwingend protokolliert werden sollte
- task_id, step_name, status_before, status_after
- reason_code für jeden Zustandswechsel
- attempt_count und next_run_at
- welche Werkzeuge mit welchen Rechten genutzt wurden
- wer eine Eskalation freigegeben hat und wie lange dies dauerte
Diese Daten sind nicht nur für Fehleranalyse nützlich, sondern auch für Nachweisführung gegenüber Kunden, internen Prüfungen und Informationssicherheitsvorgaben. Eine produktive KI-Architektur muss erklären können, warum eine Aktion stattgefunden hat.
Ein praxistauglicher Aufbau mit n8n, Supabase und Postgres
Für mittelständische Umgebungen genügt oft ein klarer, einfacher Aufbau: Supabase oder selbst gehostetes Postgres als führender Zustand, n8n für Orchestrierung und zeitgesteuerte Anstöße, Python-Worker für die Modellausführung und Doppler für Geheimnisse. Für öffentliche Einblicke verwende ich einen getrennten Nur-Lese-Pfad ohne sensible Nutzdaten.
name: agent-loop
on:
schedule:
- cron: "*/2 * * * *"
jobs:
loop:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.12"
- run: pip install anthropic psycopg[binary]
- run: python workers/run_loop.py
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
DATABASE_URL: ${{ secrets.DATABASE_URL }}Dieser Aufbau ist nicht spektakulär, aber er übersteht Neustarts, Freigaben, Warteschlangen und Audits. Genau darin liegt meist der Unterschied zwischen einer ansprechenden Vorführung und einem System, das nachts selbstständig Arbeit abschließt.
FAQ
Wann brauche ich eine Hintergrundschleife statt einer Chat-Oberfläche?
Immer dann, wenn Aufgaben mehrstufig sind, externe Systeme einbeziehen oder Wiederholungen benötigen. Sobald Zustände und Seiteneffekte entstehen, ist eine Schleife meist die sicherere Form.
Kann ich das nur mit n8n umsetzen?
Für einfache Abläufe ja. Bei längeren Prozessen mit Verzweigungen, Prüfpflichten und Nachvollziehbarkeit empfehle ich jedoch, den dauerhaften Zustand in Postgres zu halten und n8n als Orchestrierungsschicht zu verwenden.
Braucht jeder Agent immer menschliche Freigabe?
Nein. Sinnvoll ist menschliche Prüfung bei Unsicherheit oder hohem Risiko. Eine Freigabe für jeden Kleinschritt macht aus Automatisierung nur verzögerte Handarbeit.
Was ist das häufigste Fehlmuster?
Den gesamten Zustand im Prompt oder im Speicher eines einzelnen Prozesses zu halten. Der erste Neustart oder Timeout wird dann sofort zum Betriebsproblem.
Woran messe ich, ob Hintergrundschleifen helfen?
Beobachten Sie mittlere Bearbeitungszeit, Anteil ohne menschlichen Eingriff abgeschlossener Aufgaben, Zeit bis zur Eskalation und Erfolgsquote von Wiederholungen. Ohne diese Kennzahlen bleibt die Bewertung rein subjektiv.
An welcher Stelle bleibt Ihr KI-Agent im Produktivbetrieb am häufigsten stehen: bei Werkzeugaufrufen, bei Wiederholungen externer APIs, an Richtliniengrenzen oder bei menschlichen Freigaben? Das würde ich gern mit den Mustern vergleichen, die ich in DACH-B2B-Systemen sehe. 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.
Solche Agenten baue ich für Betriebe in Südbaden und ganz Deutschland.
Schreiben Sie in zwei Sätzen, was bei Ihnen Zeit frisst – Antwort innerhalb von 24 Stunden.
Aus einem Ablauf ein System machen, das läuft
Gebaut für den Betriebsalltag, nicht als Demo.