Das Enabling Environment

Unsere Position. KI-Adoption hing für uns nie am Tool, immer an der Umgebung, in die der Agent kommt (The overcorrection trap (öffnet in einem neuen Tab)). Dieses Fundament unter dem Modell lässt sich nicht abkürzen. Das Modell wird in seinem eigenen Tempo besser, das Fundament darunter müsst ihr selbst bauen (Developer experience in the AI era (öffnet in einem neuen Tab)).

Die Umgebung beginnt bei isolierten Maschinen mit reproduzierbarer Definition. Darüber liegt eine Plattform, die sie mit echten Diensten und Triggern verbindet. Am Ende steht ein Repository, dessen Build und Tests ohne Menschen laufen.

Was braucht ein Agent, bevor eine Factory ihm Arbeit zuteilt?

Bevor eine Factory eine Aufgabe zuteilt, braucht der Agent einen Ort, an dem er sie ausführt. Genau dort liegt die Investition, von der alles andere abhängt. Ona betreibt Background Agents im großen Maßstab und argumentiert aus dieser Erfahrung. Die Teams, die Agent-PRs in großer Zahl mergen, starteten nicht mit einem besseren Modell oder Harness. Sie haben ihre Entwicklungsumgebungen schon Jahre vorher standardisiert und ernten jetzt den Zinseszins. Stripes Minions mergen über tausend Agent-PRs pro Woche, und Ramps Background Agent steht für 57 Prozent der gemergten PRs. Ona selbst hat 88,5 Prozent der PRs verfasst, die auf dem eigenen Main-Branch gemergt wurden. Der Abstand zwischen einem Agenten, der “generates a diff”, und einem, der “opens a merge-ready PR”, ist genau die Umgebung.

Localhost trägt diese Last nicht. Agents brauchen viele isolierte, vollständig provisionierte Umgebungen gleichzeitig, und Git-Worktrees auf einem einzelnen Laptop kollidieren bei Ports, Caches und Service-Zustand. Bereit für Agents wird eine Umgebung zuerst durch VMs statt Containern. Bricht ein hartnäckiger autonomer Tenant aus einem Container aus, erreicht er jede andere Umgebung auf dem Host. Dazu kommen eine deklarative, reproduzierbare Definition (devcontainer.json) und eine Automationsschicht (automations.yaml). Diese startet Dienste, installiert Abhängigkeiten und spielt Daten ein, ganz ohne manuellen Schritt. So macht dieselbe Infrastruktur, die einen Menschen an Tag eins produktiv macht, einen Agenten bei Aufgabe eins produktiv (The Last Year of Localhost (öffnet in einem neuen Tab), Ona, 13. Februar 2026).

Ona zerlegt die Entscheidung zwischen Eigenbau und Kauf in vier Schichten, die eine selbst gebaute Plattform für Background Agents abdecken muss. Ona leitet sie aus den Inhouse-Stacks von Stripe und Ramp ab.

• Vollständige Entwicklungsumgebungen. Ein Agent, der keine Pakete installieren, die Suite nicht laufen lassen und keine Builds ausführen kann, kann seine Arbeit nicht validieren. Ein Container oder CI-Runner ist dafür das falsche Grundelement.
• Eng zugeschnittene Isolation und Sicherheit. Kurzlebige Tokens pro Session, RBAC und Netzwerkisolation, die auch bei Hunderten gleichzeitiger Sessions hält.
• Anbindung und Kontext. Datenbanken, interne APIs und Staging liegen im Netz des Agenten, denn die Qualität der Ergebnisse folgt dem, was der Agent erreicht.
• Automation und Parallelität. Webhook- und Cron-Trigger plus Orchestrierung für ganze Flotten. Agents, die nur auf einen Prompt hin laufen, deckelt die Kapazität der Menschen.

Stripe baute seinen Harness auf einer Plattform für Remote-Devboxen, die älter ist als GPT-3. Ramp baute Sandboxes von Hand auf Modal, mit Session-Zustand auf Cloudflare Durable Objects. Eine Registry baut dort jedes Repo alle dreißig Minuten neu. Beide haben Plattform-Teams, Jahre der Standardisierung und Budget, das den meisten Organisationen fehlt (The Background Agent Infra Ramp Had to Build (öffnet in einem neuen Tab), 2. April 2026).

Eine Besprechung von Stripes eigenem Bericht ergänzt den Aufbau eines Minion. Stripe liegt inzwischen bei rund 1.300 Agent-PRs pro Woche, ohne eine von Menschen geschriebene Zeile, in Hunderten Millionen Zeilen Ruby.

