Vom Macher zum Orchestrator: Wie KI die Rolle des Individual Contributors neu schreibt

Von Victor Hoang · Aktualisiert am 22. September 2026

Die Orchestrator-Rolle ist das, was die Arbeit eines Individual Contributors wird, sobald KI-Agents einen wachsenden Teil der Ausführung übernehmen. Statt den Output selbst zu erzeugen, definiert die Person das Problem, formuliert das Briefing, entscheidet, was abgegeben wird, und prüft das Ergebnis. Sie tauscht „die Arbeit erledigen“ gegen „Verantwortung für Arbeit, die jemand anderes oder etwas anderes erledigt hat“.

Das klingt nach einer Beförderung. In der Praxis ist es eine andere Aufgabe mit anspruchsvolleren Kompetenzen, und die meisten ICs wurden darauf nicht vorbereitet.

Wichtige Fakten

• 36 % der Führungskräfte erwarten, dass ihre Teams innerhalb von fünf Jahren KI-Agents steuern werden, und 67 % der Führungskräfte sagen, sie seien bereits mit Agents vertraut, gegenüber 40 % der Mitarbeitenden. Quelle: Microsoft, „The 2025 Annual Work Trend Index“
• In einer kontrollierten Studie mit 758 BCG-Beratern erledigten diejenigen, die GPT-4 für Aufgaben innerhalb der Leistungsgrenze der KI nutzten, 12,2 % mehr Aufgaben, arbeiteten 25 % schneller und lieferten Ergebnisse, die in der Qualität 40 % höher bewertet wurden als die einer Kontrollgruppe ohne KI. Quelle: Harvard Business School AI Institute, „Navigating the Jagged Technological Frontier“
• Bei Aufgaben außerhalb dieser Grenze lag die Wahrscheinlichkeit einer korrekten Empfehlung bei denselben Beratern mit KI rund 19 Prozentpunkte niedriger als in der Kontrollgruppe, die allein auf 84,5 % Korrektheit kam. Quelle: Karim Lakhani, HBS, zur Jagged-Frontier-Studie
• 95 % der generativen KI-Pilotprojekte in Unternehmen brachten laut MITs Project NANDA keine messbare Wirkung auf die Gewinn- und Verlustrechnung. Quelle: Fortune, über MIT Project NANDA
• Mehr Prüfaufwand verringert messbar den „Automation Bias“, die Neigung, das Ergebnis eines automatisierten Systems ohne kritische Prüfung zu übernehmen, selbst wenn es falsch ist. Quelle: Microsoft Research, „Overreliance on AI: Literature Review“

Die Arbeit ist nicht geschrumpft, sie hat sich verlagert

Die Frontier Firm und der Aufstieg des Agent Boss behandelt bereits, wie das auf Organisationsebene aussieht: Microsofts Begriff für Unternehmen, in denen KI-Agents in den täglichen Workflows arbeiten und in denen jede Person am Ende Agents aufbaut, an sie delegiert und sie steuert, so wie früher eine Führungskraft Menschen führte. Dieser Artikel handelt von Kultur und Organigramm. Hier geht es darum, was mit Ihrer konkreten Arbeit geschieht, wenn das für Sie persönlich gilt.

Wenn Sie Code schreiben, Texte entwerfen, Modelle bauen oder Support-Tickets bearbeiten, kann ein Agent inzwischen einen echten Teil des eigentlichen Erzeugens dieser Arbeit versuchen. Nicht perfekt, nicht für alles, aber für einen wachsenden Ausschnitt. Der Teil Ihrer Arbeit, der früher „die Domäne kennen und den Output erzeugen“ hieß, spaltet sich in zwei getrennte Kompetenzen: die Domäne zu kennen und einen Agent zu steuern, der einen ersten Entwurf des Outputs erzeugt.

