Über mich Portfolio Referenzen Leistungen Blog Kontakt 🎙 Mit KI sprechen
EN DE RU
🎙 Mit KI sprechen
November 11, 2026 · 5 min read

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

Denis Shokhirev
Denis Shokhirev
Agentic AI Systems Architect
Telegram LinkedIn

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

SymptomUrsacheAbhilfe
Aufgabe scheitert nach einem API-FehlerKeine WiederholungslogikTeilschritte in Schleifen mit begrenzten Versuchen ausführen
Menschen geben triviale Schritte freiKeine RisikoklassifizierungSichere, prüfpflichtige und gesperrte Aktionen trennen
Fortschritt geht nach Neustart verlorenZustand nur im ArbeitsspeicherZustand in Postgres oder Supabase speichern
Niemand weiß, warum die Aufgabe anhältKein EreignisprotokollStatuswechsel 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.

AktionEigenständigMenschliche Prüfung
Interne APIs lesenJaNur bei Zugriffsfehlern
Eingehende Anfragen klassifizierenJa, mit ProtokollierungBei niedriger Sicherheit
Kundenantwort entwerfenJaBei rechtlichen oder vertraglichen Formulierungen
Postgres-Datensätze ändernJa, über SQL-PositivlisteBei Massenänderungen
Zahlungen, Verträge, Löschung von DatenNeinImmer

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.

Für Ihren Betrieb

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.

KI-Agenten entwickeln lassen →
Weiterlesen
Ihr KI-Agent halluziniert weiter und beschädigt das Repository? So geben Sie Claude Code Gedächtnis, Datenzugriff und sichere Leitplanken
Warum ein Agent nicht mehr ausreicht: Claude Code, Codex und Kiro ohne tmux-Chaos orchestrieren
Claude Code kann im Produktivbetrieb in Slack, WordPress und .env auslaufen: 10 Guardrails vor dem ersten Start
Geben Sie KI-Agenten keine Produktionsschlüssel: neue Control Planes und Freigabe-Gates für nicht rückgängig zu machende Aktionen
Alle Artikel →
Wo das im Betrieb ankommt
KI-Telefonassistent — Anrufe annehmen, wenn niemand kann
KI-Automatisierung für Betriebe in Freiburg und der Ortenau
KI-Agentur in Freiburg — gebaut statt weiterverkauft
KI-Telefonassistent fürs Handwerk — Notfälle erkennen, Aufträge sichern
DSGVO-konforme KI — was das praktisch bedeutet
Bereit für den nächsten Schritt?

Aus einem Ablauf ein System machen, das läuft

Gebaut für den Betriebsalltag, nicht als Demo.

Projekt anfragen → ← Alle Artikel