Team Topologies für Teams aus Menschen und Agenten: Wo Agenten tatsächlich hineingehören

Von Victor Hoang · Aktualisiert am 22. September 2026

Team Topologies ist das Rahmenwerk von Matthew Skelton und Manuel Pais, das Teams um vier Typen herum organisiert (Stream-aligned, Enabling, Complicated-Subsystem und Platform), damit Arbeit mit möglichst wenig Koordinationsaufwand fließt. Auf Teams angewandt, in denen ein KI-Agent einen Teil der Arbeit übernimmt, gelten die vier Typen weiterhin, aber zwei Dinge ändern sich: Die kognitive Last bekommt eine neue Kategorie (Verantwortung für Ergebnisse, die man nicht selbst erstellt hat), und das Conway-Gesetz gilt nun für ein System, in dem ein Teil des „Teams“, das die Arbeit erledigt, Software ist und nicht nur Menschen. Das ist die strukturelle Hälfte eines größeren Wandels, den was ist die Zukunft der Arbeit behandelt.

Wichtige Fakten

• Team Topologies definiert vier grundlegende Teamtypen: Stream-aligned (ausgerichtet auf einen Fluss geschäftlichen Werts), Enabling (hilft einem Stream-aligned Team, Hindernisse zu überwinden, und erkennt fehlende Fähigkeiten), Complicated-Subsystem (verantwortet Arbeit, die tiefe Spezial- oder mathematische Expertise erfordert) und Platform (stellt ein überzeugendes internes Produkt bereit, das Stream-aligned Teams beschleunigt). Quelle: Team Topologies, "Key concepts and practices"
• Melvin Conways Aufsatz von 1968 formulierte die ursprüngliche These: „Jede Organisation, die ein System entwirft ... wird unweigerlich einen Entwurf hervorbringen, dessen Struktur eine Kopie der Kommunikationsstruktur der Organisation ist.“ Er merkte auch an, dass die möglichen Kommunikationswege in einer Gruppe ungefähr mit dem Quadrat ihrer Größe wachsen. Quelle: Melvin Conway, "How Do Committees Invent?" (Datamation, 1968)
• In DORAs Forschung 2025 haben 90 % der Organisationen mindestens eine interne Plattform eingeführt, und der Bericht fand einen direkten Zusammenhang zwischen hoher Plattformqualität und der Fähigkeit einer Organisation, aus der KI-Einführung Nutzen zu ziehen. Quelle: Google Cloud, Ankündigung des DORA Report 2025
• Microsofts Work Trend Index 2026 stellte fest, dass organisatorische Faktoren (Kultur, Unterstützung durch Führungskräfte und Talentpraktiken) die gemessene Wirkung auf KI-Ergebnisse mehr als doppelt so stark erklären wie individuelle Faktoren, und identifizierte „Frontier“-Fachkräfte, bei denen sich individuelle Fähigkeit und organisatorische Bereitschaft gegenseitig verstärken, als rund 19 % der befragten KI-nutzenden Belegschaft. Quelle: Microsoft WorkLab, "2026 Work Trend Index"

Was Team Topologies tatsächlich sagt

Skelton und Pais entwickelten Team Topologies für ein konkretes Problem: Organigramme werden meist entlang von Berichtslinien gezeichnet und nicht danach, wie Arbeit tatsächlich fließt, und diese Diskrepanz zeigt sich in langsamen Deployments, unklarer Verantwortung und Teams, die ohne die Freigabe von drei anderen Teams nichts ausliefern können. Ihre Antwort lautet, sich an genau vier Teamtypen auszurichten und bewusst zu gestalten, wie diese Teams interagieren, statt Interaktionsmuster zufällig entstehen zu lassen.