Der Fehler liegt in der Annahme, die zweite Kompetenz sei eine kleinere Version der ersten, etwas, das man nach ein paar Wochen im Chat-Interface beherrscht. Das ist sie nicht. Eine Aufgabe so präzise zu spezifizieren, dass ein Agent sie korrekt ausführt, und dann die Fehler abzufangen, beansprucht einen anderen Teil Ihrer Expertise als das eigenhändige Erledigen der Aufgabe. Mensch-Agent-Teams funktionieren gut, wenn die Beteiligten diesen Unterschied verstehen, und schlecht, wenn alle annehmen, dass Kompetenz im Erledigen der Arbeit automatisch zu Kompetenz im Steuern übergeht. Teamtopologien für Teams aus Mensch und Agent hebt diesen Wandel auf die nächste Ebene: dorthin, wo ein Agent tatsächlich in der Struktur eines Teams sitzt, statt nur auf der Aufgabenliste einer einzelnen Person.

Was „Orchestrator“ tatsächlich bedeutet

Zwei Verschiebungen definieren die Rolle. Sie sind leicht zu benennen und schwer zu leben.

Vom Erzeugen zum Spezifizieren

Der primäre Output des Orchestrators ist nicht mehr das Arbeitsergebnis. Es ist das Briefing: die Problemstellung, die Rahmenbedingungen, Beispiele dafür, wie „fertig“ aussieht, und die Grenzen dessen, was der Agent selbst entscheiden darf. Ist das Briefing falsch, ist der Output falsch, egal wie leistungsfähig das zugrunde liegende Modell ist. Es ist dieselbe Disziplin wie Prompt Engineering, nur hochskaliert von einer einzelnen cleveren Anweisung zu einer dauerhaften, wiederverwendbaren Spezifikation, die beim fünften und beim fünfzigsten Mal funktionieren muss, nicht nur beim ersten.

Vom Erledigen zum Prüfen, mit echtem Einsatz

Den Output eines Agents zu prüfen ist nicht dasselbe, wie die Arbeit eines Junior-Kollegen zu prüfen, und beides gleichzusetzen gehört zu den häufigeren Fehlern. Ein Junior-Kollege, der etwas nicht weiß, sagt das meist oder liefert etwas, das sichtbar unfertig wirkt. Ein leistungsfähiges Modell liefert selbstsicheren, sauber formatierten, plausibel klingenden Output, ob er stimmt oder nicht, eine Lücke, die in der Branche als KI-Halluzination bekannt ist. Die Skepsis, die das Ergebnis selbst nicht signalisiert, muss der Orchestrator liefern.

Die vier Kernkompetenzen der Orchestrator-Rolle

1. Problemzerlegung

Bevor Sie eine Aufgabe an einen Agent übergeben können, müssen Sie sie in Teile zerlegen, die klein und klar genug sind, dass sich „richtig“ und „falsch“ prüfen lassen. Eine vage Bitte wie „verbessere diesen Prozess“ lässt sich an niemanden delegieren, weder an Menschen noch an Agents. Eine zerlegte Fassung, „identifiziere die drei Schritte dieses Prozesses mit der längsten Durchlaufzeit und entwirf einen Vorschlag, jeden um 20 % zu verkürzen“, lässt sich delegieren. Das war früher eine Projektmanagement-Kompetenz, die vor allem Leads und Manager einsetzten. Heute ist sie eine Grunderwartung an alle, deren Arbeit das Steuern von agentenbasierten Workflows einschließt.

2. Kontext schaffen

Ein Agent weiß nur, was in seinem Briefing, seinem Training und dem steht, was er abrufen kann. Er kennt nicht die politische Vorgeschichte, warum die letzte Fassung dieses Dokuments abgelehnt wurde, oder welcher Stakeholder tatsächlich ein Vetorecht hat, oder dass „prägnant“ in diesem Unternehmen etwas Bestimmtes bedeutet, weil der CEO lange Memos hasst. Kontext schaffen heißt, das implizite Wissen auszulagern, das Sie sonst ganz selbstverständlich anwenden, damit der Agent keine formal korrekte Arbeit liefert, die aus Gründen scheitert, die er unmöglich kennen konnte. KI-Agents als Teil des Teams führen behandelt dieselbe Eingrenzungsdisziplin als laufende Führungsaufgabe statt als einmaliges Briefing: Qualitätsmaßstäbe, Übergaben und Eskalationswege, die auch nach der ersten Aufgabe weiterfunktionieren.

3. Den Qualitätsmaßstab setzen

