Fokus ist der neue Engpass: Du kannst nur so viele AI-Agenten einsetzen, wie du kontrollieren kannst

AI-Agenten können den Implementierungsdurchsatz steigern, besonders wenn sich Arbeit in unabhängige, klar spezifizierte Aufgaben teilen lässt. Sie erzeugen aber auch Arbeit für Zerlegung, Kontext, Tool-Zugriff, Review, Integration und Incident Response. Die nützliche Frage ist nicht, wie viele Agenten eine Person theoretisch ausführen kann. Entscheidend ist, wie viel parallele Arbeit das Team innerhalb seiner Risikotoleranz verifizieren und integrieren kann.

Es gibt keine evidenzbasierte universelle Obergrenze wie zwei, fünf oder zehn Agenten pro Operator. Die Kapazität hängt von Arbeit, Modell, Tools, Codebase, Tests, Berechtigungen, Operator und Fehlerfolgen ab. Behandle Parallelität als gemessenen Betriebsparameter. Wenn Agenten verschiedenen Personen gehören, wird Orchestrierung auch zu einer Frage von Identität, Einwilligung und Zustellung; unser Leitfaden zur Kommunikation zwischen Agenten unterschiedlicher Besitzer behandelt diese Vertrauensgrenze.

Was ändert sich, wenn Generierung schneller wird?

Schnellere Generierung kann den Engpass verschieben, ohne ihn zu beseitigen. Teams verbringen möglicherweise weniger Zeit mit dem Schreiben von Code und mehr mit der Entscheidung, was sich ändern soll, dem Bereitstellen von Kontext, der Kontrolle von Tools, dem Review von Verhalten, dem Lösen von Konflikten und dem Nachweis, dass das Ergebnis die Anforderungen erfüllt. Das Verhältnis unterscheidet sich zwischen Routineänderungen, neuartiger Architektur, sicherheitssensibler Arbeit und mehrdeutigen Produktentscheidungen.

Nimm weder an, dass die schwierigste Arbeit einen festen Prozentsatz ausmacht, noch dass ein Operator nun ein Team bestimmter Größe übertrifft. Miss abgeschlossene und akzeptierte Ergebnisse. Generierte Zeilen, Tool-Aufrufe oder Agenten-Turns sind Aktivitätsmetriken und können steigen, während sich Durchlaufzeit, Qualität oder Wartbarkeit verschlechtern.

Wann hilft Parallelität?

Parallele Agenten sind am vielversprechendsten, wenn Teilaufgaben wirklich unabhängig sind, Ein- und Ausgaben explizit feststehen, Tools nicht um gemeinsamen Zustand konkurrieren und sich die Integration kostengünstig prüfen lässt. Ein Orchestrator-Worker-Muster kann auch helfen, wenn die nötigen Teilaufgaben nicht im Voraus bekannt sind. Anthropics Bericht über das eigene Research-System beschreibt Vorteile bei Suchanfragen, die zuerst in die Breite gehen, sowie Herausforderungen bei Koordination, Evaluation, Zuverlässigkeit und Kosten. Die gemeldeten Benchmark- und Geschwindigkeitswerte gelten für dieses System und diesen Workload, nicht als universeller Multiplikator. Siehe den ursprünglichen Engineering-Bericht zum Multi-Agent-Research-System.

Sequenzielle Arbeit ist oft sicherer, wenn Aufgaben dieselben Dateien, Schemas, zustandsbehaftete Umgebungen, Migrationen, Zugangsdaten oder eine ungelöste Architekturentscheidung teilen. Parallelität kann eingeführt werden, sobald Schnittstelle und Integrationstests stabil sind.

Was begrenzt die Orchestrierung?

NIST weist darauf hin, dass generative AI je nach Kontext unterschiedliche Grade an Aufsicht, Mensch-AI-Konfiguration, Review, Tracking, Dokumentation und Management erfordern kann. Das unterstützt risikobasierte Aufsicht, nicht ein festes Verhältnis von Operatoren zu Agenten. Siehe das NIST Generative AI Profile.

Wie misst du sichere Parallelität?

Beginne mit einem Workflow und einem repräsentativen Aufgabensatz. Ermittle die sequenzielle Baseline und erhöhe dann die Parallelität schrittweise, während Aufgabenmix und Akzeptanzkriterien so stabil wie praktisch möglich bleiben. Erfasse:

• die Zeit von der Bereitschaft bis zur Akzeptanz einschließlich Review und Nacharbeit;
• das Alter der Review-Warteschlange und den Zeitaufwand pro Rolle;
• Akzeptanz im ersten Durchlauf und entkommene Defekte nach Schweregrad;
• Merge-Konflikte, doppelte Arbeit, Rollbacks und Incidents;
• Tool-, Modell-, Infrastruktur- und Personalkosten pro akzeptiertem Ergebnis;
• Berechtigungsausnahmen und unbelegte Abschlussbehauptungen;
• Arbeitsbelastung des Operators und Kontinuität bei Übergaben.

Erhöhe die Parallelität nicht weiter, wenn der gesamte akzeptierte Durchsatz stagniert, Review- oder Integrationswarteschlangen das Serviceziel überschreiten oder Risikoindikatoren den vereinbarten Schwellenwert verletzen. Wiederhole die Messung, wenn sich Modell, Tools, Berechtigungen, Codebase, Testsuite oder Aufgabenmix ändern.

