Aus dem SchwarzwaldTechnische Ausgabe · ToolchainStand 04.08.2026
Architektur ohne Techniktheater
Vom ersten Pilot zur kontrollierten Agentenfirma.
Die Toolchain verbindet zuverlässige Kundenabläufe, interne KI-Agenten und eine klare Kontrollschicht. Sie wächst nur dann, wenn ein echter Auftrag, mehr Kunden oder ein höheres Risiko es rechtfertigen.
Das Gesamtbild
Zwei technische Welten. Ein kontrollierter Übergang.
Die interne Ebene darf analysieren und Änderungen vorbereiten. Kundenprozesse laufen getrennt davon. Erst geprüfte und freigegebene Änderungen wechseln in den produktiven Betrieb.
Control Planeintern
Arbeit vorbereiten und kontrollieren
PaperclipHermesMCPGit & CI
Recherche, Entwicklung, Tests, Diagnose, Budgets und Freigaben.
PrüfpunktReview + Tests→
Production Planekundennah
Kundenprozesse zuverlässig ausführen
n8nAPIsPostgreSQLModelle
Feste Regeln außen, begrenzte KI-Schritte innen, messbare Ergebnisse.
Die entscheidende Grenze
Agenten beobachten, untersuchen, testen und schlagen Änderungen vor. Produktive Rechte, Kundenzusagen und sensible externe Aktionen bleiben kontrolliert.
Vier Leitplanken
Die Architektur entscheidet nicht nur, was möglich ist — sondern auch, was nicht passieren darf.
Geschäft vor Werkzeug
Ein Werkzeug kommt nur dazu, wenn es Lieferzeit, Fehler, Kosten oder Risiko nachweisbar verbessert.
Klare Abläufe außen
Kundenprozesse bleiben nachvollziehbar. KI übernimmt nur die Schritte, für die Sprache oder flexible Einordnung nötig ist.
So wenig Rechte wie möglich
Jeder Dienst und jeder Agent erhält nur den Zugriff, den die konkrete Aufgabe wirklich verlangt.
Jede Änderung bleibt umkehrbar
Versionen, Tests, Sicherungen und ein manueller Ersatzweg machen Änderungen kontrollierbar.
Der vernünftige Einstieg
Zehn Bausteine reichen für den ersten echten Pilotkunden.
Die Startumgebung ist absichtlich unspektakulär. Sie kann einen vollständigen Kundenprozess ausführen, absichern, testen und wiederherstellen — ohne schon eine komplexe Agentenorganisation zu betreiben.
Wann kommen weitere Werkzeuge dazu?EintrittCaddy oder TraefikHTTPS und Routing
Ablaufn8nsichtbarer Kundenworkflow
DatenPostgreSQLverlässliche Quelle
BetriebDocker Composereproduzierbare Dienste
Ubuntu LTSTailscaleUFWGitHubresticUptime Kuma
Fundament
Server, Container und sicherer Zugang
Ein aktueller Linux-VPS trägt die erste Umgebung. Docker Compose beschreibt die Dienste reproduzierbar; ein Reverse Proxy nimmt ausschließlich verschlüsselte Webanfragen an. Verwaltungsoberflächen bleiben in einem privaten Netz.
Auswahlregel
Caddy ist der einfache Einstieg. Traefik lohnt sich, wenn viele Docker-Dienste und Subdomains dynamisch verwaltet werden. Kubernetes kommt erst dann, wenn Compose zu einem belegbaren Engpass wird.
Kundenprozesse
Nachvollziehbare Workflows außen, Agentenlogik innen
n8n hält den äußeren Geschäftsablauf sichtbar: Auslöser, Prüfungen, Datenübertragung, Freigabe und Fehlerweg. Ein Sprachmodell bekommt darin nur eine kleine, klar beschriebene Aufgabe. Langlebige oder stark verzweigte Agentenarbeit wird in einen eigenen Dienst ausgelagert.
Auswahlregel
n8n orchestriert den Prozess. LangGraph übernimmt nur komplexen Zustand und gibt strukturierte Ergebnisse über eine versionierte Schnittstelle zurück. Wiederverwendbare Fachlogik gehört in einen getesteten Microservice.
Interne AI-Company
Agenten arbeiten wie Mitarbeiter — nicht wie Administratoren
Hermes übernimmt Recherche, Entwicklung, Dokumentation, Tests und Fehleranalyse. Paperclip macht Aufgaben, Rollen, Budgets und Berichtslinien sichtbar. OpenClaw ist nur dann sinnvoll, wenn ein dauerhaftes Chat- oder Kanal-Gateway gebraucht wird.
Auswahlregel
Zu Beginn reichen Rollen und temporäre Unteragenten. Erst wenn mehrere Agenten regelmäßig parallel arbeiten, lohnt eine eigene Governance-Ebene. Kein Arbeitsagent erhält direkten Rootzugriff oder freie Produktionsrechte.
Werkzeuge & Wissen
MCP begrenzt den Zugriff. Daten bleiben in ihren Quellsystemen.
MCP stellt kleine, fachlich benannte Werkzeuge bereit, statt Agenten freie Shell-, SQL- oder API-Rechte zu geben. Langzeit-Memory hält Arbeitspräferenzen und Beziehungen; verlässliche Geschäftsdaten bleiben in PostgreSQL und freigegebenes Wissen in versionierten Dokumenten.
Auswahlregel
Ein Agent darf zum Beispiel fehlgeschlagene Ausführungen lesen oder einen Feature-Branch anlegen. Er darf nicht beliebige Befehle ausführen. Kundenspezifische Skills, Wissensbestände und Memory-Bereiche werden strikt getrennt.
Modellzugriff
Das passende Modell pro Aufgabe — nicht das stärkste Modell für alles
Klassifikation und Extraktion laufen mit kleinen, günstigen Modellen. Komplexe Planung darf ein stärkeres Modell nutzen. Ein Modellregister begrenzt Kosten, Laufzeit, erlaubte Datenklasse und Ausgabeformat je Aufgabe.
Auswahlregel
Direkte Anbieter-APIs sind für den Start am transparentesten. LiteLLM wird zum zentralen Gateway, sobald mehrere Anbieter, Kundenbudgets oder Fallbacks verwaltet werden. Lokale Modelle lohnen erst bei passender Hardware und dauerhaftem Durchsatz.
Beobachtung
Jeder Vorgang muss erklärbar, messbar und einem Kunden zuordenbar sein
OpenTelemetry verbindet technische Spuren über mehrere Dienste. Langfuse ergänzt Modell, Promptversion, Kosten und Bewertung. Klassische Metriken, Logs und Verfügbarkeitschecks zeigen, ob Infrastruktur und Kundenablauf tatsächlich gesund sind.
Auswahlregel
Rohtelemetrie läuft ohne zusätzliche KI-Kosten. Ein Modell analysiert Logs oder Vorfälle nur gezielt und innerhalb eines Budgets. Sensible Inhalte werden minimiert, maskiert oder gar nicht erst protokolliert.
Sicherheit
Rechte, Geheimnisse und Ausführung werden voneinander getrennt
API-Schlüssel gehören weder in Prompts noch in Git oder Memory. Container laufen ohne unnötige Rechte. Fremde Inhalte gelten als Daten, nicht als Anweisung. Agentengenerierter Code startet nur in einer zum Risiko passenden isolierten Umgebung.
Auswahlregel
SOPS und age reichen für den kontrollierten Start. Vault wird erst bei vielen dynamischen Geheimnissen interessant. Docker ist die Basissandbox; gVisor, E2B oder Firecracker erhöhen die Isolation stufenweise.
Lieferung & Qualität
Keine produktive Änderung ohne Version, Prüfung und Rückweg
Agenten arbeiten auf eigenen Branches. Automatische Prüfungen kontrollieren Code, Workflows, Prompts, Geheimnisse und Container. Erst nach erfolgreichem Test und menschlicher Freigabe wird produktiv ausgerollt.
Auswahlregel
GitHub ist für den kleinen Betrieb meist einfacher; Gitea bleibt die selbst gehostete Alternative. Shadow Mode und Canary führen neue Automatisierungen schrittweise ein. restic und Datenbank-Backups sichern einen tatsächlich getesteten Wiederherstellungsweg.
Rechteklassen
Autonomie steigt stufenweise. Verantwortung wird nicht delegiert.
Ein Agent beginnt mit Dokumentation und lokaler Analyse. Erst bewährte Prüfungen öffnen den Weg zu Branches, Staging und später zu einem freigegebenen Produktionsdeployment. Notfalladministration bleibt menschlich.
R0Lesen & lokal analysierenAgent
R1Telemetrie & TestsystemeAgent
R2Branch, Tests & VorschlagAgent
R3Staging ausrollenbewährter Agent
R4Produktion nach FreigabePolicy + Mensch
R5Notfalladministrationnur Mensch
Ausbau nach Auslöser
Sechs Phasen statt eines überladenen Startsystems.
Die Phasen sind keine starre Zeitplanung. Ein konkretes Geschäftssignal entscheidet über den nächsten Ausbau: erster Umsatz, mehrere Kunden, parallele Agentenarbeit oder ein tatsächlich gemessener Betriebsengpass.
Noch kein Kunde
Lokaler End-to-End-Demoablauf
n8n, PostgreSQL, Docker Compose, Testdaten, Freigabeschritt und Kostenmessung laufen lokal reproduzierbar.
Erster Umsatz
Erster zahlender Pilot
VPS, HTTPS, privater Adminzugang, Backups, Verfügbarkeitscheck und getrennte Kundenzugänge werden Pflicht.
3–5 Kunden
Wiederholbarer Kundenbetrieb
Staging, Redis, Telemetrie, Sicherheitsscans, Prompttests und standardisierte Kundenmodule begrenzen den Supportaufwand.
Parallele Agentenarbeit
Interne Agentenorganisation
Hermes, Paperclip, MCP, Honcho und ein internes Skill-System erhöhen Liefergeschwindigkeit innerhalb definierter Rechte und Budgets.
Komplexere Fälle
Kontrolliert höhere Autonomie
LangGraph, stärkere Sandboxen, tiefe Observability, automatisierte Evaluationen sowie Canary und Shadow Mode kommen hinzu.
Echter Betriebsengpass
Skalierbare Plattform
Separate Datenbanken, mehrere Worker, Hochverfügbarkeit, GPU-Inferenz oder Kubernetes werden erst anhand realer Last begründet.
Bewusste Grenzen
Was diese Architektur ausdrücklich nicht tut.
Originaldokumentation
Weiterlesen, prüfen und aktuell halten.
Werkzeuge, Lizenzen und Installationswege ändern sich. Die technische Umsetzung wird deshalb immer gegen die jeweilige Originaldokumentation geprüft. Externe Links öffnen in einem neuen Tab.
01Agenten, Orchestrierung und Kontext+
02Workflows und Infrastruktur+
03Daten und Modelle+
04Beobachtung, Sicherheit und Lieferung+
Das Zielbild