• Einstiege über CLI, Web und Slack speisen einen Pool vorgewärmter EC2-Devboxen. Diese starten in etwa zehn Sekunden, mit Stripes Code und Diensten bereits geladen.
• Der Agent-Harness ist ein Fork von Blocks Goose und um “blueprints” gebaut. Das sind in Code entworfene Workflows, die deterministische Knoten (Lint, Commit, Tests laufen lassen) mit Agent-Knoten (implementieren, CI reparieren) abwechseln.
• Regeldateien, per Glob-Muster zugeschnitten, hängen Kontext an, während der Agent durch den Baum geht.
• Ein zentraler MCP-Server, der “tool shed”, stellt 400 bis 500 interne Tools hinter einem Meta-Tool bereit, das unter ihnen auswählt.
• Die CI führt gezielt einen Ausschnitt aus über drei Millionen Tests aus. Jeder Minion darf aus Kostengründen höchstens zwei CI-Runden fahren (Kommentar zu Stripes Minions (öffnet in einem neuen Tab), 2. März 2026).

Ona bietet dieselbe Form als Produkt an, als Automations: “proactive background agents running in the cloud that combine AI prompts with deterministic shell scripts in trigger-based, closed-loop workflows”. Vorlagen gibt es für die Auswahl von Aufgaben aus dem Backlog, Sentry-Triage und das Aufräumen von totem Code. Dazu kommen CVE-Behebung, die so lange neu läuft, bis der Scanner sauber ist, und Migrationen im großen Maßstab. Das Angebot zielt auf bis zu 30 Prozent der Engineering-Zeit, die in CVE-Mitigation, Dependency-Updates und große Migrationen fließen. Ein Pharma-Kunde aus den Top fünf berichtet, dass Automations 90 bis 95 Prozent dieser Arbeit erledigen. Den letzten Schritt machen Menschen (Ona – Ona Automations: Proactive Background Agents (öffnet in einem neuen Tab), 19. Februar 2026, Anbieter).

Ein Gespräch aus der Praxis über Factory-Stacks hält die Entwicklungsumgebung für die Schicht, die ihr selbst besitzen solltet. Die Sandbox eines Anbieters ist bequem, solange ihr nur ein Base-Image mit der richtigen Toolchain braucht. Sie wird zur Reibung, sobald der Agent die gemeinsamen Dienste erreichen muss, von denen eine große Anwendung abhängt. Dann müsstet ihr das Firmennetz für fremde Rechenleistung öffnen. Sie bricht auch, sobald dem nicht standardmäßigen Kernel der Sandbox ein System Call fehlt, den die Toolchain braucht. Die Hosts erwarten diese Reibung bei jedem Team, außer seine Arbeit ist eine kleine Anwendung mitten in der Trainingsverteilung der Modelle. Identität verorten sie ebenfalls in dieser Schicht statt im Harness. Die Umgebung hält die Credentials und Scopes, die interne Dienste öffnen, also muss der Harness nie Zugriff provisionieren (Boundary - How to Build a Software Factory for AI Coding Agents (öffnet in einem neuen Tab), August 2026, Praxis und Anbieter).

Dasselbe Gespräch behandelt Arbeit, die sich über viele Repositories erstreckt. Submodules pinnen Commits und zwingen dazu, jede Änderung an zwei Stellen zu committen. Stattdessen startet jede Agent-Session aus einem Koordinations-Repository oder Workspace. Dessen Agent-Config-Datei sagt, wo die anderen Repositories liegen. Der Agent recherchiert dann über alle hinweg, ohne dass sie einen Git-Tree teilen. On-Demand-Sandboxes erschweren das. Jedes Repository pro Lauf zu klonen kostet Zeit und Plattenplatz. Wählt ein Mensch die relevanten aus, scheitert das genau dort, wo Agents am meisten helfen: in Codebasen, die dieser Mensch nicht kennt. Diese Abwägung ist die Wahl zwischen Pets und Cattle, angewandt auf Agent-Umgebungen. Für ein kleines Team halten die Hosts ein paar langlebige, von Hand gepflegte Maschinen für einen vernünftigen Start (Boundary - How to Build a Software Factory for AI Coding Agents (öffnet in einem neuen Tab), August 2026, Praxis und Anbieter).

Wer baut die Umgebung, und wem gehört sie?