„Gut genug“ ist ein Urteil, und es muss getroffen werden, bevor die Arbeit beginnt, nicht danach, sonst wird der Prüfprozess zum Streit mit sich selbst über ein bewegliches Ziel. Den Maßstab zu setzen heißt festzulegen, welche Belege, welches Format, welchen Ton und welche Sorgfalt der Output erfüllen muss, und das so ausdrücklich zu tun, dass eine zweite Person (oder ein zweiter Agent-Durchlauf) die Arbeit am selben Standard prüfen könnte. Teams, die diesen Schritt auslassen, prüfen tendenziell entweder aus Angst alles zu streng oder aus Erschöpfung alles zu lasch, und beide Fehlformen zeigen sich in dem lieblosen Massen-Output, den manche Teams inzwischen Workslop nennen.

4. Wissen, wann man es selbst tut

Diese Kompetenz bekommt die geringste Aufmerksamkeit und zählt am meisten. Die Feldstudie von BCG und der Harvard Business School ergab, dass Berater mit KI bei Aufgaben innerhalb der Leistungsgrenze des Modells deutlich besser und bei Aufgaben außerhalb spürbar schlechter waren, und die Grenze selbst ist zerklüftet: Zwei Aufgaben, die für einen Menschen ähnlich schwer wirken, können auf entgegengesetzten Seiten liegen. Die Forschenden fanden außerdem, dass sich Fachleute in unterschiedliche Nutzungsmuster aufteilten. Etwa ein Drittel agierte als „Centaurs“ und zog eine klare Linie zwischen der Arbeit, die sie an die KI abgaben, und der, die sie selbst behielten, und bewahrte so sein Urteilsvermögen für die schwierigere Hälfte. Eine deutlich größere Gruppe mischte KI wahllos in alles. Zu erkennen, um welche Art von Aufgabe es sich handelt, und die Disziplin zu haben, die schwierigen, mehrdeutigen, folgenreichen Teile selbst zu behalten, ist die schwierigste einzelne Abwägung in der Orchestrator-Rolle, denn der Agent versucht die Aufgabe in jedem Fall und sagt selten, dass sie ihn überfordert.

Alte IC-Kompetenz vs. neues Orchestrierungs-Pendant

Direkte Produktion baut das Arbeitsergebnis; Orchestrierung definiert die Aufgabe, delegiert die Ausführung und prüft das Ergebnis.

Warum das tatsächlich schwerer ist, als es klingt

Es ist verlockend, Orchestrierung für grundsätzlich weniger Arbeit zu halten als das eigenhändige Erledigen. Manchmal stimmt das. Aber drei Dinge machen sie zu einer schwerer aufzubauenden Kompetenz, nicht zu einer leichteren, und dieselbe Obergrenze, die begrenzt, wie viele Personen eine Führungskraft gut betreuen kann, begrenzt auch, wie viele Agents ein Orchestrator wirklich steuern kann, ohne dass die Prüfung oberflächlich wird; Führungsspanne, wenn Agents die Arbeit machen behandelt genau diese Obergrenze.

Die Leistungsgrenze verschiebt sich und ist nicht beschriftet

Nichts auf dem Bildschirm sagt Ihnen, ob die gerade abgegebene Aufgabe innerhalb oder außerhalb der tatsächlichen Leistungsgrenze des Modells liegt. Der Rückgang der Korrektheit um 19 Punkte bei Aufgaben außerhalb der Grenze, den die BCG-Studie zeigte, betraf Berater, die im Schnitt gut in ihrem Job waren und ein führendes Modell nutzten. Das Scheitern war keine Kompetenzlücke im Umgang mit KI. Es war ein Kategorienfehler: eine Aufgabe, die nach Routine aussah, so zu behandeln, als läge sie innerhalb der Grenze, obwohl sie es nicht tat. Das Urteilsvermögen, dies in der eigenen Domäne zu erkennen, erfordert bewusstes Üben, nicht Vertrautheit mit dem Tool.

Prüfen ist eine andere kognitive Belastung als Erzeugen

