Unser AI-Stack in der Praxis.
Keine Marketing-Version. Der echte Stack hinter 120.000 Nutzern und 50+ AI-Modellen in Produktion.
Hier ist unser Stack, Stand März 2026. Keine Marketing-Version. Die echte.
Warum Provider-Agnostik nicht optional ist
Unser Stack beginnt mit einer Grundentscheidung, die wir Ende 2023 bei SiemensGPT getroffen haben: Kein Lock-in an einen einzelnen AI-Provider.
Die Begründung war damals architektonisch. Heute ist sie existenziell. In 18 Monaten hat sich die Modelllandschaft dreimal fundamental verändert. GPT-4 war dominant, dann kam Claude und war für bestimmte Aufgaben besser. Dann Open-Source-Modelle, die Enterprise-Niveau erreichten. Dann multimodale Modelle. Dann Reasoning-Modelle.
Wer sich 2023 an OpenAI gebunden hat, hatte 2024 ein Problem. Wer sich 2024 an Anthropic gebunden hat, verpasst 2026 die Vorteile von Gemini für bestimmte Workloads.
Unsere Lösung: LiteLLM als Abstraktionsschicht. Ein einheitliches Interface für alle Provider. Claude, GPT, Gemini, LLaMA, Mistral. Modellwechsel in der Konfiguration, nicht im Code. Neue Provider in Stunden integriert, nicht in Wochen.
Das hat einen Preis: Wir können nicht jedes Provider-spezifische Feature sofort nutzen. Aber der Preis ist deutlich niedriger als ein Rewrite, wenn sich der Markt verschiebt.
Die Schichten unseres Stacks
Schicht 1: Foundation Models
Wir betreiben aktuell Modelle von fünf Providern in Produktion:
| Provider | Modelle | Einsatzbereich |
|---|---|---|
| Anthropic | Claude Opus, Sonnet, Haiku | Komplexe Reasoning-Tasks, Code-Generierung, Analyse |
| OpenAI | GPT-4o, o1 | Multimodale Aufgaben, Rückwärtskompatibilität |
| Gemini Pro, Flash | Lange Kontexte, multimodale Verarbeitung | |
| Meta | LLaMA 3 | Self-Hosted für daten-sensitive Workloads |
| AWS | Bedrock (alle Provider) | Managed Inference, Enterprise-Compliance |
Die Modellwahl ist kein Glaubenskrieg. Es ist eine Engineering-Entscheidung. Claude ist besser für komplexe Reasoning-Tasks. Gemini ist besser für sehr lange Dokumente. LLaMA ist besser, wenn Daten das Unternehmen nicht verlassen dürfen. Wir wählen pro Aufgabe, nicht pro Projekt.
Schicht 2: Agent Framework
Agents sind keine Chatbots mit Tools. Agents sind Software-Systeme, die eigenständig Aufgaben ausführen, Entscheidungen treffen und mit anderen Systemen interagieren.
Unser Agent Framework basiert auf drei Prinzipien:
Tool-Based Architecture. Jeder Agent hat eine definierte Menge an Tools (API-Aufrufe, Datenbankzugriffe, Code-Ausführung). Die Tools definieren, was der Agent kann. Das LLM entscheidet, wann und wie es sie nutzt.
Guardrails, nicht Hoffnung. Jeder Agent hat definierte Grenzen: Maximale Ausführungszeit, Budget-Limits pro Aufruf, Whitelist für erlaubte Aktionen. Kein Agent kann eigenständig Ressourcen löschen oder Daten an externe Services senden, es sei denn, es ist explizit erlaubt.
Observability by Default. Jeder Agent-Aufruf wird geloggt: Input, Reasoning-Schritte, Tool-Aufrufe, Output. Nicht für Debugging. Für Nachvollziehbarkeit. Enterprise-Kunden brauchen Audit-Trails. Wir liefern sie.
Frameworks, die wir nutzen: LangGraph für komplexe Workflows, Google ADK für Agent-zu-Agent-Kommunikation, Microsoft Agent Framework für bestimmte Enterprise-Integrationen. Kein einzelnes Framework für alles, sondern das richtige Tool für die richtige Aufgabe.
Schicht 3: Orchestrierung
Ein einzelner Agent löst ein einzelnes Problem. Produktive Enterprise-Systeme brauchen Orchestrierung: Agents, die andere Agents aufrufen. Workflows, die je nach Ergebnis verzweigen. Fallback-Logik, wenn ein Agent scheitert.
Unsere Orchestrierung läuft auf AWS Step Functions. Jeder Workflow ist ein State Machine. Visuell nachvollziehbar, testbar, versioniert.
Beispiel HR Data Hub: Ein Nutzer beschreibt im Self-Service Data Shop das gewünschte Datenformat. Der Orchestrator startet einen Data Transform Agent, der Python-Code generiert. Der Code wird in einer Sandbox getestet. Wenn die Tests bestehen, wird er als Lambda deployt. Automatisch. Kein Mensch involviert.
Schicht 4: Infrastruktur
Alles läuft auf AWS. Nicht aus Prinzip, sondern weil unsere Enterprise-Kunden AWS nutzen und Compliance-Anforderungen haben, die On-Premise oder Multi-Cloud nicht einfacher machen.
| Komponente | Service | Warum |
|---|---|---|
| Agent-Runtime | Fargate / Lambda | Serverless, skaliert automatisch, Pay-per-Use |
| Workflow Engine | Step Functions | State Machines, visuelles Debugging |
| Datenspeicher | S3, DynamoDB | Serverless, Event-driven |
| Monitoring | CloudWatch + Custom Agents | Self-Healing (Agent analysiert Logs) |
| Security | IAM, KMS, VPC | Enterprise-Standard, Cross-Account |
| CI/CD | CDK, GitHub Actions | Infrastructure as Code |
Schicht 5: Self-Healing
Die Schicht, die alles zusammenhält: Agents, die andere Agents überwachen.
Unser AWS Architect Agent überwacht CloudWatch-Logs aller laufenden Services. Erkennt Anomalien (Latenz-Spikes, Fehlerquoten, ungewöhnliche Zugriffsmuster). Erstellt Root-Cause-Analysen. Postet die Ergebnisse in Slack. Einfache Probleme (Timeout wegen Cold Start, temporärer Rate Limit) behebt er eigenständig.
Das ist kein Monitoring-Dashboard mit Alert-Regeln. Es ist ein AI Agent, der Logs liest, versteht und handelt. Der Unterschied: Regeln erkennen bekannte Probleme. Agents erkennen unbekannte Probleme.
Was das für Kundenprojekte bedeutet
Wir entwickeln diesen Stack nicht nur für uns. Wir entwickeln ihn für und mit unseren Kunden.
Bei SiemensGPT läuft der gesamte Stack in der Siemens-AWS-Umgebung. Provider-agnostisch, Self-Healing, 50 Modelle, 10.000+ Agents. Die Siemens-Engineers arbeiten täglich mit diesem Stack. Er gehört ihnen.
Bei der Siemens Energy AI Platform haben wir den Stack als Self-Service-Plattform implementiert. Teams erstellen eigene Agents, wählen Modelle, definieren Tools. Ohne FNTIO-Beteiligung. Forward-Deployed Engineering heißt: Wir zeigen, wie es geht, dann machen die Teams es selbst.
Das ist der Unterschied zwischen einem Stack, den man kauft, und einem Stack, den man versteht.
Jannik Frisch hat als Technical Advisor den Provider-agnostischen AI-Stack entworfen, der 50+ Modelle und tausende Agents in Enterprise-Produktion betreibt.
Profil ansehen →