Was sollte jede delegierte Aufgabe enthalten?

1. Ziel: das konkrete Ergebnis und warum es wichtig ist.
2. Grenzen: Dateien, Systeme, Personen, Daten und Aktionen innerhalb oder außerhalb des Scopes.
3. Eingaben: verbindliche Quellen, aktueller Zustand, Annahmen und Abhängigkeiten.
4. Berechtigungen: erlaubte Lese- und Schreibzugriffe, Freigabepunkte und verbotene Aktionen.
5. Output-Vertrag: Artefakt, Format, Verantwortung und die Meldung teilweiser Fehler.
6. Akzeptanz: Tests, Review-Kriterien, Evidenz und Rollback- oder Wiederherstellungspfad.
7. Übergabe: geänderter Zustand, Entscheidungen, ungelöste Risiken und nächste sichere Aktion.

Klare Delegation reduziert doppelte Erkundung und fehlende Abdeckung. Sie garantiert keine Korrektheit. Abschlussnachweise müssen deshalb am realen System geprüft und dürfen nicht allein aus der Darstellung des Agenten übernommen werden.

Wie sollten Kontext und Übergaben funktionieren?

Kontext sollte ausreichend und begrenzt sein, nicht bloß kurz oder nach einem Timer zurückgesetzt werden. Ein neuer Agent ohne die aktuellen Einschränkungen kann alte Fehler wiederholen; ein zu langer Kontext kann die maßgebliche Anforderung verbergen. Halte dauerhaften Zustand möglichst in versionierten Artefakten fest: Pläne, Entscheidungen, Schnittstellen, Testergebnisse und Wiederherstellungshinweise. Zusammenfassungen sollten verifizierte Fakten, Annahmen, offene Fragen und tatsächlich angewandte Änderungen unterscheiden.

Nutze explizite Zustandsübergänge wie ausstehend, in Arbeit, benötigt Aufmerksamkeit, abgeschlossen und verifiziert. Eine Agentennachricht ist kein Nachweis, dass eine Änderung existiert oder Tests besteht. Prüfe das Artefakt und führe die relevanten Checks aus, bevor nachgelagerte Arbeit davon abhängt.

Können Reviewer-Agenten menschliches Review ersetzen?

Reviewer-Agenten können einen unabhängigen Durchgang ergänzen, Hypothesen testen oder eine andere Risikoklasse untersuchen. Sie können Blindstellen mit dem erzeugenden Modell teilen, Umgebungsverhalten übersehen oder für eine unvollständige Rubrik optimieren. Nutze sie als eine Kontrolle, nicht als Beweis dafür, dass der Output korrekt oder sicher ist.

Menschliches Review sollte den Folgen angemessen sein und sich auf Absicht, Architektur, Security, Datenschutz, Auswirkungen auf Nutzer und Ausnahmen konzentrieren, die automatisierte Checks nicht abdecken. Auch die Multi-Agent-Referenzarchitektur von Google Cloud betont menschliche Aufsicht, definierte Autonomie, Observability und kontinuierliche Evaluation. Siehe die Architekturhinweise für Multi-Agent-Systeme.

"Die sinnvolle Agentenanzahl ist die Parallelität, die dein Team innerhalb seiner Risikotoleranz verifizieren und integrieren kann. Miss sie anhand akzeptierter Ergebnisse, nicht anhand von Aktivität."

Wie wenden wir das in Projekten an?

Wavect verwendet weder einen universellen Default von zwei Agenten noch ein Maximum von fünf Agenten, eine Review-Grenze von vier Stunden oder eine feste Erfahrungsschwelle als öffentliches Lieferversprechen. Wir setzen Work-in-Progress-Limits anhand von Aufgabengraph, Review-Verantwortung, Tool- und Datenzugriff, Tests, Integrationsfläche und Fehlerfolgen. Diese Grenzen können sich innerhalb eines Projekts mit der Evidenz ändern.

Bevor wir parallele Worker hinzufügen, erwarten wir begrenzte Aufgaben, möglichst isolierte Verantwortung, eine sichtbare Review-Warteschlange, explizite Übergaben und Checks für die wichtigen Verträge. Bei risikoreicheren Änderungen ergänzen wir Freigabegates und tieferes menschliches Review. Das ist ein Betriebsansatz, kein Beleg dafür, dass keine Defekte entkommen können.

Was ändert das bei der Einstellung?

Arbeit mit Agenten erhöht den Wert von Zerlegung, Fachurteil, Verifikation, Security, Debugging, Kommunikation und Wiederherstellungsfähigkeiten. Sie macht das Tippen nicht irrelevant und beweist nicht, dass die wertvollste Engineering-Person fünf Agenten beaufsichtigen kann. Rollen sollten nach der tatsächlichen Arbeit und den Risiken bewertet werden, für die sie Verantwortung tragen.

Bei fraktionaler technischer Führung kann das die Auswahl geeigneter Agenteneinsätze, das Definieren von Berechtigungen und Evidenz, den Aufbau von Evaluations- und Review-Schleifen und die Messung umfassen, ob Automation die akzeptierte Lieferung verbessert. Siehe unseren Service für fraktionale Führung.