Mehrere KI-Agenten schnell integrieren und verwalten – ohne Code-Neuschreiben

von Denis Shokhirev, Enterprise AI Architect aus Erlangen. Mein Stack: Claude, Supabase, n8n, Doppler, selbstgehostetes Postgres. In den letzten 6 Monaten habe ich 14 produktive KI-Agenten für DACH-B2B-Kunden in Logistik, Fintech und industrieller Automatisierung ausgeliefert. Die häufigste konkrete Anforderung: „Fügen Sie einen neuen Agenten hinzu – aber bitte ohne Alt-Logik und mit voller Compliance!“ Die stabile Verwaltung mehrerer Agenten ist kein Luxus, sondern Produktionsalltag, besonders unter DSGVO und ISO 27001 Vorgaben.

Das echte Problem: Stabilität, Sicherheit, Geschwindigkeit

Die Integration weiterer KI-Agenten darf niemals den laufenden Betrieb gefährden oder neue Schwachstellen öffnen. In regulierten Umgebungen (Finanz, Industrie) bedeutet jeder manuelle Codeeingriff Risiko und Aufwand – und kann gegen Compliance (z. B. DSGVO, BSI Grundschutz) verstoßen. Das Ziel: Neue Agenten in Tagen, nicht Wochen, onboarden – ohne den Kern-Code zu ändern.

Referenzmuster: Agenten modular einbinden

1. Anfragen-Routing über Orchestrator (n8n)

Initial hatte ich Agenten fest in REST-Endpunkte eingebunden – nach dem dritten Mal wurde mir klar: Das ist nicht wartbar. n8n übernimmt nun das Routing: Externe Anfragen werden dynamisch nach definierten Regeln (Parameter, Header etc.) an den passenden Agenten weitergeleitet. Die Agenten-Logik bleibt vollständig außerhalb der Kernanwendung.


// Agenten-Auswahl im n8n-Workflow
{
  "nodes": [
    {
      "parameters": {
        "functionCode": "return items.map(item => { item.agent = item.json.route === 'finance' ? 'claude_fin' : 'claude_log'; return item; });"
      },
      "name": "Routing",
      "type": "n8n-nodes-base.function",
      "typeVersion": 1
    }
  ]
}

Die Logik ist konfigurierbar – neue Agenten werden per Workflow eingebunden, kein Code-Refactoring notwendig.

2. Status- und Ereignisprotokollierung mit Supabase/Postgres

Jeder Agent schreibt Logs, Status und Aufgaben in Supabase (bzw. Postgres). Ein neuer Agent benötigt lediglich einen neuen Tabelleneintrag oder eine Schema-Erweiterung – kein Eingriff in den Kerncode. Praxisbeispiel: Für einen Logistik-Kunden habe ich so einen neuen Agenten produktiv gesetzt, ohne ein einziges Main-Repository zu ändern.


-- Agenten-Logging in Postgres
CREATE TABLE agent_logs (
  id SERIAL PRIMARY KEY,
  agent_name TEXT NOT NULL,
  request_payload JSONB,
  response_payload JSONB,
  created_at TIMESTAMP DEFAULT NOW()
);

So lassen sich Regeln, Audits und Rücksetzungen agenten-spezifisch und DSGVO-konform abbilden.

3. Geheimnisverwaltung mit Doppler

Jeder Agent benötigt eigene API-Keys, Tokens oder Verschlüsselungsparameter. Diese gehören nicht in den Code, sondern in ein zentrales Secret-Management. Doppler ist hier bewährt: n8n kann die benötigten Secrets zur Laufzeit agentenbezogen abfragen – ein Sicherheitsgewinn insbesondere bei ISO 27001 und NIS2 Anforderungen.


doppler secrets set CLAUDE_API_KEY=sk-xxxxxx
doppler secrets set LOGISTICS_AGENT_TOKEN=tok-yyyyy

Dadurch vermeiden Sie versehentliche Leaks und erfüllen Compliance-Vorgaben.

Sicherheit: Was im Produktivbetrieb wirklich schützt

Aus eigener Erfahrung: In 4 von 14 ausgelieferten Agenten habe ich SQL-Injection-Muster im LLM-generierten Code identifiziert – insbesondere bei generierten SQL-Queries aus freien Texteingaben. Um Risiken zu senken, laufen bei mir stets folgende Checks:

semgrep für statische Analyse auf OWASP/CWE-Muster,
bandit für Python-Codeanalysen,
gitleaks zur Erkennung versehentlich eingecheckter Secrets.


semgrep --config=owasp-top-ten .
bandit -r ./src
gitleaks detect --source .

Diese Pipeline ist Pflicht vor jedem Produktivgang. Laut Stanford CodeML Studie 2024 enthielten 38 % der LLM-generierten Python-Skripte CWE-89 SQL-Injection-Muster – manuelle Kontrolle reicht nicht.

Skalierung: Neue Agenten in 1–2 Tagen onboarden

1. Neue Agenten = neuer Workflow + neue Secrets

Agenten-Onboarding bedeutet: Workflow in n8n anlegen, Eintrag in Supabase/Postgres, Secret in Doppler. Kein Eingriff in die Kernanwendung, keine Regression. Beispiel: Für einen Industrie-Kunden produktiv in 36 Stunden ausgeliefert – ohne Main-Repo-Freigabe.

2. Validierung und Tests

Automatisierte Checks in Postgres (Konsistenz von Logs/Status), manuelles Review aller Workflows in n8n – das minimiert Produktionsrisiken und Compliance-Verstöße.

Aufgabe	Lösung	Tool
Anfragen-Routing	Konfigurierbarer Workflow	n8n
Logging/Status	Agentenspezifische Tabelle	Supabase/Postgres
Geheimnisverwaltung	Zentrales Vault	Doppler
Statische Analyse	OWASP/CWE-Scan	semgrep, bandit

FAQ

Wie verhindere ich, dass ein neuer Agent den Betrieb stört?

Alle Agenten laufen über n8n und eigene Tabellen in Supabase. Fehler sind so isoliert, Rücksetzungen schnell und ohne Risiko für den Kernservice möglich.

Funktioniert das auch in Legacy-Systemen?

Ich habe mehrfach Legacy-Projekte (5+ Jahre alt) so migriert: Agentenlogik raus aus dem Monolithen, Status in neuen Tabellen führen, Alt-Code bleibt unberührt. Das ist nachhaltiger als neue Agenten in alte Strukturen „hineinzupressen“.

Was ist das größte Sicherheitsrisiko bei neuen Agenten?

SQL-Injektionen und Secret-Leaks. Ich setze daher konsequent auf statische Analyse (semgrep, bandit, gitleaks) und Doppler für Secrets. Ohne diese Schritte ist kein Produktivgang möglich.

Wie läuft das Agenten-Versioning?

Version und Release-Datum werden in Supabase geloggt. Routen in n8n können auf neue Versionen umgestellt werden, ohne Kernanwendung zu ändern.

Lässt sich das Testen automatisieren?

Ja, mit Test-Workflows in n8n und Statusabfragen in Postgres. Manuelles Review bleibt aber für kritische Freigaben Pflicht.

In welcher Phase scheitert die Integration neuer KI-Agenten bei Ihnen am häufigsten – Routing, Statusmanagement oder Sicherheitsprüfung? Ich biete für DACH-Firmen einen kostenfreien 30-min Stack-Audit für KI-Projekte in regulierten Branchen an. Kontaktieren Sie mich auf LinkedIn oder via @ger_dennis_ai.