Ein Stream-aligned Team verantwortet einen Ausschnitt geschäftlichen Werts von Anfang bis Ende und ist darauf ausgelegt, ihn mit minimalen Übergaben zu liefern. Ein Enabling Team existiert, um eine Fähigkeitslücke in einem anderen Team gezielt und befristet zu schließen und sich zurückzuziehen, sobald die Lücke geschlossen ist. Ein Complicated-Subsystem-Team übernimmt den Teil des Systems, der wirklich tiefe, enge Expertise braucht (die Payment-Engine, das Empfehlungsmodell, den Preisalgorithmus), damit nicht jedes Stream-aligned Team seinen eigenen Spezialisten benötigt. Ein Platform-Team baut das interne Produkt, die gemeinsame Infrastruktur, das Tooling und die Self-Service-Fähigkeit, mit denen Stream-aligned Teams schnell vorankommen, ohne dieselbe Basisinfrastruktur fünfmal neu zu erfinden.

Nichts an diesem Vokabular muss sich ändern, um ein Team zu beschreiben, in dem ein Teil der „Arbeit“ von einem KI-Agenten statt von einem Menschen erledigt wird. Zu ergänzen ist eine klare Antwort auf zwei Fragen, für die Skelton und Pais nicht geschrieben haben: Wo sitzt die Arbeit des Agenten innerhalb dieser vier Typen, und was geschieht mit der kognitiven Last, wenn ein Mensch für Ergebnisse verantwortlich ist, die er nicht selbst erstellt hat.

Kognitive Last war immer die eigentliche Grenze

Team Topologies behandelt Teamgröße und Zuständigkeitsumfang als Folge einer einzigen Variablen: der kognitiven Last, also der gesamten mentalen Anstrengung, die ein Team aufrechterhalten kann, bevor Qualität und Tempo gleichermaßen leiden. Ein Stream-aligned Team, dem eine fünfte, unzusammenhängende Verantwortung aufgebürdet wird, wird dadurch nicht leistungsfähiger, sondern bei allen fünf langsamer und schludriger. Deshalb besteht das Rahmenwerk auf enge, klar abgegrenzte Teamverantwortung statt auf breite.

Agenten verändern, was dieses Budget füllt, ohne die Gesamtsumme zwingend zu senken. Ein Team, das seine kognitive Last früher auf die Erstellung eines Ergebnisses verwendete, wendet nun einen Teil davon auf, die Aufgabe so präzise zu spezifizieren, dass ein Agent sie versuchen kann, und einen Teil, Ergebnisse zu prüfen, die selbstsicher wirken, ob sie nun stimmen oder nicht. Vom Macher zum Orchestrator behandelt diesen Wandel auf der Ebene der Aufgabe einer einzelnen Person. Auf Teamebene bedeutet derselbe Wandel, dass die kognitive Last eines Teams einen neuen Posten hat: die Verantwortungslast, den fortlaufenden Aufwand, eine Entscheidung oder ein Artefakt zu verantworten, das ein Agent und nicht ein Teammitglied erzeugt hat. Wer diesen Posten bei der Dimensionierung eines Teams ignoriert, bekommt ein Stream-aligned Team, das auf dem Papier schlank besetzt aussieht und leise in ungeprüften Agenten-Ergebnissen versinkt.

Wo Agenten in den einzelnen Teamtypen sitzen

Die ehrliche Antwort lautet: Agenten schaffen keinen fünften Teamtyp. Sie verändern die innere Zusammensetzung und die Interaktionslast der vier bestehenden.

Stream-aligned Teams: Der Agent arbeitet im Fluss, ein Mensch verantwortet weiter das Ergebnis

Hier findet heute der Großteil der Agentennutzung statt, und das sollte der Standard bleiben. Ein Agent entwirft den Code, den Kampagnentext, die Support-Antwort oder die erste Analyse, und eine benannte Person im Team bleibt für das Ausgelieferte verantwortlich. Der Zuständigkeitsumfang des Teams ändert sich nicht, wohl aber seine interne Arbeitsteilung. Achten Sie auf schleichende Ausweitung in die andere Richtung: Ein Stream-aligned Team, das nebenbei beginnt, eine eigene Agenten-Infrastruktur (Prompt-Bibliotheken, Evaluierungs-Harnesses, Tool-Konnektoren) zusätzlich zu seiner eigentlichen Produktarbeit zu bauen und zu pflegen, hat eine zweite, unbegrenzte Aufgabe übernommen, für die es sich nie gemeldet hat. Das ist das Muster Augmentierung statt Automatisierung, das wie vorgesehen funktioniert, bis die Infrastrukturarbeit das kognitive Budget des Teams übersteigt.

