Agenten verlassen das Labor — was 2026 zeigt

agents-2026.png

Auf einen Blick

• Auf der PyCon DE & PyData 2026 zeigen Teams Agenten-Systeme, die seit drei bis sechs Monaten stabil in Produktion laufen — nicht mehr nur Demos.
• Drei Muster verbinden diese Systeme: striktes Kontextmanagement, deterministische Fallback-Pfade, Evaluation-gekoppelte Releases.
• Drei Muster brechen verlässlich: offene Aufgabenstellungen, freie Tool-Auswahl, Test-Generation ohne Domänen-Anker.
• Die strategische Konsequenz: Agent-Architekturen sollten 2026/27 am Harness gemessen werden, nicht am Modell. Wer den nächsten Euro ins Base-Modell steckt, investiert nicht dort, wo der Hebel sitzt.

Vom Demo zur Produktion: ein leiser, aber harter Schnitt

Auf der PyCon DE & PyData 2026 fiel etwas auf, was sich schwer in einer Schlagzeile fängt: Der Ton der Agenten-Talks hat sich gedreht. Wo 2024 und 2025 noch fast jede Demo mit "Look at what's possible" begann, sprachen Teams in diesem Jahr von "läuft seit Februar", "musste dreimal nachgesteuert werden", "scheitert in genau diesen Kategorien". Das klingt unspektakulär. Es ist die wichtigste Verschiebung des Jahres.

Was dort sichtbar wurde, ist keine neue Agenten-Euphorie, sondern ihr Gegenteil: Ernüchterung als Reifezeichen. Die Teams, die liefern, sprechen nicht mehr über Modellmagie. Sie sprechen über Kontextbudgets, Fallbacks, Tool-Grenzen und Evaluation. Kurz: über das Harness.

Mit Harness ist hier die Gesamtheit aus Kontextsteuerung, Tool-Grenzen, Eval-Pipeline, Fallback-Logik und Freigabemodell gemeint — also die operative Schicht, die ein Modell produktionsfähig macht. Sie ist gleichzeitig technische Architektur, Governance-Rahmen und Investitionsentscheidung. Drei Muster aus der Konferenz wiederholten sich in den Systemen, die laufen — und drei in jenen, die in der Demo überzeugen und in Produktion zuverlässig brechen.

Drei Muster, die 2026 tragen

Striktes Kontextmanagement statt freier Speicher

Die Systeme, die laufen, behandeln Kontext nicht als unbegrenzten Speicher, sondern als knappes Gut mit klarer Ökonomie. Sie wissen, was rein muss, was draußen bleibt, und wann gepflegt wird. Sebastian Raschka brachte das im Fireside Chat trocken auf den Punkt: das Geheimnis hinter funktionierenden Coding-Agents sei nicht das Modell, sondern Prompt- und Cache-Management. Die Repo-History, die Konversation, der Plan — alles muss eingespeist werden, aber nicht alles auf einmal. Wer das nicht aktiv kuratiert, baut ein System, dessen Verhalten von Dialog zu Dialog driftet. Kontextmanagement ist deshalb keine Prompt-Technik. Es ist Zustandsmanagement.

Deterministische Fallback-Pfade

Jedes belastbare System hat einen Pfad, der ohne LLM funktioniert. Das ist keine Restauration der Vergangenheit, sondern die ehrliche Anerkennung, dass ein Sprachmodell weder verfügbarer noch günstiger noch erklärbarer wird, je tiefer man es im Stack vergräbt. In regulierten Kontexten ist dieser Punkt nicht verhandelbar: ohne deterministischen Fallback gibt es keine Audit-Spur, keine Nachvollziehbarkeit, keine Freigabe. Der Fallback ist nicht der Notausgang des Systems. Er ist der Beweis, dass das System verstanden wurde.

Evaluation-gekoppelte Releases

Die produktionsstabilen Teams releasen nicht "wenn es gut aussieht", sondern wenn die Eval-Pipeline grün ist. Das setzt voraus, dass diese Pipeline existiert — was in vielen Programmen erst spät passiert, oft zu spät. Wo Eval-Disziplin von Anfang an eingebaut war, sah man auf der Konferenz Systeme mit klaren Versionsständen und nachvollziehbaren Verbesserungskurven. Wo sie fehlte, sah man Teams, die nicht mehr genau sagen konnten, wann ihr System eigentlich besser geworden war. Eval ist nicht Qualitätssicherung am Ende. Sie ist die einzige Schicht, in der "besser" eine Bedeutung hat.

Drei Muster, die in Produktion brechen

Offene Aufgabenstellungen