Organisatorisch folgt daraus: Harness Engineering ist Platform Engineering, von Grund auf neu erfunden, also werden alle Engineers zu Platform Engineers. Die alte Stellenleiter in Onas Bericht sah Dokumentation ab 15 Engineers vor, eine Infrastruktur-Fachkraft ab 50 und eine Plattform ab 150. Sie gilt nicht mehr, wenn eine einzelne Person im Tempo vieler liefert. Agents halten Standards außerdem folgsamer ein, als es eine Abteilung je tat. Für die nahe Zukunft lautet die Prognose: Weit kleinere Organisationen als früher lernen die Lektionen des Platform Engineering auf die harte Tour neu. Sie lernen sie durch Tool-Wildwuchs und wuchernde Standards (Ona – Everyone’s Becoming a Platform Engineer (öffnet in einem neuen Tab), 29. April 2026).

Zwei Organisationsentwürfe geben dieser Neuerfindung der Plattform eine Form. Ein Bericht passt Team Topologies an die agentische Ära an. Agents machen aus kognitiver Last, die sich über Teams verteilt, ein Durchsatzproblem, das auf einer Person lastet. Es besteht aus einer Last der Vorausschau (“everything the human must foresee before launching the agent”) und einem anhaltenden Strom an Entscheidungen. Denn Agents “do not ask questions: they produce answers, immediately”, und schlecht gebriefte Agents liefern schnell und am Ziel vorbei. Das Modell des Berichts für Plattform-Teams bietet drei Säulen als Service: systemischen Kontext, systemische Guardrails sowie Tooling und Skills. Stream-aligned Teams können nicht-technisch sein, weil die Plattform die technische und operative Last trägt.

Drei seiner Regeln taugen auch anderswo. Eine Guardrail, die drei oder mehr Teams neu bauen, wandert in die Plattform, die Rule of Three aus dem Refactoring übertragen. Reife lässt sich an Guardrail-Abdeckung, Pipeline-SLA, Self-Service-Anteil, Dokumentation und Nachvollziehbarkeit von Entscheidungen beobachten. Nachvollziehbarkeit heißt hier ein Audit Trail, warum ein Deployment blockiert wurde und durch welche Regel. Sobald nicht-technische Teams Produktions-Apps ausliefern, gilt: “ease of production must be matched by ease of oversight”. Sonst industrialisiert die Factory Schatten-IT. Die gemeinsame Plattform rechnet sich ab etwa drei bis fünf Produktteams, die parallel agentische Apps betreiben. Ab dort übersteigen die summierten Kosten der Neuerfindung die Investition (Team Topologies for the Agentic Platform (öffnet in einem neuen Tab), 22. Juni 2026).

Ein Talk über Agent Enablement fasst denselben Rollout in vier Schichten, analog zur Geschichte von DevOps. Erst befähigt ihr die Agents, dann das Team, dann die Plattform, dann die Organisation. Ein Inkubationsteam entwickelt Muster, die andere Teams nachahmen, bevor eine gemeinsame zentrale Schicht entsteht. Das Registry-Muster des Talks macht Skills, MCP-Server, Harnesses und Pipelines versioniert, auffindbar und per Self-Service nutzbar. Dazu kommt eine Warnung: Gemeinsame Komponenten verrotten ohne ausdrückliche Ownership und Budget. Von den “5 or 6 harnesses being built” in einer typischen Organisation sollten nur wenige überleben (The Rise of Agent Enablement (öffnet in einem neuen Tab), 8. Juli 2026).

Warum gehört Security in die Laufzeitumgebung?

Security ist in dieser Umgebung eine Schicht der Laufzeitumgebung selbst, kein nachträglicher Anbau. Ona beschreibt sie als Defense in Depth über einen Stack, den Ona selbst kontrolliert. Dazu gehören Plattform-Hygiene im Kundennetz, Guardrails für Ein- und Ausgaben und Durchsetzung auf Kernel-Ebene. Guardrails aus KI, die KI bewachen, sind laut Ona zirkulär. HiddenLayer brach OpenAIs Guardrails binnen Tagen. Cisco maß über acht Open-Weight-Modelle eine durchschnittliche Erfolgsquote von 64 Prozent für Multi-Turn-Angriffe. Regeln auf Anwendungsebene sehen den Plan, nur der Kernel sieht die Ausführung. Als Designprinzip gilt, dass die Bremsen ins Fahrgestell konstruiert sind. Die Richtung folgt dem Modell autonomer Fahrzeuge. Eine harte, von Nutzer:innen festgelegte äußere Grenze umschließt eine dynamische innere Grenze. Die innere wird weiter, wenn ein Agent Vertrauen verdient, und zieht sich bei Fehlern zusammen. Alles ruht auf Durchsetzung auf Kernel-Ebene als Fundament (Introducing Veto (öffnet in einem neuen Tab), 3. März 2026).