Enabling Teams: Agenten beschleunigen den Kompetenztransfer, automatisch wird er nicht

Skelton und Pais haben Enabling Teams von Natur aus als befristet angelegt: Sie existieren, um eine konkrete Fähigkeitslücke zu schließen, und lösen sich auf oder ziehen weiter, sobald sie geschlossen ist. Im Kontext von Mensch plus Agent ist dies das Team, das anderen Stream-aligned Teams beibringt, wie sie ein brauchbares Agenten-Briefing schreiben, eine Evaluierungsschwelle setzen und ein plausibles, aber falsches Ergebnis abfangen, bevor es ausgeliefert wird. Die Versuchung besteht darin, ein Enabling Team stillschweigend zu einer dauerhaften Schatten-Plattform werden zu lassen, die die Arbeit erledigt, statt die Kompetenz zu übertragen. Das verfehlt den Zweck und versteckt die reale kognitive Last in einem Team, das niemand am Rahmenwerk misst.

Complicated-Subsystem-Teams: Der Spezialist wird selten ersetzt, seine Reichweite wird erweitert

Ein Complicated-Subsystem-Team existiert, weil ein Teil des Systems wirklich tiefe, schwer zu verteilende Expertise erfordert. Agenten eignen sich schlecht, dieses Subsystem eigenständig zu verantworten, gerade weil das Team deshalb existiert, dass Fehler dort teuer sind und ohne das Spezialwissen kaum zu entdecken. Wo Agenten hier helfen, ist die Reichweite: Ein Spezialist, der zehn KI-entworfene Erstfassungen einer Änderung am Preismodell prüft, nutzt knappe Expertise anders und oft besser als derselbe Spezialist, der alle zehn von Grund auf von Hand baut. Das ist Human-in-the-Loop, der wie vorgesehen funktioniert: Der Spezialist bleibt die letzte Kontrollinstanz, kein Abnick-Automat. Die Kopfzahl des Subsystem-Teams mag schrumpfen oder sein Output wachsen, aber seine Verantwortungsgrenze und sein Prüfstandard sollten sich nicht verschieben.

Platform-Teams: Warum ein internes KI-Plattform-Team fast sofort entsteht

Dies ist der Teamtyp, der am schnellsten wächst, sobald mehr als zwei oder drei Stream-aligned Teams eigenständig Agenten einsetzen. Sich selbst überlassen, löst jedes Team dieselben Probleme getrennt: welches Modell aufgerufen wird, wie Zugangsdaten und Kostenlimits gehandhabt werden, wie protokolliert wird, was ein Agent für Audit-Zwecke getan hat, wie er sicher an interne Daten und Tools angebunden wird. DORAs Forschung 2025 stellte fest, dass dieses Muster nicht auf KI beschränkt ist: 90 % der Organisationen hatten aus diesem Grund bereits mindestens eine interne Plattform eingeführt, und die Plattformqualität sagte direkt voraus, ob die KI-Einführung zu echtem Leistungsgewinn oder zu verstreutem, doppeltem Aufwand wurde.

Ein internes KI-Plattform-Team entsteht aus demselben Grund wie ein gemeinsames DevOps-Plattform-Team: Die Basisinfrastruktur einmal und gut zu bauen und als Self-Service-Fähigkeit anzubieten, schlägt es, wenn jedes Stream-aligned Team seine eigene baut. Typischerweise verantwortet es gemeinsame Anbindungen an Modellanbieter, eine MCP-basierte Interop-Schicht, damit Agenten interne Tools und Daten einheitlich erreichen statt über fünf einmalige Integrationen, Kosten- und Nutzungsleitplanken sowie einen gemeinsamen Evaluierungs- und Logging-Standard, damit niemand die Frage „Woher wissen wir, dass dieses Ergebnis gut genug ist?“ von Grund auf neu erfindet. Es ist auch der natürliche Eigentümer für alles, was mehrere Agenten bei einer Aufgabe koordiniert, die Art gemeinsamer Basisinfrastruktur mit hohem Risiko, die kein einzelnes Stream-aligned Team allein verantworten sollte. Rework hält es auf der Produktseite genauso: Agenten-bezogene Workflows und MCP-Interop zu standardisieren ist Work-Ops-Terrain, weil diese Basisinfrastruktur nicht redundant in jedem Team liegen sollte, das sie berührt.