Beim Erzeugen von Arbeit bleiben Sie die ganze Zeit im Problem; Sie bemerken Unstimmigkeiten sofort, weil Sie die Sache Stück für Stück aufbauen. Das fertige Ergebnis einer anderen Person zu prüfen, ob Mensch oder Agent, bedeutet, dasselbe Verständnis von außen zu rekonstruieren, oft schneller, als Sie es beim ersten Mal aufgebaut haben. Das ist echte kognitive Anstrengung, und sie zu überspringen ist genau der Weg, auf dem überzeugend klingende Fehler durchrutschen. Prüfen ist nicht „weniger Arbeit als Erledigen“. Es ist andere Arbeit, und wer sie als leichte Option behandelt, lässt Orchestrierung unbemerkt scheitern.

Die meisten Organisationen haben die Kompetenz nicht gezielt aufgebaut

MITs Project NANDA stellte fest, dass die meisten generativen KI-Pilotprojekte in Unternehmen nie einen messbaren finanziellen Ertrag brachten, und ein gemeinsamer Nenner der Fehlschläge war nicht das Modell, sondern das Fehlen der organisationalen Lernschleife, die für den guten Einsatz nötig ist: klare Verantwortung, Workflow-Neugestaltung und Menschen, die das Tool wirklich zu steuern wussten, statt nur Zugang dazu zu haben. Die oben genannten Orchestrator-Kompetenzen sind diese fehlende Schleife, angewandt auf die Arbeit einer einzelnen Person. Unternehmen, die den Wandel mit „Tool geben und die Leute selbst herausfinden lassen“ angehen, sparen sich das Training für eine neue Kompetenz und hoffen, dass die alte kostenlos übertragbar ist.

Das Risiko: Prüfer von Arbeit zu werden, die man nicht mehr versteht

Es gibt eine bestimmte Fehlform, die man klar benennen sollte: ein IC, der so viel Ausführung so lange delegiert, dass die eigene praktische Fertigkeit in der zugrunde liegenden Arbeit unbemerkt schwindet, während der Jobtitel weiterhin sagt, er sei dafür verantwortlich.

Das ist die praktische, individuelle Version des Automation Bias, der gut belegten Neigung, das Ergebnis eines automatisierten Systems weniger kritisch zu prüfen, als es verdient, besonders wenn es oft genug richtig lag, um Vertrauen zu gewinnen. Von Microsoft ausgewertete Forschung fand, dass mehr bewusster Prüfaufwand zu den wenigen Maßnahmen gehört, die ihn zuverlässig verringern. Das ist eine konkrete, erlernbare Gewohnheit, keine Charaktereigenschaft, und sie braucht in Teams einen Namen: Jemand muss das erneute Prüfen ausdrücklich verantworten, statt anzunehmen, dass eine Rolle namens „Reviewer“ es von allein sicherstellt.

Das Modell des Ökonomen David Autor dazu, wie Automatisierung mit Expertise zusammenwirkt, zieht hier eine nützliche Linie: Manche Tools machen Expertise überflüssig, andere vervielfachen sie, und was man bekommt, hängt davon ab, wie das Tool eingesetzt wird, nicht vom Tool selbst. Ein Orchestrator, der die schwierigsten 20 % der Arbeit weiterhin persönlich erledigt, den Teil, den das Modell falsch macht, nutzt KI als Multiplikator für sein eigenes Urteilsvermögen. Wer damit unbemerkt ganz aufgehört hat, riskiert, Prüfer einer Domäne zu werden, die er nicht mehr praktiziert, eine brüchige Position, aus der man Verantwortung trägt. Human-in-the-Loop bedeutet nur dann etwas, wenn der betreffende Mensch noch die Autorität hat, zu erkennen, was falsch ist.

Was das für Seniorität und Arbeitszufriedenheit bedeutet

