Warum Ihre KI-Agenten nicht skalieren: Lokale Speicher- und Orchestrierungsmuster mit OpenHuman

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau. Mein Stack: Claude, Supabase, n8n, Doppler und selbst gehostetes Postgres. Bei DennisCraft AI Studio liefere ich produktive Agenten-KI-Systeme für DACH-B2B-Kunden aus. Die Realität: Die meisten KI-Agenten-Demos scheitern beim Übergang in den Produktivbetrieb – Skalierbarkeit und Compliance brechen, sobald echte Nutzer und Regulatorik ins Spiel kommen. OpenHuman (live einsehbar unter live.gerdennisai.com) bleibt nur deshalb stabil, weil ich auf lokale Speicher- und Orchestrierungsmuster setze – ganz ohne Cloud-Vendor-Lock-in.

Das Skalierungsproblem: Warum Cloud-Konzepte im Produktivbetrieb versagen

In den letzten Monaten habe ich wiederholt beobachtet: KI-Agenten, die auf Cloud-Speicher oder -Orchestrierung setzen, stoßen bei echten Nutzern und Auditierung an harte Grenzen. Latenz explodiert, Kosten steigen, und die Datenschutzabteilung blockiert die Einführung. Insbesondere in regulierten Branchen (Finanz, Logistik, Industrie) sind Cloud-basierte Speicherlösungen wegen DSGVO und BSI Grundschutz oft von vornherein ausgeschlossen. In zwei Projekten musste ich SaaS-Vektordatenbanken entfernen, weil sie den Audit nicht bestanden haben.

Typisches Muster: Zentrale Cloud-Speicherung

Frameworks wie LangChain oder AutoGen speichern Agenten-Memory meist in einer externen Vektordatenbank oder via Managed API. Jeder Agenten-Schritt erzeugt einen Netzwerk-Request – langsam, teuer und aus Sicht der Compliance riskant. Die Anthropic Claude-Dokumentation (2023, Link) bestätigt: „Externes State-Management erweitert die Angriffsfläche und erschwert das Audit.“ In 3 von 4 produktiven Kundenprojekten wurde ich gezwungen, das Speicher-Layer auf selbst gehostetes Postgres umzustellen.

Lokaler Speicher: Das Muster für produktive Agenten

Was im Produktivbetrieb tatsächlich funktioniert: Jeder Agent schreibt sein Gedächtnis (Kontext, Task-Logs, Embeddings) lokal in eine Postgres-Tabelle. Für schnelle Ähnlichkeitssuche nutze ich pgvector, für Nachvollziehbarkeit die integrierte Volltextsuche. Die Vorteile:

• Vorhersehbare, niedrige Latenz (1–5ms im internen Netz statt 100ms+ über Cloud)
• Vollständige Auditierbarkeit (Postgres-Trigger + Supabase Policies, erfüllt DSGVO/ISO 27001)
• Klare Perimeterkontrolle: Keine Daten verlassen das eigene VPC, keine Drittanbieter-APIs

Codebeispiel: Lokaler Agenten-Speicher in Python

import psycopg2
from pgvector.psycopg2 import register_vector

conn = psycopg2.connect(dbname="agentdb", user="postgres", password="***")
register_vector(conn)

def save_agent_memory(agent_id, embedding, content):
    with conn.cursor() as cur:
        cur.execute(
            "INSERT INTO agent_memory (agent_id, embedding, content) VALUES (%s, %s, %s)",
            (agent_id, embedding, content)
        )
    conn.commit()

def search_memory(agent_id, query_embedding):
    with conn.cursor() as cur:
        cur.execute(
            "SELECT content FROM agent_memory WHERE agent_id=%s ORDER BY embedding <-> %s LIMIT 5",
            (agent_id, query_embedding)
        )
        return cur.fetchall()

Orchestrierung ohne Cloud: n8n, Supabase und Doppler

In OpenHuman verzichte ich bewusst auf zentrale Orchestrierungstools (z.B. Temporal) und Cloud-Taskrunner. Die Architektur: n8n als Workflow-Engine im Docker, Supabase (Postgres + Storage) und Doppler für Secrets – alles im isolierten VPC. Ergebnis: Nachvollziehbarkeit, Rückrollbarkeit und keine Vendor-Abhängigkeit.

n8n Workflow-Beispiel

nodes:
  - id: 1
    type: webhook
    parameters:
      path: /agent/task
  - id: 2
    type: postgres
    parameters:
      query: SELECT * FROM agent_tasks WHERE status='pending'
  - id: 3
    type: httpRequest
    parameters:
      url: http://localhost:8080/agent/execute
      method: POST
connections:
  - from: 1
    to: 2
  - from: 2
    to: 3

OpenHuman: Messbare Ergebnisse aus dem Produktivbetrieb

OpenHuman ist ein produktiver, öffentlich einsehbarer Agenten-Stack. Es laufen 5–10 spezialisierte Agenten (Antragsbearbeitung, Datensammlung, Validierung), die ihre Memory ausschließlich in lokalem Postgres speichern. Keine SaaS-Vektordatenbanken, keine externen APIs. Unter 500+ Requests/min liegt die Lese-Latenz bei 3–7 ms. Jede Aktion wird via Postgres-Trigger und supabase audit extension geloggt. Fehlerhafte Agentenstates lassen sich per SQL sofort zurücksetzen.

Das bringt Ihnen im Alltag

• Sofortige Rollbacks: Memory per SQL zurücksetzen, wenn ein Agent „hängt“
• Compliance-Audit: Vollständige Aktionslogs für DSGVO, ISO 27001, BSI Grundschutz
• Keine versteckten Cloud-Abhängigkeiten – alles on-premises, voll isoliert

FAQ

Können Sie komplett auf Cloud verzichten?

Für Agenten-Memory und Orchestrierung: ja. Für LLM-Inferenz (z.B. Claude/OpenAI) sind Cloud-Endpunkte nötig, aber sämtlicher State bleibt lokal.

Wie aufwendig ist die Migration auf lokalen Speicher?

Mit bestehendem Postgres ist pgvector und Audit-Trigger in 1–2 Tagen integriert. In der Praxis habe ich das für einen FinTech-Kunden in 12 Stunden umgesetzt.

Wie sieht es mit Sicherheit aus?

Supabase Policies und Postgres-Trigger erlauben exakte Zugriffskontrolle und lückenlosen Audit. Damit ist der Stack auditierbar nach DSGVO, ISO 27001 und BSI Grundschutz.

Wie wird das Monitoring gehandhabt?

Alle Logs und Memory bleiben im lokalen Postgres. Dashboards können über Grafana oder Supabase Realtime gebaut werden.

Was ist der Vorteil gegenüber Cloud?

10–30x niedrigere Latenz, keine Vendor-Abhängigkeit, sofortiger Compliance-Audit. Gerade in Finanz, Healthcare und Industrie entscheidend.

An welcher Stelle wird Ihr Agenten-Stack im Produktivbetrieb zum Flaschenhals: Latenz, Audit, Kosten, DSGVO? Mich interessiert, wo es am häufigsten bricht. Ich biete einen kostenlosen 30-minütigen Stack-Audit für DACH-Teams im regulierten KI-Umfeld. Schreiben Sie mir auf LinkedIn oder an @ger_dennis_ai.