Eigener KI-Agenten-Marktplatz für Codex, Claude, Copilot: Was 2026 im Produktivbetrieb wirklich funktioniert

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau. Für DACH-B2B-Kunden betreibe ich produktive Multi-Agenten-Systeme auf Basis von Claude, Supabase, n8n, Doppler und selbst gehostetem Postgres. Im Frühjahr musste ich einen laufenden Agenten (Copilot) kurzfristig isolieren, weil er SQL mit klassischen CWE-89-Mustern generierte – nicht im Demo, sondern live im Produktivbetrieb (siehe live.gerdennisai.com). Im Jahr 2026 bedeutet ein KI-Agenten-Marktplatz im Unternehmen: Sicherheitsprüfung, Orchestrierung und Nachvollziehbarkeit, nicht nur „schicke“ APIs.

Marktplatz-Architektur: Was ist ein produktiver Agenten-Marktplatz?

Im Praxisbetrieb ist ein Agenten-Marktplatz keine Klick-Oberfläche, sondern eine Plattform, auf der mehrere LLM-Agenten (z.B. Codex, Claude Code, Copilot) für Geschäftsanwendungen als Services bereitstehen. Entscheidend ist: dynamisches Routing, Auditierbarkeit, stabile Fallback-Mechanismen. Ohne diese bleibt der Marktplatz ein Demo.

Technische Komponenten im Vergleich

In der Produktivarchitektur werden Agenten per Orchestrierung (n8n) ereignisbasiert angesteuert, alle Requests und Antworten landen persistent in Postgres (via Supabase). Secrets werden ausschließlich über Doppler verwaltet, niemals als Umgebungsvariablen im Server-File.

Sicherheitsprüfung: Was findet echte Schwachstellen?

Die Stanford CodeML-Studie von 2024 zeigte: 38% von LLM-generiertem Python-Code enthalten CWE-89-Patterns (SQL-Injektionen), Quelle: arxiv.org/abs/2401.09958. In mehreren Kundenprojekten entdeckte ich in den ersten 24 Stunden SQL-Injections und Credential-Leaks mit semgrep und bandit – trotz Unit-Tests.

Produktiver Static-Analysis-Workflow

import subprocess

def run_semgrep(file_path):
    result = subprocess.run(
        ["semgrep", "--config", "p/ci", file_path],
        capture_output=True, text=True
    )
    return result.stdout

def run_bandit(file_path):
    result = subprocess.run(
        ["bandit", "-r", file_path],
        capture_output=True, text=True
    )
    return result.stdout

def main():
    code_file = "agent_job.py"
    print(run_semgrep(code_file))
    print(run_bandit(code_file))

Jeder vom Agenten generierte Code wird vor Ausführung durch diesen Pipeline geschickt. Bei Findings durch bandit oder semgrep wird der Task blockiert und manuell geprüft. Ohne diese Stufe ist kein produktiver Betrieb DSGVO-konform möglich.

Orchestrierung und Fallback: Ausfallsicherheit im Betrieb

n8n als zentrale Task-Schicht

n8n steuert alle Aufgaben (z.B. „Vertrag prüfen“, „SQL generieren“) workflowbasiert, Agenten sind eigenständige Nodes. Bei Fehlern erfolgt automatisches Fallback auf andere Agenten oder Incident-Alert (z.B. Slack), alles lückenlos protokolliert.

# n8n Workflow-Snippet
- node: Claude_Code
  action: process_contract
  onError:
    - node: Copilot
      action: retry
    - node: Notify
      channel: slack
      message: "Fehler bei Claude_Code"

Zentrale Anforderung: Alle Inputs, Outputs und Metadaten der Agenten-Calls müssen in Postgres (über Supabase) gespeichert werden. Nur so ist Nachvollziehbarkeit im Audit (z.B. nach BSI Grundschutz, DSGVO) gewährleistet.

Audit, Logging und Compliance: Was Kunden wirklich verlangen

Im DACH-Markt, spätestens durch die EU AI Act und DSGVO, fordern Unternehmen: Audit Trails für 6–12 Monate, Zugriffstrennung bei Tokens, keine Klartext-Secrets. Supabase mit Row-Level-Security und Verbindungsprotokollierung bietet das technisch, sofern konsequent genutzt.

Beispiel Row-Level Security

-- Zugriff auf Logs auf User einschränken
CREATE POLICY user_logs_policy
ON logs
FOR SELECT
USING (user_id = current_setting('app.current_user')::uuid);

In einem Projekt hätte ein falsch konfigurierter Supabase-Endpoint beinahe alle Agenten-Logs offengelegt. Row-Level Security ist für B2B Pflicht, nicht Kür.

Agenten-Qualität: Unterschiede und Bewertung

Jeder Agent (Claude, Copilot, Codex) hat spezielle Stärken, aber auch typische Schwächen. Die Static-Analysis-Pipeline muss einheitlich, aber agentenspezifisch konfigurierbar sein. Beispiel: Claude Code generiert oft ausführlicheren Code, der Standard-semgrep-Regeln unterläuft – hier braucht es Feintuning.

FAQ

Sollten Agenten als ein API oder orchestriert bereitgestellt werden?

Orchestrierung (n8n, Airflow) erlaubt Skalierung, Monitoring und Austausch einzelner Agenten ohne Kopplung. Ein monolithisches API erhöht Risiko und Wartungsaufwand.

Wie sieht ein schneller Fallback aus?

Parallele Anfragen an 2–3 Agenten mit Auswahl des ersten gültigen Ergebnisses reduziert Latenz, erhöht aber API-Auslastung. Reihenfolge-Fallback ist günstiger, aber langsamer.

Wie prüfe ich Codequalität der Agenten?

Statische Analyse (semgrep, bandit) für alle Agenten zwingend, mit agentenspezifischen Regeln und Schwellenwerten.

Was ist das größte Risiko beim Token-Handling?

Leaks über Logs oder falsch konfigurierte Endpunkte. Doppler und Row-Level Security in Supabase reduzieren das Risiko signifikant.

Wie automatisiere ich das Audit?

Logs in Supabase, monatlicher Export in Audit-Tabellen, n8n-basierte Alerts bei Auffälligkeiten. Manuelle Kontrolle reicht nicht aus.

In welchem Schritt Ihrer LLM-Pipeline werden im Produktivbetrieb die meisten Fehler entdeckt – statische Analyse, Laufzeitsandbox oder manuelle Prüfung? Das interessiert mich wirklich. Ich biete einen kostenlosen 30-min Stack-Check für DACH-Entscheider mit KI-Projekten in regulierten Branchen. Kontaktieren Sie mich auf LinkedIn oder unter @ger_dennis_ai.