--- title: "Ein KI-System wächst nicht in die Breite, sondern nach oben" description: "Wenn ein KI-System wächst, denken alle an mehr Agenten. Der eigentliche Sprung ist eine Ebene darüber: Aufträge, Abnahmekriterien, Prüfung am Beweis." author: "Matthias Meyer" published: 2026-08-16 updated: 2026-08-16 language: de tags: ["ki-agenten", "supervisor", "orchestrierung", "agenten-flotte", "claude-code"] canonical: "https://studiomeyer.io/de/blog/vom-orchestrator-zum-supervisor" markdown_versions: ["https://studiomeyer.io/de/blog/vom-orchestrator-zum-supervisor.md", "https://studiomeyer.io/en/blog/vom-orchestrator-zum-supervisor.md", "https://studiomeyer.io/es/blog/vom-orchestrator-zum-supervisor.md"] publisher: "StudioMeyer, https://studiomeyer.io (llms.txt: https://studiomeyer.io/llms.txt)" --- # Ein KI-System wächst nicht in die Breite, sondern nach oben Mehr Agenten, mehr Abläufe, mehr Automatisierung. Eine Zeit lang funktioniert das. Dann kommt der Punkt, an dem mehr von allem nichts mehr besser macht. Bei uns kam der nächste Sprung nicht durch mehr. Er kam durch eine Ebene darüber. ## In die Breite waren wir schon gewachsen Die Flotte lief lange vor diesem Umbau. Orchestratoren steuerten sie: Cron-getrieben, Pipelines in TypeScript, kleine Sprachmodelle für die Triage, die eingehende Mails sortierten und Berichte bündelten. Eine Generation hatte einen Dirigenten, der eine Handvoll Spezialisten befragte, jeder mit genau einem exklusiven Werkzeug-Anschluss. Das war kein Provisorium. Es lief günstig, zuverlässig und unauffällig, jede Nacht, und das meiste davon läuft bis heute. Diese Bauform hatte eine bewusste Grenze. Die Arbeiter bekamen Text und gaben Text zurück, und für Sortieren, Bündeln und Melden ist genau das richtig. Echte Eingriffe dagegen, Code ändern, etwas messen, eine Behauptung prüfen, verlangten einen Ablauf, der jeden Schritt vorwegnahm. Auch das haben wir gebaut. Nur wächst ein System in dieser Form nicht weiter, es wird nur voller. Jede neue Fähigkeit ist ein neuer Ablauf, jeder neue Ablauf eine neue Stelle, an der jemand nachziehen muss, wenn sich etwas ändert. ## Dann machte die Technik einen Sprung Agenten, die einem Projekt unterstehen, können heute selbst handeln: eine Datei öffnen und ändern, einen Browser steuern, einen Test fahren und lesen, was er ausgibt. Sie binden Dienste und Datenquellen über MCP an, einen offenen Standard, mit dem sich ein Programm an externe Werkzeuge anschließen lässt, und sie starten jede Aufgabe mit einem passenden Ausschnitt aus dem Gedächtnis des Systems. Das alles läuft innerhalb von Claude Code. Ein kleines Setup nimmt so einen Sprung mit, indem es ein paar Skripte tauscht. Ein System mit laufender Flotte nutzt ihn anders: Es wächst nach oben. ## Aus Steuern wird Beauftragen Sobald die Arbeiter selbst handeln können, verschenkt Vorplanen Fähigkeit. Wer den Weg vorschreibt, bekommt genau den Weg, den er sich vorher ausgedacht hat, und nie den besseren, den der Agent vor Ort gesehen hätte. Der Orchestrator plante einen Ablauf. Der Supervisor vergibt einen Auftrag. Das ist nicht dasselbe. Nebeneinandergelegt wird der Unterschied greifbar: | | Orchestrator | Supervisor | |---|---|---| | Verteilt | eine Abfolge von Schritten | einen Auftrag | | Der Agent bekommt | eine Anweisung nach der anderen | Rahmen, Regeln, Abnahmekriterien | | Es kommt zurück | Text | ein Ergebnis plus Beleg | | Bei Unklarheit | muss die Ausnahme im Ablauf vorgesehen sein | greift die Stopp-Bedingung: der Agent fragt zurück | Der Preis dafür ist Sorgfalt an einer neuen Stelle. Ein schlecht geschnürter Auftrag ist schlimmer als ein schlecht geplanter Ablauf, weil niemand mehr dazwischensteht und die Lücke im Vorbeigehen füllt. ## Was in einem Auftrag steht Ein Auftrag ist kein Satz. Er ist ein Paket, und was für die Ausführung verbindlich sein soll, muss darin stehen. Er nennt das Ziel und, genauso ausdrücklich, die Nicht-Ziele. Der Umfang ist, was dasteht, nicht was vollständig wäre. Er nennt die Entscheidungen, die schon feststehen, damit der Agent sie weder neu diskutiert noch nachträglich erfindet. Er nennt die Dateien, die ihm gehören, und bei paralleler Arbeit gehören zwei Agenten niemals dieselben, notfalls arbeitet jeder in einer eigenen Kopie. Er nennt die erlaubten Werkzeuge, denn alles, was nicht ausdrücklich erlaubt ist, gilt als nicht erlaubt, und das zählt besonders bei allem, was Geld kostet oder nach außen wirkt. Dazu kommt der Teil, an dem sich später entscheidet, ob der Auftrag etwas taugte. Die Abnahmekriterien sind so formuliert, dass man sie nachrechnen kann: erfüllt ist es, wenn dieses Kommando dieses Ergebnis zeigt, nicht wenn es rund aussieht. Die geforderten Prüfungen stehen namentlich drin, mitsamt der Pflicht, ihre Ausgabe im Bericht zu zitieren. Die Stopp-Bedingungen sagen, wann der Agent anhält und zurückfragt statt zu raten, bei fehlenden Daten, bei einem Widerspruch zum Umfang, bei einer Regel, die im Weg steht. Und am Ende stehen die Sperren, also das, was unter keinen Umständen passiert, wie sinnvoll es dem Agenten im Moment auch erscheinen mag. Was der Auftraggeber noch nicht entschieden hat, wird vor dem Auftrag geklärt. Nicht unterwegs vom Agenten erraten, und auch nicht nach unten durchgereicht nach dem Muster: falls du Gründe dagegen findest, brich ab. Diese Regel kam aus der Praxis, nicht aus einem Handbuch. Sie ist die unbequemste von allen, weil sie den Supervisor zwingt, zu Ende zu denken, bevor er delegiert. ## Alles, was gelten soll, reist im Auftrag mit Ein untergeordneter Agent startet nicht mit dem Wissen des Projekts im Kopf. Er kennt die Hausregeln nicht, die für die Hauptsitzung selbstverständlich sind. Wer das übersieht, delegiert an jemanden, der alle Vorgaben des Hauses nicht kennt, und wundert sich über das Ergebnis. Deshalb trennen wir zwei Dinge: Kontext darf aus dem Gedächtnis des Systems kommen, Wissen, Vorarbeiten, Zusammenhänge. Was verbindlich gelten soll, steht im Auftrag oder gilt nicht. Das ist unbequem und wirkt beim ersten Mal wie Bürokratie. Es ist der Unterschied zwischen einem Team, das man führt, und einer Reihe von Zufallsergebnissen. ## Geprüft wird am Beweis, nicht an der Auskunft Ob etwas wirklich fertig ist, wird am Beweis geprüft: am tatsächlichen Änderungsstand, an ausgeführten Tests, an angesehenen Screenshots. Nicht an der Zusammenfassung des Agenten, der es gebaut hat. Ein Bericht, der sagt, alles sei grün, ist eine Behauptung über eine Prüfung, nicht die Prüfung. Wer prüft, bekommt deshalb nur den Auftrag und das Ergebnis, sonst nichts. Keine Selbsteinschätzung des Bauers, kein "ich habe hier bewusst so entschieden". Lob im Vorspann erzeugt beim Prüfer genau die Erwartung, die er nicht haben soll, und dann sieht er, was er erwartet. Intern nennen wir das Blind-Review. Das Ergebnis dieser Trennung ist unspektakulär und genau deshalb wertvoll: Ein Bericht wird gelesen, die behaupteten Änderungen werden angesehen, die Prüfung wird selbst noch einmal gefahren. Erst dann geht die Meldung weiter. ## Wenn ein Projekt ein anderes weckt Der eigentliche Hebel liegt eine Stufe darüber. Ein Supervisor kann nicht nur Agenten innerhalb seiner eigenen Sitzung beauftragen, sondern eine vollwertige Sitzung in einem anderen Projekt starten, die dort alles vorfindet, was zu diesem Projekt gehört: dessen Regeln, dessen Schutzmechanismen, dessen Werkzeuge, dessen Gedächtnis. Damit ändert sich die Arbeitsteilung. Der Supervisor muss das fremde Projekt nicht mehr im Detail kennen. Er schreibt auf, was zu tun ist und was dabei gilt, weckt die Sitzung, die dort zuhause ist, und prüft, was zurückkommt. Das Fachwissen bleibt, wo es hingehört, und die Führung bleibt, wo sie hingehört. Ein solcher Auftrag trägt immer dieselben Sperren: den kleinstmöglichen Eingriff, nichts veröffentlichen, nichts ausliefern, die Prüfung als Beweis, eine einzige saubere Zusammenfassung der Änderung, ein Bericht als Datei statt als Zuruf. Was ausgeliefert wird, entscheidet ein Mensch, jedes Mal. ## Jedes Projekt führt sein eigenes Team Bauen, prüfen, texten, recherchieren, absichern: Das sind Rollen, keine Stellen, die an eine Person oder ein Modell gebunden sind, und jedes Projekt nimmt sich aus diesem Baukasten, was es braucht. Der Vorteil zeigt sich beim Ändern. Eine Rolle wird an einer Stelle geschärft und wirkt überall, statt in jedem Projekt neu erfunden zu werden. Darüber haben wir noch eine Schicht gebaut, die selbst nichts baut, sondern das System beobachtet und vermisst: was wächst, was auseinanderläuft, wo eine Regel etwas behauptet, das nicht mehr stimmt. Diese Position musste sie sich verdienen. Vorerst beobachtet und meldet sie nur, mehr Automatik kommt Schritt für Schritt. Auch das ist Wachstum nach oben, nicht in die Breite. ## Kein Dirigent über den Dirigenten Was wir bewusst nicht gebaut haben, ist ein zentraler Verteiler, der jeden Auftrag über alle Projekte hinweg entgegennimmt und zuteilt. Das wäre die naheliegende Krönung gewesen und der Punkt, an dem das System kippt. Jedes Projekt behält die Hoheit über seine eigene Arbeit. Die Schicht darüber beobachtet, sie verteilt nicht. Ein Projekt, das nicht mehr selbst entscheidet, was mit seinen eigenen Aufträgen passiert, ist nicht mehr das, das dafür verantwortlich ist. Und Verantwortung, die niemandem mehr zuzuordnen ist, war noch nie ein Fortschritt, sondern immer nur eine Ebene mehr. ## Weiterlesen, Agent-Flotten - [AutoML für Agent Fleets, ohne die Vendor-Rechnung](https://studiomeyer.io/de/blog/automl-for-agent-fleets-without-the-vendor-bill.md) - [Drei Tools, drei Schichten: Sentry, Langfuse und LangGraph für Multi-Agent-Fleets](https://studiomeyer.io/de/blog/agent-fleet-observability-stack-2026.md) - [Das CrewAI-5,76x-Paradox: Was Framework-Benchmarks dir nicht sagen](https://studiomeyer.io/de/blog/crewai-5x-benchmark-paradox.md) - [StudioMeyer Crew: 8 Experten-Personas für Claude ohne extra API-Kosten](https://studiomeyer.io/de/blog/mcp-crew-agent-personas.md)