Du hast einen Agent gebaut. Auf deinem Laptop getestet. Lief — sogar richtig gut. Also hast du ihn live geschoben wie man 2003 Websites deployed hat: Datei auf dem Server bearbeiten, speichern, beten.

Dann, um 2 Uhr nachts, fängt dein Agent an, Tool Calls zu halluzinieren, E-Mails an Leute zu schicken, die nie danach gefragt haben, und dein API-Budget zu verballern wie ein Matrose auf Landgang. Du greifst nach dem Rollback-Button. Es gibt keinen Rollback-Button. Es gibt keine vorherige Version. Dein Agent hat keine Versionen — er ist ein System Prompt in einem Textfeld, eine Handvoll Tool-Konfigurationen und das, was in deinem Kopf rumschwirrt.

Willkommen beim Agent-Deployment im April 2026.

Die Plattformen sind da. Die Pipelines nicht.

Zwischen dem 8. und 22. April haben die drei Hyperscaler ihre Agent-Plattformen im Schnelldurchlauf rausgehauen: Anthropics Managed Agents (8. April) mit gehosteten Sandboxes und einer ant-CLI, OpenAIs Agents SDK v0.14 (15. April) mit sechs Point-Releases in zehn Tagen, und Googles ADK 1.0 als Highlight der Cloud Next (22. April) mit Multi-Language SDKs und einem Monitoring-Dashboard. Die Feature-Vergleiche haben wir bereits abgedeckt. Was keiner davon mitgeliefert hat: Deployment-Disziplin.

Wie xpander.ai's Vergleich am 24. April zusammenfasste: "Was sie nicht bieten: Multi-Cloud-Portabilität, native CI/CD für Agents, Versionierung, Rollback oder Canary Deployments." Jeder Hyperscaler bekam beim Agent Lifecycle die Note "DIY".

Um fair zu sein: Anthropic kam am nächsten — die ant-CLI verspricht Staging-to-Production-Promotion. Aber ihr eigener Engineering-Blogpost enthält null Erwähnungen von Rollback, Canary Deploys oder Blue-Green-Switching. Versionierung existiert; Deployment-Disziplin nicht.

Warum Agents CI/CD kaputtmachen

CI/CD — Continuous Integration und Continuous Deployment — ist die Art, wie normale Software ausgeliefert wird. Du hast ein deploybares Artefakt (ein Docker Image, eine kompilierte Binary), du testest es in Staging (eine sichere Kopie von Production), du machst ein Canary (schickst 5% des Traffics auf die neue Version), und wenn es kaputtgeht, rollst du mit einem Befehl zurück.

Agents haben kein einzelnes Artefakt. Das Verhalten eines Agents verteilt sich auf mindestens vier Ebenen:

# Ebene 1: Code (versioniert in git)
agent = Agent(model="claude-sonnet-4", tools=[search, email, calendar])

# Ebene 2: System Prompt (oft im Dashboard bearbeitet, nicht in git)
SYSTEM_PROMPT = "You are a scheduling assistant who..."

# Ebene 3: Tool Configs (Berechtigungen, Rate Limits, API Keys)
# Ebene 4: Memory / gelernter Kontext (lebt... irgendwo)

Der System Prompt und die Tool-Beschreibungen sind die verhaltenskritischsten Komponenten, aber sie leben standardmäßig außerhalb der Versionskontrolle. Simon Willison hat das am 18. April demonstriert, indem er manuell eine Git-History mit gefälschten Commit-Daten gebaut hat, nur um Prompt-Änderungen zu tracken — er hat sich die Versionierung zusammengebastelt, die eigentlich ein Plattform-Feature sein sollte.

Wie Anthropic selbst eingeräumt hat: "Ein Production-Grade Agent erfordert von Software-Teams, nicht nur den Agent selbst zu bauen, sondern auch eine erhebliche Menge an Scaffolding drumherum."

Die Ära des Klebebands

Workarounds gibt es. Du kannst deine Prompt-Dateien in git versionieren. Du kannst Blue-Green-Swaps manuell machen. Du kannst deine Tool-Listen hinter Feature Flags stecken. Hier das Minimum Viable "Agent Versioning":

# Provisorisches Agent-Artefakt
agent_config = {
    "version": "1.4.2",
    "prompt_sha": "a3f8c1d",  # git hash der Prompt-Datei
    "tools": ["search_v2", "email_v1"],
    "permissions": {"email": {"max_per_hour": 10}},
    "model": "claude-sonnet-4",
}
# Deploy: config laden → validieren → Traffic umleiten
# Rollback: vorherige config laden → zurückschalten

Aber das ist Klebeband, das Disziplin erfordert, die keine Plattform erzwingt. Und es zerfällt in dem Moment, wo Agent Memory — also gelernter Kontext, der sich über Sessions ansammelt — ins Spiel kommt. Du kannst nicht zurückrollen, was ein Agent sich gemerkt hat.

Wie schlimm kann es werden? Ein Post-Mortem von Reworkd aus dem März 2026 dokumentierte ein einziges fehlerhaftes Prompt-Deployment, das 14.000 fehlerhafte API-Aufrufe in 47 Minuten auslöste — 2.300 Dollar an Token-Kosten, bevor es jemand bemerkte. Kein Canary. Kein Rollback. Nur ein Slack-Alert, der zu spät kam. Multiplizier das mit den Tausenden von Teams, die jetzt Agents ohne Deployment-Leitplanken bauen, und du siehst die Umrisse des Problems.

Was du jetzt sofort tun solltest

Wenn du heute Agents baust: Behandle jeden Prompt, jede Tool-Konfiguration und jede Berechtigungsrichtlinie als Infrastructure-as-Code. Alles in die Versionskontrolle. Aktualisiere niemals einen Production-Agent, ohne vorher eine Staging-Kopie zu testen. Plane Zeit ein, um die Deployment-Pipeline zu bauen, die dein Plattform-Anbieter übersprungen hat. Das ist kein Nice-to-have — es ist der Unterschied zwischen einer Demo und einem Produkt.

Die fehlende Schicht

Erinnerst du dich? Du hast diese Reise damit begonnen, eine Datei auf einem Server zu bearbeiten. Genau da stehen Agents jetzt — in der Vor-Docker-Ära von "Bei mir läuft's". Die Plattform, die Agent CI/CD als Standard-Primitive ausliefert — Stage, Canary, Rollback, mit dem Agent als versionierbarem Artefakt — erobert die operative Schicht, die über Modellqualität und Tool-Anzahl sitzt. Das ist der eigentliche Jackpot, und Stand 26. April 2026 hat ihn noch niemand eingestrichen.