"Schreib Tests für dieses Modul" produziert Tests. Sie sind nur selten gut. Raschka formulierte es im Chat klar: Agenten haben "keine eigene Agency". Sie reagieren präzise auf präzise Anweisungen. Wo offene Aufgaben gestellt werden, entstehen flache Lösungen — die in der Demo überzeugen, weil sie irgendwas tun, und in Produktion versagen, weil "irgendwas" nicht ausreicht.

Alina Dallmann hat das in ihrem Talk Beyond Vibe-Coding — A Practitioner's Guide to Spec-Driven Development präzise zerlegt: Drei wiederkehrende Versagensmodi entstehen, wenn man der KI offene Aufgaben gibt — fragmentierte Designentscheidungen, über mehrere Chat-Sitzungen verstreut; Prompt Drift, in dem die Konversation eine Eigendynamik entwickelt; und versteckte Annahmen, die das Modell trifft, weil niemand sie ausgesprochen hat. Ihr Schluss ist derselbe, der hier als Architektur-Aussage steht: die Spezifikation gehört vor den Code, nicht in den Code. Aufgabenstellungen werden zur Architektur. Wer das nicht erkennt, hat ein anderes Problem als ein Modell-Problem.

Freie Tool-Auswahl

Wenn ein Agent aus einer offenen Werkzeugkiste wählen darf, kippt das Verhalten in der Praxis unkalkulierbar — meist elegant, gelegentlich katastrophal. Harald Nezbedas Talk Building Secure Environments for CLI Code Agents lieferte dazu konkrete Vorfälle aus der Praxis (mehr im Abschnitt "Trust Boundary"). Für unkritische Anwendungen ist diese Spannweite in Ordnung. Für jeden regulierten Kontext, jede kritische Pipeline, jede automatisierte Operation an realen Daten ist es eine Architektur, die irgendwann teuer wird. Die Systeme, die laufen, beschränken die Tool-Auswahl drastisch — und überprüfen jedes Tool gegen einen klaren Use-Case-Kontrakt.

Test-Generation ohne Domänen-Anker

Die New York Times hat den Fall im April 2026 dokumentiert: ein Finanzdienstleister sprang mit dem AI Coding Tool Cursor von 25.000 auf 250.000 Code-Zeilen pro Monat. Innerhalb kurzer Zeit entstand ein Review-Backlog von einer Million Zeilen. Joni Klippert, Co-Gründerin und CEO von StackHawk (Security-Start-up, das mit dem Unternehmen arbeitete): "Die schiere Menge an ausgeliefertem Code und der Anstieg an Schwachstellen ist etwas, mit dem sie nicht Schritt halten." Die Folge: händeringend gesuchte Senior Software Engineers, die reviewen sollen — und ein Druck, der sich nach Vertrieb, Marketing und Support verschiebt, weil die das Tempo mitgehen müssen. Tests, die Agents schreiben, sind oft flach. Reviews, die Menschen leisten, skalieren nicht im Faktor zehn. Diese Schere wird sich 2026 nicht von allein schließen.

Was das für Architektur-Entscheidungen heißt

Wenn Harness die entscheidende Schicht ist, hat das drei konkrete Folgen für Programme, die 2026 anlaufen:

Modellwahl wird sekundär

Cursors Composer-3-Modell — produktiv im Einsatz — ist ein Beispiel dafür, warum: der Produktionsgewinn entstand nicht aus der Modellwahl, sondern aus dem Post-Training auf einem offenen Basismodell. Wer diese Logik akzeptiert, verschiebt sein Investment vom Lieferanten-Vergleich zum Harness-Engineering. Die ausführliche Lehrstück-Sicht auf Composer-3 trägt der Open-Stack-Beitrag dieser Serie.

Trust Boundaries werden explizit

Wo darf ein Agent autonom handeln, wo nur vorschlagen, wo nur informieren? Diese Entscheidung ist keine Detailfrage, sondern Architektur. In regulierten Industrien definiert sie den Compliance-Rahmen. In allen anderen entscheidet sie über Skalierbarkeit.

Review-Kapazität wird zum Engpass

Der Faktor-10-Sprung in Code-Volumen entsteht ohne weiteres Zutun, sobald Agenten produktiv schreiben. Reviewer, die das prüfen, entstehen nicht von allein. Wer das nicht im Programm-Setup adressiert, baut sich eine technische Schuld, die in zwölf Monaten teurer ist als jeder Einsparungsgewinn.

Trust Boundary als Vertrag, nicht als Slogan

Trust Boundaries auszusprechen ist einfach, sie als Vertrag zu schreiben ist die eigentliche Arbeit. Genau an dieser Stelle straucheln 2025/26 die meisten Programme — nicht, weil die Idee falsch ist, sondern weil sie nie operativ gemacht wird.