Das Conway-Gesetz, wenn ein Teil des Teams Software ist

Conways ursprüngliche Beobachtung von 1968 betraf Menschen: Eine Organisation, die ein System entwirft, bringt tendenziell einen Entwurf hervor, der ihre eigene Kommunikationsstruktur spiegelt, weil die Schnittstellen zwischen den Modulen am Ende den Schnittstellen zwischen den Teams entsprechen, die sie gebaut haben. Er wies auch auf etwas weniger Zitiertes, aber ebenso Nützliches hin: Die Zahl möglicher Kommunikationswege in einer Gruppe wächst ungefähr mit dem Quadrat ihrer Größe, genau deshalb erzeugen große, lose koordinierte Gruppen ausufernde, schlecht integrierte Entwürfe.

Diese Logik gilt weiter, sobald ein Agent einen Teil der Arbeit übernimmt. Die Tool-Anbindungen und Zugriffsgrenzen eines Agenten sind selbst eine Schnittstelle, strukturell nicht anders als die API-Grenze zwischen zwei menschlichen Teams. Wenn fünf Stream-aligned Teams jeweils ihre eigene Version von „ein Agent, der das CRM lesen und eine E-Mail entwerfen kann“ aufsetzen, entstehen fünf leicht unterschiedliche Integrationen, fünf Fehlerbilder und fünf Stellen, die eine Sicherheitsprüfung getrennt kontrollieren muss. Das ist das Conway-Gesetz, das genau wie vorhergesagt abläuft, mit dem Tool-Zugriff eines Agenten als Ersatz für einen Kommunikationskanal.

Der nützliche Schritt ist derselbe, den Team Topologies aus Conways ursprünglicher Einsicht übernimmt: das Inverse Conway Maneuver, also die Organisationsstruktur, die man will, bewusst zu formen, um die gewünschte Systemarchitektur zu bekommen, statt die Architektur zufällig zu entdecken, nachdem das Organigramm schon feststeht. Ist das Ziel ein kohärenter, prüfbarer Weg, wie Agenten sich mit internen Systemen verbinden, muss die Organisation eine klare Grenze ziehen (meist das Platform-Team), die diese Schnittstelle verantwortet, statt fünf Stream-aligned Teams jeweils unabhängig neu erfinden zu lassen und das entstehende Chaos „Flexibilität“ zu nennen.

Vier Teammuster für die Arbeit von Mensch und Agent

Nichts davon sind Vorschriften zum exakten Nachbauen. Es sind wiedererkennbare Formen, und die meisten Organisationen werden mehr als eine gleichzeitig betreiben, in unterschiedlichen Reifegraden.

Eine nützliche Diagnose: Wenn Sie nicht sagen können, in welcher dieser vier Formen ein bestimmtes Stück Agentenarbeit gerade sitzt, ist das meist das eigentliche Problem, nicht das verwendete Modell oder der Prompt, den jemand geschrieben hat.

Anzeichen, dass Ihre Topologie nicht Schritt gehalten hat

Einige Symptome zeigen sich zuverlässig in Organisationen, die Agenten in ihre Workflows aufgenommen haben, ohne die Teamstruktur zu überprüfen:

