> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/de/2026/w33-five-steps-toward-the-future-work-paradigm-seen-through-agent-teams.md). # W33-Fünf Stufen der künftigen Arbeitsweise, betrachtet durch Agent-Teams Boris Cherny, der Leiter von Claude Code, veröffentlichte kürzlich eine Tabelle namens [Steps of AI Adoption](https://docs.google.com/document/d/1R91ayvj7uvlxgNi--__2-Bf3w8x5r1nF-xIBN7ds8Ns/edit). In seinem [Originalbeitrag](https://x.com/bcherny/status/2077929379661844559) beschreibt er ein wiederkehrendes Phänomen: Eine Person im Team steigert ihren Output mithilfe von Claude um eine Größenordnung, während der Rest der Organisation nicht nachzieht. Das entspricht ziemlich genau meinem jüngsten Eindruck. Die durch KI entstehenden Unterschiede betreffen längst nicht nur den geschickten Umgang mit Werkzeugen. Verschiedene Menschen arbeiten nach völlig unterschiedlichen Paradigmen. Boris unterteilt die KI-Nutzung in fünf Ebenen von L0 bis L4. Genauer sind es fünf Zustände und vier Übergänge. Ich verstehe sie lieber als fünf Stufen der künftigen Arbeitsweise. ## Fünf Stufen | Ebene | Rolle des Menschen | Arbeitsweise | Hauptengpass | | --------------------------- | ------------------------- | ------------------------------------------------------------------------------------------------------------ | ------------------------------------ | | L0 Eingeschränkt | Zuschauer | Man möchte KI nutzen, doch wirklich leistungsfähige Modelle bleiben von der Arbeit ausgeschlossen | Zugangsrechte | | L1 Unterstützung | Partner | Ein Mensch arbeitet mit einem Agent; der Agent führt aus, der Mensch prüft Schritt für Schritt | Menschliche Aufmerksamkeit | | L2 Parallelität | Koordinator | Ein Mensch organisiert mehrere Agents; sie führen aus und prüfen sich selbst, der Mensch nimmt Ergebnisse ab | Review-Kapazität | | L3 Beaufsichtigte Autonomie | Vorgesetzter von Managern | Zeitpläne oder Ereignisse lösen Arbeit aus; Menschen genehmigen Ausnahmen | Vertrauen und Entscheidungskapazität | | L4 KI-nativ | Definierer von Absichten | Hunderte oder Tausende Agents arbeiten zielgerichtet; Menschen steuern über Ausnahmen | Werturteile und Governance | Boris nennt Agent-Zahlen von 0, 1, 10, 100 bis über 1000. Das sind eher Größenordnungen als Aufstiegskriterien. Entscheidend ist, wie sich die Rolle des Menschen verändert. Auf L1 sitzt der Mensch bei jeder Aufgabe noch am Steuer. Der Agent ähnelt einem sehr schnellen Assistenten. Auf L2 entwirft der Mensch die Arbeitsteilung, steuert den Kontext und setzt Abnahmekriterien. Mehrere Agents treiben die Arbeit parallel voran; die menschliche Aufmerksamkeit gilt vor allem Ergebnissen und Ausnahmen. L3 geht einen Schritt weiter. Nicht mehr jede Aufgabe muss einzeln von einem Menschen angestoßen werden. Das System hört auf Ereignisse, arbeitet nach Zeitplan, erkennt Probleme und erzeugt selbst Aufgaben. Der Mensch verwaltet nicht mehr jeden einzelnen Agent, sondern das aus Agents bestehende Arbeitssystem. ## Mehrere Agents sind noch kein Agent-Team Bisher ging es vor allem darum, einzelne Agents leistungsfähiger zu machen und ihnen längere, komplexere Aufgaben zu übertragen. Ihre Fähigkeiten haben Grenzen. Deshalb setzen immer mehr Menschen mehrere Agents gleichzeitig ein. Mit ihrer Zahl entstehen neue Probleme. Die Fähigkeit des einzelnen Agents ist nicht mehr der einzige Engpass. Die Organisationsform bestimmt zunehmend die Gesamtleistung. Wenn Menschen weiterhin für jede Aufgabe den Einstieg auswählen, Hintergründe aufbereiten, Kontext transportieren und das Ergebnis eines Agents an den nächsten übergeben müssen, bleiben diese Agents im Kern unabhängige Werkzeuge. Der Mensch ist weiterhin der einzige Router des Systems und damit faktisch dessen Engpass. Ein Agent-Team hat nach meinem Verständnis drei Merkmale. Erstens trägt jeder Agent dauerhaft Verantwortung für seinen Bereich. Er weiß, was er bearbeiten soll, wo seine Grenzen liegen und welche Fragen nicht zu ihm gehören. Zweitens geht ein Teil der Zusammenarbeit vom Menschen auf Agents über. Innerhalb klarer Verantwortungsbeziehungen erledigen sie Routing, Übergaben und die Rückführung von Ergebnissen selbst. Nicht mehr jeder Schritt muss durch den Menschen verbunden werden. Drittens bleibt der Mensch Teil des Teams, nimmt aber eine andere Position ein. Bei Richtung, Fakten, Entscheidungen, Reviews und Freigaben kehrt er zurück, statt den gesamten Ausführungsprozess zu beobachten. Sobald Menschen nicht mehr an jedem Schritt beteiligt sind, stellt sich jedoch sofort eine weitere Frage: Woher weiß ich, wie dieses Team tatsächlich arbeitet? Ein Agent-Team muss deshalb beobachtbar und verständlich sein und sich laufend anpassen lassen. Sonst tausche ich nur die persönliche Steuerung jedes Agents gegen Unwissen darüber, was sie tun. ## Das erste Gefühl eines echten Agent-Teams Meine prägendste L2-Erfahrung machte ich mit Multica. Dort richtete ich zunächst einen Engineering Squad ein, um einen MCP zur Anbindung der internen Codehosting-Plattform meines Unternehmens zu bauen. In der frühen Version übernahm Claude Strategie, Zerlegung und Routing, Codex die Implementierung und Gemini Erkundung sowie unabhängige Abnahme. Produktabsicht, Prioritäten, Abwägungen und die letzte Freigabe blieben bei mir. Diese Kombination gab mir erstmals ein starkes Teamgefühl. Nachdem ich Ziel und Grenzen erklärt hatte, zerlegte der Leader die Arbeit weiter und wählte passende Agents für Erkundung, Umsetzung und Abnahme aus. Nur bei Fragen mit Urteilsbedarf erhielt ich eine Nachricht und kehrte für eine Entscheidung in die Aufgabe zurück. Zu Beginn einer Aufgabe widersprachen sich zwei Unterlagen bei Schnittstellenstil und Authentifizierung. Der Leader ließ Codex nicht sofort Code schreiben, sondern beauftragte zuerst einen klar begrenzten Spike. Dieser sollte nur einige Faktenfragen beantworten und reale Anfragen als Belege liefern. Die Implementierung des MCP war ausdrücklich untersagt. Wenige Minuten Erkundung verhinderten eine vollständige Fehlimplementierung. Auch die spätere Abnahme zeigte den eigentlichen Wert des Teams. Ein Bericht wollte mit einer 401-Antwort auf ein ungültiges Token beweisen, dass ein bestimmtes Authentifizierungsverfahren nicht existierte. Die Schlussfolgerung stimmte zufällig, die Begründung war aber ungültig. In einer anderen Runde bestanden alle Tests, doch das reale Fixture enthielt lediglich ein leeres Array. Die Feldstruktur nicht leerer Daten wurde überhaupt nicht geprüft. Diese Berichte waren nicht gefälscht. Sie waren richtig, aber unvollständig. Der Leader musste die Belege mit einer anderen Zielfunktion erneut betrachten. Implementierer und Prüfer durften sich nicht auf dieselbe Logik zur Selbstbestätigung stützen. Aus der Aufgabe entstanden einige feste Regeln: Begrenzte Erkundung kommt vor Implementierung. Der Autor darf bei riskanten Änderungen nicht der einzige Reviewer sein. Belege müssen erklären, was sie beweisen und was nicht. Nach außen sichtbare, irreversible oder mit persönlicher Identität verbundene Aktionen werden angehalten und an einen Menschen gegeben. Das war meine unmittelbare L2-Erfahrung: Eine einzelne Person verfügt plötzlich über ein Umsetzungsteam mit sehr geringen Koordinationskosten. ## Von einer Konfiguration zu einem Betriebsmodell Danach entwickelte ich meine Multica-Nutzung von einer vorübergehenden Konfiguration zu einem wartbaren Betriebsmodell weiter und hielt es in einem Git-Repository fest. Entscheidend war, vier Objekte voneinander zu trennen. | Objekt | Zuständigkeit | Änderungstempo | | ------------------ | ---------------------------------------------------------------- | ------------------------------------------ | | Profession Profile | Rollenaufgaben, Entscheidungsgrenzen, Werkzeuge und Belegvertrag | Stabil und versionierbar | | Agent Instance | Konkrete Runtime, Modell, Rechte und Parallelität | Austauschbar | | Squad | Dauerhafter Auftrag, Routingregeln und Mitgliedschaft | Anpassung an stabile Arbeitswarteschlangen | | Issue Run | Ziel, Kontext, Belege und verbleibende Risiken einer Aufgabe | Bei jeder Aufgabe anders | Der Kernnutzen liegt darin, stabile Verträge von veränderlichen Bereitstellungen zu trennen. Rollenaufgaben sollten stabil sein. Der Delivery Lead verantwortet dauerhaft Zerlegung, Routing, Konfliktentscheidungen und die Zusammenführung der Belege. Der Implementation Engineer implementiert und testet. Der Challenger sucht Gegenbeispiele und führt Reviews ohne Schreibzugriff durch. Der Explorer-Validator erkundet große Kontexte, untersucht Auswirkungen und übernimmt unabhängige Abnahmen. Runtime und Modell können wechseln. Heute läuft der Delivery Lead auf Claude, der Implementation Engineer auf Codex, der Challenger verwendet Grok und der Explorer-Validator Gemini über Antigravity. Ändern sich Modelle künftig, lassen sich Instanzen ersetzen, ohne zugleich die Verantwortungsbeziehungen des Teams neu zu schreiben. Das bedeutet keinen kostenlosen Modelltausch. Rechte, Werkzeuge, Sitzungen und Fehlermuster jeder Runtime müssen erneut geprüft werden. Austauschbarkeit heißt, dass der Organisationsvertrag nicht an eine Modellmarke gebunden ist. Sie ersetzt keine Abnahme der Bereitstellung. ## Meine aktuelle Multica-Konfiguration Zum Zeitpunkt dieses Artikels verwalte ich in Multica acht Agent-Instanzen und vier dauerhafte Squads. Die vier squadübergreifenden Hauptrollen sind Delivery Lead, Implementation Engineer, Challenger und Explorer-Validator. Dazu kommen Product Architect, Market Researcher, Ops Engineer und Data Analyst für Forschung, Architektur und Zuverlässigkeit. Die vier Squads orientieren sich an stabilen Arbeitswarteschlangen. | Squad | Eingangskriterium | Standardweg | | ----------------------- | ------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | Engineering | Alltägliche Funktionen, Refactoring, gewöhnliche Bugs und technische Lieferung | Claude routet, Codex schreibt allein, Gemini nimmt ab, bei Bedarf prüft Grok kritisch | | Reliability & Incident | Unklare Ursache, modulübergreifender oder schwer reproduzierbarer Fehler, Zuverlässigkeitsprobleme im Betrieb | Mehrere reine Belegsammlungen, Claude bündelt Hypothesen, Codex schreibt die Reparatur allein, Regressionstest durch Nichtautor | | Research & Architecture | Technologiewahl, Produktabwägungen, Migration oder begrenzter Spike | Gemini sammelt Belege, Grok greift Annahmen an, Codex führt nur begrenzte Experimente aus | | Frontend Experience | Nutzerabläufe, Gestaltung, responsives Verhalten, Barrierefreiheit und Browserabnahme | Gemini erstellt die Ausgangsbasis, Codex implementiert, Gemini prüft die reale Seite | Squads werden nicht nach Repositories aufgeteilt und entstehen auch nicht allein wegen eines neuen Modells. Ein neues Repository ist lediglich eine neue Project-Ressource. Aufgaben mit klarer Zuständigkeit werden direkt dem entsprechenden Agent zugewiesen. Nur wenn mehrere Fähigkeiten nötig sind und bei der Issue-Erstellung noch kein konkreter Verantwortlicher feststeht, geht die Aufgabe an einen Squad. Auch diese Konfiguration hat harte Grenzen. Jede Aufgabe hat genau einen aktuellen Verantwortlichen. Jeder Worktree hat genau einen schreibenden Agent. Schreibende Agents haben eine Parallelität von 1, nicht schreibende Rollen können 2 haben, der lokale Daemon insgesamt höchstens 3. Produktion, Zugangsdaten, Veröffentlichungen, externe Sendungen und irreversible Aktionen genehmige immer ich. ## Immer nur die kleinste nötige Rollenmenge aktivieren Ein Agent-Team wird leicht so verstanden, als müssten bei jeder Aufgabe alle Modelle mitarbeiten. Meist erhöht das nur Kontext-, Token- und Koordinationskosten. Ein Multica-Squad ist zunächst nur ein Routingobjekt. Wird ihm ein Issue zugewiesen, weckt das System zuerst den Leader. Dieser liest den Kontext und entscheidet, an wen es weitergeht. Der Squad führt nicht automatisch alle Mitglieder aus und erhöht auch nicht die Parallelität. Meine Standardregel lautet deshalb: Pro Aufgabe wird nur die kleinste ausreichende Rollenmenge geweckt. Eine kleine Reparatur mit klaren Grenzen kann direkt an Codex gehen, ohne einen Squad zu starten. In einem unbekannten großen Repository oder bei einer UI-Aufgabe erstellt Gemini zuerst eine Übersicht der Auswirkungen und eine Abnahmebasis; danach übernimmt Codex. Erst schwer reproduzierbare Fehler oder riskante Diffs rechtfertigen Groks adversariales Review. Standardmäßig sind höchstens zwei ausführende Mitglieder gleichzeitig aktiv. Parallelität nutze ich nur für unabhängige Untersuchungen, unabhängige Reviews desselben stabilen Commits oder Worktrees mit vollständig getrennten Dateibereichen. Wenn mehrere Agents denselben Zustand gleichzeitig ändern, sieht das zunächst schneller aus, endet aber meist in Konflikten und Nacharbeit. Die Zahl der Agents misst nicht die Reife des Teams. Koordinationsfähigkeit zeigt sich darin, zur richtigen Zeit die richtige Rolle zu aktivieren. ## Die DoD ist die Schnittstelle zwischen Agents Direkte Zusammenarbeit zwischen Agents bedeutet nicht, dass eine Übergabe mit „Mach du weiter“ auskommt. Ich verlange bei jeder Delegation vier klare Angaben. ``` outcome: 最终可观察结果 evidence: 证明结果的测试、命令、截图、数据或链接 verification: 由谁、用什么方式验收 max_rounds: 最多返工轮数，默认 2 ``` Das ist die Definition of Done. Sie legt den Belegvertrag fest, der erfüllt sein muss, bevor ein Ergebnis angenommen wird. Der Implementation Engineer liefert nicht nur Code, sondern auch den Änderungsumfang, den Commit, Testbefehle und rohe Ergebnisse. Ein unabhängiger Reviewer liest Ziel, Diff und Tests; die Fertigmeldung des Autors gilt nicht als Beleg. Beim Abschluss führt der Leader tatsächliche Ergebnisse, ungeprüfte Punkte, verbleibende Risiken und nötige menschliche Entscheidungen auf. `max_rounds` ist ebenso wichtig. Agents können einander erwähnen, aber das System kann nicht für mich bestimmen, wann die Zusammenarbeit enden sollte. Widersprechen sich die Belege nach zwei Nacharbeitsrunden weiterhin, muss das Team die Schleife beenden und den Konflikt einem Menschen vorlegen. Wenn eine Multica-Aufgabe `completed` anzeigt, bedeutet das nur, dass dieser Agent-Run regulär beendet wurde. Es bedeutet nicht, dass das Ziel des Issues erfüllt ist. Ob die Aufgabe ins Review darf, entscheiden DoD und Belege. Diese Unterscheidung trennt den Laufzustand des Agents vom Erledigungszustand der Arbeit. ## Auch Agent-Teams brauchen Konfigurationsengineering Ein noch so guter Rollenprompt beweist nicht, dass das Team in der realen Umgebung funktioniert. Mein Git-Repository ist die maßgebliche Konfigurationsquelle. `config/agents/` enthält Rollenverträge, `config/squad-*.md` Routingregeln und `config/topology.json` Agents, Runtimes, Rechte, Parallelität und die Squad-Topologie. Die laufenden Multica-Objekte sind lediglich Kopien dieser Deklaration. Der Synchronisierer gibt standardmäßig nur einen Änderungsplan aus. Erst nach menschlicher Prüfung wird er angewendet. Ein weiterer Lauf muss anschließend `No changes.` melden. Nicht verwaltete Objekte werden nur gemeldet, nicht automatisch gelöscht. Workspace-IDs, Agent-IDs, Tokens, Webhooks und lokale Pfade bleiben außerhalb des Repositories. Das verhindert Konfigurationsdrift. Wenn Rollen und Routing sich ändern, sehe ich ein Diff, kann es prüfen und den laufenden Zustand wieder mit dem Sollzustand abgleichen. Die praktische Anbindung zeigte mir auch, dass ein Agent-Team weit mehr als einige Prompts ist. Der Leader muss Multicas Steuerungsebene bedienen, darf aber keine Projektdateien schreiben. Grok braucht reine Leserechte für Reviews und darf nicht zu weit gefasste Netzwerk- und Schreibrechte erben. Desktop-Runtimes hängen zudem von Proxys, Sandbox, Befehlsargumenten und lokaler Umgebung ab. Nachdem diese Probleme nacheinander sichtbar wurden, korrigierte ich die direkte Verbindung zur Steuerungsebene, Sandbox-Grenzen und die Zuordnung von CLI-Unterbefehlen. Eine Erlaubnis in einer Konfigurationsdatei beweist keine funktionierende Runtime. Jede Schlüsselrolle braucht echte positive und negative Smoke-Tests. ## Die fünf Stufen aus Sicht des Agent-Teams Aus dieser Perspektive bedeuten die fünf Stufen vor allem, dass Verantwortung für Routing, Zusammenarbeit und Abnahme schrittweise vom Menschen auf das System übergeht. | Ebene | Organisation der Agents | Hauptarbeit des Menschen | | ----- | -------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | | L0 | Agents erreichen die reale Arbeit nicht | Mit bisherigen Abläufen weiterarbeiten | | L1 | Mehrere unabhängige Werkzeuge; der Mensch ist der einzige Router | Kontext einzeln liefern und jedes Ergebnis prüfen | | L2 | Dauerhafte Rollen und Squads; der Leader wählt das kleinste Team | Ziele und DoD definieren, Belege abnehmen, zentrale Entscheidungen treffen | | L3 | Zeitpläne oder Ereignisse lösen Agent-Teams aus | Ausnahmen, Rechte, Budgets und Abbruchbedingungen verwalten | | L4 | Mehrere Teams folgen Absichten; Organisationsstrukturen passen sich dynamisch an | Richtung, Werte und nicht delegierbare Grenzen bestimmen | Ich selbst befinde mich derzeit zwischen L2 und L3. Meine Multica-Konfiguration löst Rollen-, Routing-, Beleg- und Beobachtbarkeitsfragen. Die meisten Aufgaben erstelle ich aber noch selbst. Die entscheidende Veränderung auf L3 betrifft das Auslösen von Arbeit. Multicas [Autopilot](https://multica.ai/docs/autopilots) kann aus periodischen Aufgaben oder Webhook-Ereignissen automatisch Issues erzeugen und an Agents oder Squads übergeben. In [„Auch der Mac eines Builders braucht einen Sweeper“](https://weekly-essay.mikey.wang/de/2026/w32-a-builders-mac-also-needs-a-sweeper) beschrieb ich bereits tägliche Routinen zur Skill-Pflege und wöchentliche Prüfungen meiner Mac-Umgebung. Solche Arbeit liegt näher an L3. Die Befugnis zum Auslösen darf der Prüffähigkeit aber nicht vorauslaufen. Ohne DoD, Belege, Rechte, Abbruchbedingungen und beobachtbare Aufzeichnungen sorgt das automatische Wecken weiterer Agents nur dafür, dass Fehler früher geschehen und schwerer auffallen. Unser Team arbeitet insgesamt noch überwiegend auf L1. Die meisten stehen im Übergang von L1 zu L2. Alle können bereits Agents nutzen. Als Nächstes müssen Rollen, Routing, Abnahme und Rechte zu einem gemeinsamen Arbeitssystem werden.