Dahinter steht die Unterscheidung zwischen Guardrails und Garantien: “LLMs are optimizers. Given a task, they will find creative paths to completion. If a guardrail blocks a command, a sufficiently capable model may find an alternative route, including disabling the guardrail itself. Guarantees operate at a level the agent cannot reach”. Die Designregel lautet, auf der Diagonale zu bleiben, auf der die Macht des Agenten und die Risikokontrollen im Gleichschritt wachsen (Ona – The AI-SDLC Framework (öffnet in einem neuen Tab), 14. Mai 2026).

Wie verkürzt das Repository die Feedback-Schleife des Agenten?

Das Repository selbst ist die innere Schicht der Umgebung. Ein Agent arbeitet in Zyklen: ändern, bauen, Ausgabe lesen und neu versuchen. Jeder kaputte Build, jeder flaky Test und jede unklare Fehlermeldung verlängert diesen Zyklus. Die Community rund um Continuous Delivery beziffert den Preis. Ein falscher erster Versuch mit Review und neuem Prompt kostet ungefähr dreimal so viele Tokens wie ein Versuch, der sofort sitzt. Ihre Readiness-Rubrik bewertet jedes Kriterium von 0 bis 3. Dazu gehören Reproduzierbarkeit des Builds, Testqualität, Klarheit der CI, gepinnte Abhängigkeiten, Modularität, Benennung, Typsicherheit und Fehlerbehandlung. Ein Kriterium auf 0 blockiert Agent-Arbeit, eines auf 1 macht die Ergebnisse unzuverlässig. Wirksame Agent-Arbeit verlangt, dass jedes Kriterium mindestens 2 erreicht (MinimumCD.org and DojoConsortium.org - Repository Readiness for Agentic Development (öffnet in einem neuen Tab), Stand September 2026).

Der Leitfaden ordnet die Reparatur danach, was zuerst blockiert. Ein einziger Befehl muss das Projekt aus einem frischen Checkout bauen. Die Tests müssen bei jedem Lauf dasselbe Ergebnis liefern, ohne externe Dienste in Unit-Tests. Danach kommen Fehlermeldungen, die Erwartetes neben Tatsächlichem zeigen, und eine schnelle Teststufe, getrennt von der langsamen. Erst dann lohnt sich Dokumentation für den Agenten. Es folgen kleinere Module, einheitliche Benennung, erzwungene Formatierung und das Entfernen von totem Code. Dazu kommen Typen an öffentlichen Grenzen und ein einziges Muster für Fehlerbehandlung, das ein Linter durchsetzt. Zwei seiner Begründungen gelten speziell für Agents. Jedes Synonym für einen Fachbegriff verbraucht Kontextbudget, und toter Code bringt dem Agenten Muster bei, die das Team aufgegeben hat. Der Mindestvertrag besteht aus einem Build-Befehl und einem Test-Befehl. Beide laufen ohne Menschen, nutzen funktionierende Defaults für jede Umgebungsvariable und enden bei Fehlern mit einem Exit-Code ungleich null (MinimumCD.org and DojoConsortium.org - Repository Readiness for Agentic Development (öffnet in einem neuen Tab), Stand September 2026).

Verwandte Seiten

• Software Factories und Harness Engineering: der Harness, der auf dieser Umgebung läuft.
• Sicherheit und Runtime-Isolation: warum die Kontrollen, die halten, unterhalb des Agenten liegen.
• Agent Observability: das Run-Protokoll, das eine Umgebung für jeden Agenten erzeugen sollte.
• Federated Factory im Enterprise-Maßstab: wie eine Plattformschicht Umgebungen für viele Teams bereitstellt.
• Agentic Continuous Delivery: die Pipeline, die eine Agent-Änderung durchläuft, nachdem sie die Umgebung verlassen hat.

Quellen

Readiness

• Repository Readiness for Agentic Development (öffnet in einem neuen Tab) - Community-Leitfaden mit einer Readiness-Rubrik von 0 bis 3 und einer geordneten Upgrade-Reihenfolge, die die Build- und Test-Schleife des Agenten strafft, CC BY 4.0.