Konkret heißt das: für jeden Agenten-Schritt sind drei Modi sinnvoll zu unterscheiden. Lesen und vorschlagen (Mensch entscheidet), ausführen mit nachgelagerter Freigabe (Vier-Augen-Prinzip), oder autonom abschließen (kein Mensch im Loop). Welcher Modus für welche Aktion gilt, ist keine technische, sondern eine Architektur- und Governance-Entscheidung. Sie muss in der Pipeline kodiert sein, nicht in der Prompt-Vorlage.

Die Programme, die 2026 produktiv liefern, haben für jeden Agenten-Schritt diese drei Modi explizit zugewiesen. In den meisten Fällen ist die autonome Variante für mehr als die Hälfte der möglichen Aktionen ausgeschlossen — und gerade das macht den Rest erst belastbar. Wo diese Zuweisung fehlt, läuft jede Aktion implizit auf "autonom", bis ein Vorfall die Diskussion erzwingt. Aus laufenden Architektur-Reviews kann ich das ergänzen: dort, wo diese Modi-Zuweisung explizit als Vertragsbestandteil im Programm-Setup steht, wird sie auch operativ. Wo sie als Anhang oder als implizite Architektur-Entscheidung mitgeführt wird, fällt sie im ersten Stress-Moment.

Gabriela Bogk, CISO bei Mobile.de und langjähriges Mitglied des Chaos Computer Club, brachte das in ihrer Keynote "Honey, I vibe coded some crypto" auf eine Formel, die in jeder Architektur-Diskussion zum Vertrag werden sollte: Blast Radius. Die Frage, die vor jedem autonomen Agenten-Schritt stehen muss, ist nicht "kann der Agent das?", sondern "was ist das Schlimmste, das passieren kann, wenn er es falsch macht — und können wir das tragen?". Ihr eigener Cloud-Code-Setup läuft in einer VM mit handgepflegten API-Keys, ohne Zugriff auf produktive Daten, mit dem Code als Backup im Git-Repo. Das ist nicht Paranoia, sondern die Übersetzung von Trust Boundary in operative Architektur.

Bogks zweite Pointe ist für regulierte Kontexte zentral: Prompt-basierte Guardrails sind weich. "Everything that's prompt-based in terms of your guardrails is soft and can be worked around and is prone to injection attacks." Wer Sicherheit über System-Prompts implementiert, baut auf Sand. Hardcoded-Limits in Tool-Berechtigungen, Filesystem-Zugriff und API-Keys sind die einzige belastbare Schicht — das LLM sitzt darüber, nicht darunter.

Harald Nezbeda hat in seinem Talk Building Secure Environments for CLI Code Agents die Konsequenzen sehr konkret gemacht. Die Risikolage, in der ein Coding-Agent ohne Sandbox auf der Entwickler-Maschine läuft, fällt in das, was Simon Willison die lethal trifecta nennt: privater Datenzugriff plus externe Verbindung plus Handeln auf Basis nicht vertrauenswürdigen Kontexts. Dokumentierte Vorfälle aus der Cloud-Code-Praxis: gelöschte Home-Verzeichnisse, ein Crypto-Miner per kompromittiertem NPM-Paket. Sein Pattern dafür ist Container-Isolation plus Man-in-the-Middle-Proxy mit eigener SQLite-basierter Observability. Das ist nicht paranoid. Es ist 2026 die Mindestkonfiguration, wenn ein Coding-Agent in Produktion oder regulierten Kontexten zum Einsatz kommt. Diesen Punkt nicht abzuwarten, ist die teuerste Disziplin im Agent-Engineering 2026.

So What

Wer die Konferenz als "Bestätigung der Agenten-Welle" liest, missversteht das Bild. 2026 trennen sich die Agenten-Programme in zwei Lager: jene mit Harness-Disziplin und jene ohne. Die positionierende Aussage "wir setzen jetzt auch auf agentische KI" — ob auf Vorstandsfolien, in Strategiepapieren oder im Investor-Deck — ist 2026 zu billig. Sie sagt etwas über die Außendarstellung, nichts über die Architektur.

Die Frage, die in den nächsten zwölf Monaten über Programme entscheidet, ist konkreter: Was ist unser Harness, wer baut ihn, woran messen wir, dass er hält. Nicht die Modellwahl entscheidet, nicht der Vendor, nicht das Pilot-Budget. Wer das Harness ernst nimmt, bekommt Agenten, die tragen. Wer es übergeht, bekommt Demos mit Produktionskosten.