• Stille Duplikation. Mehrere Stream-aligned Teams haben jeweils ihre eigene Version derselben Agenten-Fähigkeit gebaut, weil es kein Platform-Team gibt, das sie einmal anbietet. Das ist das fragmentierte Conway-Muster von oben, und es zeigt sich meist zuerst als Befund einer Sicherheitsprüfung, die fünf verschiedene Wege findet, wie Agenten dieselbe Kundendatenbank berühren.
• Unsichtbare Verantwortungslast. Der Stellenplan eines Teams spiegelt weiter „wie viel Arbeit dieses Team erzeugen kann“, ohne die Zeit zu berücksichtigen, die inzwischen für die Prüfung von Agenten-Ergebnissen draufgeht. Das ist die Teamversion des KI-Produktivitätsparadoxons: Die Aktivität steigt, während sich der vertrauenswürdige Durchsatz nicht so bewegt, wie es die Aktivitätskennzahlen nahelegen.
• Ein Enabling Team, das nie geht. Ein befristeter Kompetenztransfer ist stillschweigend zu einem Team geworden, das die Agentenarbeit für alle anderen erledigt, was den Sinn eines Enabling Teams verfehlt und realen Personalbedarf in einem Team versteckt, das niemand an seinem tatsächlichen Umfang misst.
• Eine überschrittene Subsystem-Grenze. Jemand außerhalb des Spezialistenteams hat begonnen, mit einem Agenten Ergebnisse in einem Bereich zu erzeugen, der früher die Freigabe des Subsystem-Teams erforderte, und niemand hat aktualisiert, wer für das Ergebnis tatsächlich verantwortlich ist.

So fangen Sie an

Die Reihenfolge zählt weniger, als es bewusst zu tun, statt es zufällig geschehen zu lassen:

1. Ordnen Sie die aktuellen Teams den vier Typen zu, ehrlich und nicht wunschgetrieben. Die meisten Organisationen stellen fest, dass in zwei oder drei Stream-aligned Teams bereits informell Plattformarbeit stattfindet, unbenannt und unkoordiniert.
2. Fragen Sie, wo sich die Verantwortungslast verschoben hat, und gleichen Sie das mit der tatsächlichen Besetzung ab. Ist die Prüfzeit gewachsen und die Kopfzahl nicht, ist die reale kognitive Last dieses Teams höher, als sein Organigramm nahelegt.
3. Entscheiden Sie bewusst, wann sich ein Platform-Team lohnt. DORAs Befund, dass die Plattformqualität den organisatorischen Ertrag von KI vorhersagt, ist ein nützlicher Bauchcheck: Sichtbare Duplikation über Teams hinweg bedeutet meist, dass sich die Investition selbst trägt.
4. Geben Sie Enabling Teams eine Ausstiegsbedingung, bevor sie beginnen. Legen Sie vorab fest, wie „die Lücke ist geschlossen“ aussieht, damit das Team einen natürlichen Zeitpunkt zur Auflösung hat, statt eine dauerhafte, nirgends erfasste Funktion zu werden.
5. Schützen Sie die Complicated-Subsystem-Grenze ausdrücklich. Halten Sie schriftlich fest, welche Entscheidungen weiter die Freigabe des Spezialistenteams brauchen, unabhängig davon, was den ersten Entwurf erzeugt hat, und behandeln Sie das Umgehen dieser Grenze als Vorfall, nicht als Effizienzgewinn.

Nichts davon ist eine einmalige Reorganisation. Microsofts eigene Rahmung der Rolle des „Agent Boss“ und der Frontier Firm behandelt die Struktur aus Mensch und Agent als fortlaufende betriebliche Frage, nicht als einmal gezeichnetes und abgelegtes Diagramm, und eine KI-bereite Kultur aufzubauen verhindert, dass sie binnen eines Quartals in alte Gewohnheiten zurückfällt. Mensch-Agenten-Teams behandeln bereits die Seite von Normen und Vertrauen in diesem Wandel, wie Menschen im Alltag Arbeitsbeziehungen zu Agenten aufbauen. Dies hier ist die strukturelle Hälfte desselben Problems, und beide funktionieren nur, wenn jemand die Entscheidung zum Organisationsdesign tatsächlich verantwortet, statt dass jedes Team seine eigene Antwort improvisiert.

Ein Teamdiagramm, das nach dem Auftauchen von Agenten nie neu gezeichnet wird, ist nicht neutral. Die Duplikation, die nicht erfasste Prüfzeit und die unklare Verantwortung entstehen trotzdem, leise, innerhalb jener Struktur, die schon da war, bevor jemand auf die Idee kam, die Frage bewusst zu stellen.