Seniorität ließ sich früher zum Teil daran messen, wie viel Arbeit jemand persönlich und wie schnell erzeugen konnte. Dieses Maß wird unschärfer: Ein Junior-Analyst mit einem gut gebauten Agent-Workflow kann heute ein Volumen an Erstentwürfen liefern, für das früher eine Senior-Person eine ganze Woche brauchte. Nicht so leicht ersetzt wird das Urteil: zu wissen, welche 20 % einer Aufgabe sorgfältig von Hand erledigt werden sollten, zu erkennen, wann die selbstsichere Antwort eines Agents unbemerkt falsch ist, und einen Qualitätsmaßstab so präzise zu setzen, dass der Unterschied überhaupt prüfbar ist. Genau das ist die Expertise, die laut Autor und Thompson vervielfacht wird, statt zu verschwinden, und sie lässt sich schwerer in einen Lebenslauf schreiben als „X Features ausgeliefert“ oder „Y Berichte verfasst“.

Auch die Arbeitszufriedenheit leidet in verwandter Weise, was man ehrlich benennen sollte. Viele Menschen mochten die Arbeit selbst, nicht nur die Verantwortung für das Ergebnis: das Handwerk auf Satzebene, den Flow, etwas von Anfang bis Ende zu bauen, das Rätsel des Modells. Orchestrierung behält die Entscheidungen und nimmt viel von dem weg, was sich nach Flow anfühlte. Ein Teil dieser Zufriedenheit kann zu dem wandern, was bleibt (das Einordnen, die Abwägungen, die Momente, in denen ein echtes Problem auftaucht), aber so zu tun, als wäre der Tausch für alle ein Nullsummenspiel, wäre unehrlich. Psychologische Sicherheit ist hier besonders wichtig, denn zuzugeben „Ich vermisse es, diesen Teil selbst zu machen“ sollte nicht als Widerstand gegen Veränderung gelten.

Wie Führungskräfte den Übergang unterstützen sollten

Keine der vier Kompetenzen oben entsteht automatisch, nur weil jemand Zugang zu einem Agent hat. Führungskräfte, die möchten, dass ihre Teams sie tatsächlich entwickeln, sollten:

• Zerlegung ausdrücklich vermitteln, so wie das Onboarding früher den Umgang mit einem bestimmten Tool vermittelte. Gehen Sie ein paar echte Briefings gemeinsam durch und zeigen Sie, wo eine vage Bitte drei getrennte Entscheidungen verbirgt.
• Zeit für das Prüfen schützen, nicht nur Zeit für mehr Output. Wenn ein Agent die Entwurfszeit halbiert und die gewonnene Zeit vollständig in mehr Volumen fließt, prüft niemand etwas gründlicher.
• Ausdrücklich neu definieren, wie „Senior“-Output in Ihrem Team aussieht, damit Menschen nicht unbemerkt an einem Mengenstandard gemessen werden, der den Wert nicht mehr abbildet. Das ist Organisations- und Bewertungsarbeit ebenso wie Kompetenzarbeit; siehe Aufbau einer KI-bereiten Kultur für die breitere Version dieses Wandels.
• Gezielt Wiederholungen für das Urteilsvermögen aufbauen, nicht nur für die Tool-Nutzung. Lassen Sie Menschen üben, eingebaute Fehler im Agent-Output zu finden, so wie Piloten an simulierten Ausfällen trainieren, statt nur zu fliegen, wenn alles funktioniert.
• Offen aussprechen, dass dies eine andere Aufgabe ist, nicht eine schnellere Version der alten. Die Kompetenzlücke ehrlich zu benennen macht es erst sicher, zuzugeben, dass man sie noch nicht geschlossen hat, und das ist die Voraussetzung dafür, sie wirklich zu schließen.

Stellen Sie sich diese Rolle gut ausgeführt vor: jemand, der weniger Zeit mit dem Tippen des ersten Entwurfs verbringt und mehr Zeit damit, zu entscheiden, was „richtig“ heißt, bevor der Entwurf existiert, und der Ihnen genau sagen kann, für welchen Teil des Outputs er mit seinem Namen einstehen würde und welchen er noch nicht genau genug geprüft hat, um ihm zu trauen. Diese Aufgabe ist schwerer zu besetzen und schwerer auszubilden, aber sie ist die, die jetzt tatsächlich ansteht, und so zu tun, als wäre es dieselbe Aufgabe mit schnellerer Tastatur, ist der Weg, auf dem Teams bei selbstsicherem, ungeprüftem Output landen, für dessen Abfangen niemand so recht zuständig ist.