AI-Ready Platform Engineering — Plattformen, die KI-Agenten als ersten Klasse-Konsumenten behandeln.
AI-Ready Platform Engineering heißt: Eine interne Entwickler-Plattform betreibt KI-Agenten nicht als Nebenbei-Add-on, sondern als gleichrangige Konsumenten neben Menschen — mit Tool-Registry, Agent-Identitäten, Audit-Trail, Sandboxing und Cost-Controls. Die Voraussetzung dafür, dass Agenten in Ihren Workflows arbeiten, ohne dass es eskaliert.
Warum Platform Engineering jetzt eine KI-Frage ist.
Klassisches Platform Engineering baut die Plattform für menschliche Entwickler:innen — Deployment-Pipelines, Observability, Self-Service-Infrastruktur. KI-Agenten als zusätzliche Konsumenten brechen das Modell auf: Sie skalieren anders (eine Agent-Session erzeugt hunderte Operationen), sie haben andere Identitäts-Anforderungen (Agent A im Auftrag von Person B), und sie produzieren andere Risiken (versehentliches Löschen, ungewollte Kosten, Datenabfluss).
Wer das nicht plattformseitig löst, löst es in jedem einzelnen Agent-Setup wieder neu — mit dem Resultat, dass irgendwann das erste Sicherheits-Incident auftritt. Eine AI-Ready Plattform stellt Tool-Registry, Identity, Sandboxing und Audit zentral bereit; Agenten in einzelnen Teams nutzen das, statt es zu rekonstruieren.
Fünf Kernfähigkeiten einer AI-ready Plattform.
Die Bausteine, ohne die jedes Agent-Projekt zur Insellösung wird — mit allen Folgekosten.
Tool-Registry (MCP & API-Katalog)
Eine zentrale Stelle, an der jedes Werkzeug — lesend wie schreibend — beschrieben, versioniert und freigegeben ist. MCP-Tools, REST-APIs, GraphQL-Endpoints. Agenten bekommen den Katalog inklusive Permissions; Sicherheits- und Compliance-Prüfungen passieren am Katalog, nicht in jedem Agent.
Agent-Identity & Delegation
Ein Agent hat eine eigene Identität — mit eingeschränkten Berechtigungen — und handelt im Auftrag einer Person, die ihre Berechtigungen delegiert. OAuth-Flows, JWT mit Scope-Claims, OBO-Tokens. Audit-Logs zeigen: Agent X hat im Auftrag von Person Y die Operation Z ausgeführt, mit dem Scope W.
Sandboxing & Workspace-Trennung
Agenten arbeiten in Workspaces, nicht direkt auf Produktivdaten. Änderungen sind Vorschläge, die ein Mensch (oder ein anderer Agent mit Prüf-Rolle) freigibt. Für Code: kurzlebige Container, kein Cluster-Admin-Token, keine Schreibrechte auf das Host-Filesystem.
Observability für Agent-Traces
Jede Agent-Session ist nachvollziehbar: welche Tools wurden in welcher Reihenfolge aufgerufen, welche Inputs, welche Outputs, welche Modell-Versionen. OpenTelemetry-Spans mit Agent-spezifischen Attributen. Wer einen Fehler debuggen will, sieht den vollständigen Trace — nicht nur das verirrte Endergebnis.
Cost-Governance
Token-Verbrauch, Inferenz-Kosten und Cloud-Operations werden pro Agent, pro Team und pro Use-Case zugerechnet. Limits stoppen Schleifen, bevor sie eskalieren. Reports zeigen, wo Wert entsteht und wo nur Kosten. Ohne diese Schicht entstehen über Nacht vierstellige Rechnungen aus harmlosen Pilotprojekten.
Verwandte Architekturen rund um AI-Ready Platform Engineering.
Die Nachbarn, mit denen eine AI-ready Plattform typischerweise verzahnt ist — von klassischem IDP bis zu MCP-Spezifika.
Internal Developer Platform (IDP)
Backstage, Port, eigene Self-Service-Layer — die klassische IDP ist der ideale Ort, an dem die AI-Ready-Bausteine andocken. Tool-Registry, Identity-Provider und Cost-Reports sitzen idealerweise schon dort und werden für Agent-Konsumenten erweitert.
MCP (Model Context Protocol)
Der werdende Standard, über den Agenten mit Werkzeugen sprechen. Eine AI-ready Plattform exponiert ihre Tools über MCP, mit klarer Authentifizierung und Permissions — statt jedem Agent-Framework eigene Adapter zu liefern.
Kubernetes & Container Sandboxing
Kubernetes liefert die Bausteine für Agent-Sandboxes: kurzlebige Pods mit minimalen Berechtigungen, NetworkPolicies, RBAC-Beschränkung pro Namespace, eingebaute Quotas. Agenten, die Code ausführen, laufen dort — nie auf einem geteilten Host.
DevSecOps
AI-Ready Platform Engineering ist DevSecOps mit einem zusätzlichen Konsumenten. Supply-Chain-Security (signierte Container, SBOM), Secret-Management und Provenance werden für Agent-Operationen ebenso wichtig wie für menschliche Commits.
Content Provenance & Audit
Wenn Agenten Inhalte erzeugen oder ändern, muss das nachvollziehbar dokumentiert sein. Ed25519-Signaturen, getrennte Audit-Logs für Mensch- und Agent-Operationen, EU-AI-Act-konforme Provenance-Metadaten direkt am Inhalt.
Verwandte Open-Source-Pakete für AI-ready Plattformen.
Die OSS-Bausteine aus unserem Stack, die direkt Plattform-Fähigkeiten für Agent-Use-Cases umsetzen — MCP, Workflows, Vector-Store, Provenance.
webmcp
Web Model Context Protocol — Tool-Registration für Browser-Agents. Die Schnittstelle, über die KI-Agenten zentral verwaltete Werkzeuge sicher aufrufen.
ai-workflows
Agentic Workflow-Engine mit Steps, Expressions und Blocking/Resume — strukturierte Orchestrierung statt freilaufender Agent-Loops, mit Audit-Trail per Default.
business-agent
RAG-Pipeline mit Vector-Store, Access-Klassen und Web-Chat — die Plattform-Basis für Agenten, die auf realen Unternehmens-Inhalten antworten.
content-provenance
Ed25519-Signaturen, Audit-Trail, Verifikations-API — macht jede von einem Agenten ausgelöste Inhaltsänderung nachvollziehbar und EU-AI-Act-konform.
typo3-config
Fluent Config-API für TLS/mTLS, Secrets und Logging — die Bausteine, ohne die Agent-Identitäten und sichere Tool-Aufrufe nicht sauber lösbar sind.
Aus dem Blog
Beiträge zu Plattform-Engineering, KI-Agenten und Sicherheits-Defaults
Häufige Fragen zu AI-Ready Platform Engineering.
Die Fragen, die in technischen Erstgesprächen rund um Agent-Plattformen immer kommen.
Brauchen wir eine eigene Plattform dafür — oder reicht Cursor/Copilot?+
Für eine Hand voll Entwickler:innen, die KI als Tipp-Hilfe nutzen, reicht ein Editor-Plug-in. Sobald Agenten an Produktivsystemen schreiben, Tickets schließen, Code in main-Branches mergen oder Daten verändern, braucht es eine Plattform-Sicht: Identität, Permissions, Audit, Sandbox. Sonst entstehen punktuelle Lösungen, die niemand mehr überblickt.
Welche Risiken adressiert eine AI-ready Plattform konkret?+
Versehentliches Löschen von Produktivdaten, ungewollte Cloud-Kosten durch Agent-Schleifen, Datenabfluss über unbedachte Tool-Aufrufe, fehlende Nachvollziehbarkeit bei Vorfällen, Prompt-Injection über kontaminierte Inputs. Alle fünf werden gelöst an der Plattform, nicht im einzelnen Agent.
Wie passt das zu unserem bestehenden DevSecOps-Setup?+
AI-Ready Platform Engineering ist eine Erweiterung, kein Ersatz. Bestehende DevSecOps-Bausteine (SBOM, Container-Signaturen, Secret-Scanning) werden um Agent-spezifische Aspekte ergänzt: Agent-Identitäten, Tool-Permissions, Trace-Analyse, Cost-Quotas. Wer DevSecOps schon sauber betreibt, hat die halbe Plattform.
Wie sieht ein realistischer erster Schritt aus?+
Ein konkreter Use Case (z.B. Tickets klassifizieren, Test-Daten erzeugen, Code-Reviews unterstützen), dafür eine saubere Plattform-Baseline: Tool-Registry mit drei Tools, Agent-Identität mit eingeschränktem Scope, Audit-Trail, Cost-Limit. Daraus lässt sich der zweite und dritte Use Case in einem Bruchteil der Zeit aufsetzen.
Lässt sich das mit europäischen oder On-Prem-Modellen betreiben?+
Ja. Die Plattform-Schicht — Tool-Registry, Identity, Audit, Cost — ist modellunabhängig. Inferenz läuft je nach Use Case auf US-APIs, europäischen Anbietern oder lokal (Llama-, Mistral- und vergleichbare Modelle). Wer Modelle hinter einem Abstraktions-Layer kapselt, kann den Anbieter später wechseln, ohne die Plattform neu zu bauen.
Wie startet ein Projekt mit Moselwal?+
Erstgespräch zu vorhandener Plattform, geplanten Agent-Use-Cases und Risiko-Toleranz. Daraus eine konkrete Plattform-Skizze mit den fünf Bausteinen — priorisiert nach Use Case. Umsetzung iterativ: erst der eine Use Case, dann die nächsten zwei auf derselben Baseline.
Wie ready ist Ihre Plattform für den ersten produktiven Agent-Use-Case?
Erstgespräch zu vorhandenem Platform-Stack und konkretem Pilot-Use-Case — mit Plattform-Skizze als Ergebnis.
Antwort innerhalb von zwei Werktagen.