Die 10-Agenten-Schwelle — Warum das Skalieren über 10 KI-Agenten hinaus alles verändert
Ab 10 geht etwas kaputt
Nicht die Technologie selbst. Sondern die organisatorische und Monitoring-Infrastruktur drumherum.
Die ersten fünf Agents sind übersichtlich — jeder macht eine Aufgabe, jeder hat einen klaren Owner, jeder ist nachvollziehbar. Der sechste bis neunte sind noch handhabbar. Beim zehnten merkt man meistens, dass sich etwas verschoben hat, aber man kann es nicht genau benennen. Bis zum fünfzehnten sind sie im Production-Crisis-Modus — kaskadierende Fehler, die sie nicht zurückverfolgen können, Abrechnungen, die sie nicht rechtfertigen können, und ein Monitoring-Setup, das mehr Rauschen als Signal erzeugt.
Die Google-Cloud-Daten erklären warum: 52 % der AI-Adopter haben Agents in Production deployed. 39 % haben mehr als 10 deployed. Das Problem ist, dass so gut wie keine praxistaugliche Guidance dafür existiert, was sich an dieser Schwelle ändert. Das Content-Ökosystem behandelt das Deployen von einem bis fünf Agents ausführlichst. Es fällt genau dann eine Klippe hinunter, wenn die echte Engineering-Arbeit beginnt.
Es geht um diese Klippe.
Was die Daten wirklich zeigen
Der Google-Cloud-ROI-Report für 2025 enthält zwei Zahlen, die in jedem CTO-Briefingdeck sein sollten.
52 % der Organisationen mit AI-Deployments haben die Pilotphase hinter sich gelassen. Das ist kein Experimentieren mehr — das ist Production-Infrastruktur.
39 % haben die 10-Agenten-Marke überschritten.
Die Lücke zwischen diesen beiden Zahlen ist da, wo die meisten gescheiterten Deployments leben. Von einem einzelnen Agent zu fünf zu kommen ist ein gut verstandener Journey. Von neun auf zwölf zu kommen ist ein völlig anderes Problem, und fast niemand schreibt ehrlich darüber.
Warum 1–10 Agents funktionieren — und warum es nicht skalieren kann
Der Grund, warum 1–10 Agents handhabbar sind, ist strukturell, nicht technologisch.
Jeder Agent hat einen klaren Owner. Wenn etwas kaputtgeht, triaget eine Person. Wenn etwas funktioniert, bekommt eine Person den Credit. Die Accountability-Struktur ist menschlich skalierbar.
Die Kosten jedes Agents sind zuweisbar. Du weißt, was der Customer-Service-Agent pro Monat kostet. Du weißt, was der Invoicing-Agent kostet. Wenn der CFO fragt, welche AI-Investments Value generieren, kannst du antworten.
Die Outputs jedes Agents sind verifizierbar. Du prüfst die Arbeit. Du spot-checkst die generierten Invoices, die geschlossenen Tickets, die produzierten Reports. Die Arbeit des Agents ist unterscheidbar von der menschlichen Arbeit drumherum.
Das Versagen jedes Agents ist eingedämmt. Ein Agent geht kaputt, eine Person fixt ihn, das System läuft weiter.
Diese Struktur funktioniert bis etwa 10 Agents. Bei 11 funktioniert sie nicht mehr.
Was an der 10-Agenten-Schwelle kaputtgeht
Die Failure Modes bei Scale sind spezifisch und benennbar.
Orchestration Complexity Explosion
Agent A hängt von Agent B ab, der von Agent C abhängt. Wenn A fehlschlägt, weißt du nicht, ob es A's, B's oder C's Fault ist. Der Failure ist kaskadierend und unsichtbar, bis er irgendwo downstream auftaucht — meistens vor einem Kunden.
Bei einer Organisation hat ein Lead-Routing-Agent gelegentlich Leads an den falschen Sales Rep geschickt. Der Debugging-Prozess dauerte vier Tage. Die eigentliche Ursache: Ein Data-Enrichment-Agent hatte begonnen, ein neues Field zurückzugeben, das der Routing-Agent nicht erwartet hat, was dazu führte, dass er den Priority Score falsch geparst hat. Niemand hat den Routing-Agent angefasst. Niemand hat das CRM angefasst. Der Failure war komplett in der Interaktion zwischen zwei Agents, die jeweils einzeln getestet wurden und für korrekt befunden wurden.
Das ist das fundamentale Problem von Multi-Agent-Systemen: Agents werden isoliert getestet, schlagen aber in der Komposition fehl.
Cost Attribution Collapse
Ohne Per-Agent-Tracking-Infrastruktur weißt du, dass du $X pro Monat für AI ausgibst. Du weißt nicht, welche Agents Value generieren und welche Rauschen sind.
Bei einem mittelständischen Unternehmen mit 14 Agents fragte ein CFO: „Welche davon sind eigentlich das wert, was wir bezahlen?" Die Antwort dauerte drei Wochen und war immer noch unpräzise. Die Agents waren über acht Monate inkrementell von drei verschiedenen Team-Mitgliedern hinzugefügt worden, und niemand hatte die Attribution-Infrastruktur aufgebaut, als der erste Agent deployed wurde.
Die Kosten dieser Attribution-Debt: ungefähr $40.000 an überprovisionierter Agent-Kapazität, die niemand bemerkt hatte, weil die Abrechnung als einzelne Line Item reinkam.
Monitoring Gap
Die individuellen Metriken jedes Agents sind sichtbar. Agent-System-Interaktionsmetriken sind es nicht.
Die individuellen Metriken deines Customer-Service-Agents sind in Ordnung. Die individuellen Metriken deines CRM-Agents sind in Ordnung. Aber die Interaktion zwischen ihnen — was passiert, wenn der Customer-Service-Agent einen Case erstellt, auf den der CRM-Agent reagieren muss — diese Interaktion hat keine Metriken. Du siehst Bäume. Du siehst den Wald nicht.
Das ist die Monitoring Gap bei Scale. Sie erfordert Instrumentation, die die meisten Agent-Plattformen nicht out of the box mitliefern, und die die meisten Teams nicht kennen, bevor sie nicht schon hineingedeployed haben.
Ownership Ambiguity
Wenn drei Agents zu einem Outcome beitragen, wer owns den Outcome?
Genauer gesagt: Wenn ein Agent mitten im Workflow fehlschlägt, wer triagiert? Wenn ein Agent's Output degradiert, weil ein anderer Agent sein Verhalten geändert hat, wer diagnostiziert? Wenn das System einen schlechten Outcome produziert, wer ist accountable?
Die organisatorische Struktur, die für fünf Agents funktioniert — „du ownst den Agent, ich own den hier" — lässt sich nicht sauber auf fünfzehn Agents mappen, wo Agents mehr miteinander interagieren als mit den Menschen, die sie nominal ownen.
The Coordination Tax
Zeit, die für die Koordination von Agents aufgewendet wird, wächst als O(n²).
Bei fünf Agents ist der Koordinationsaufwand handhabbar — gelegentliche Check-ins, gelegentliches Debugging, gelegentliches Re-Routing. Eine Person kann das mentale Model behalten, wie die fünf Agents interagieren.
Bei zwanzig Agents wird Koordination zum Full-Time-Job. Du brauchst jemanden, dessen Job es ist, Agent-to-Agent Dependencies zu tracken, Handoffs zu managen, Cross-Agent-Failures zu debuggen und die System Map zu pflegen, die sonst niemand Zeit hat zu behalten.
Bei fünfzig Agents brauchst du ein Team.
Die meisten Organisationen, die AI Agents deployen, haben für diese Rolle nicht budgetiert. Sie entdecken den Bedarf reaktiv — wenn der Koordinationsaufwand die Productivity-Gains bereits konsumiert hat, die die Agents liefern sollten.
Die Orchestration Layer — Was es wirklich ist
Eine Orchestration Layer ist Infrastruktur, die über einzelnen Agents sitzt und fünf Dinge managt, die einzelne Agents nicht selbst managen können.
Task Routing: Welcher Agent bearbeitet welche Anfrage? In einem 5-Agent-System ist das eine manuelle Entscheidung. In einem 15-Agent-System braucht es Routing-Logik, die Agent-Capabilities, aktuelle Load und Kontext versteht.
State Management: Wie teilen Agents Kontext? Wenn Agent A Output produziert, den Agent B braucht — wie weiß B, was A produziert hat? Ohne Shared-State-Infrastruktur kommunizieren Agents durch brittle Handoffs — File Drops, Webhook-Triggers, Shared Databases, die out of sync geraten.
Error Handling: Was passiert, wenn ein Agent mitten im Workflow fehlschlägt? Haltet der Workflow an? Retry ein anderer Agent? Wird ein Mensch benachrichtigt? Einzelne Agents handhaben ihre eigenen Errors. Orchestration handhabt Errors über Agent-Grenzen hinweg.
Cost Tracking: Per-Agent-, Per-Task-, Per-Output-Attribution. Das erfordert Instrumentation, die die meisten Agent-Frameworks nicht nativ mitliefern.
Monitoring: Agent-System-Interaktionsmetriken, nicht nur Agent-Level-Metriken. Das ist die Monitoring Gap, die oben beschrieben wurde.
Was eine Orchestration Layer NICHT ist: Ein einzelner Super-Agent, der alles macht. Es ist nicht die AI, die die anderen AIs in einer sentience Hierarchy managed. Es ist Infrastruktur — Routing, State, Error Handling, Attribution, Monitoring — die Multi-Agent-Systeme operabel macht.
LangGraph handhabt stateful Workflows und ist die flexibelste Option für Developer. AWS Bedrock Agents bietet managed Orchestration mit AWS-Integration. Azure AI Agent Service bietet ähnliche managed Capability für Microsoft-aligned Teams. Google Vertex AI Agent Builder sitzt in derselben Kategorie. CrewAI bietet Multi-Agent Role-based Orchestration, die zugänglicher für Teams ohne tiefe Infrastructure-Engineering-Expertise ist.
Das Decision Framework
Fünf Fragen, die durch das Rauschen durchschneiden.
Interagiert dieser Agent mit existierenden Agents? Wenn der neue Agent Output von oder Input zu irgendeinem existierenden Agent liest/schreibt, bist du bereits in Orchestration-Territory. Die Interaktion muss designed werden, nicht emergent.
Kann ich seine Kosten einem spezifischen Business Outcome zuweisen? Wenn du diese Frage für den vorgeschlagenen Agent nicht beantworten kannst, fügst du Opacity hinzu. Jeder Agent, den du nicht attributen kannst, ist ein Noise-Generator in deiner Cost-Reporting.
Teilt er State mit anderen Agents? Wenn der neue Agent Zugriff auf Daten braucht, die andere Agents produzieren oder konsumieren, brauchst du Shared-State-Infrastruktur.
Kann ich ihn unabhängig monitoren? Nicht nur ob er läuft — ob seine Outputs korrekt sind, ob seine Error Rate innerhalb der Bounds liegt. Wenn du es nicht messen kannst, kannst du es nicht verbessern.
Kann ich „welche Agents generieren Value" für alle meine aktuellen Agents beantworten? Wenn du das für deine existierenden Agents nicht kannst, hast du die Schwelle bereits überschritten. Das 10-Agent-Problem ist nicht spezifisch关于 den 10. Agent — es geht um die Capability Gap, die sich akkumuliert, wenn du Agents hinzufügst. Der 10. Agent ist nur da, wo die Gap unmöglich zu ignorieren wird.
Die Faustregel: Wenn du deinen 8. Agent hinzufügst und er mit irgendeinem der vorherigen 7 interagieren wird, investiere in Orchestration-Infrastruktur VOR dem 10. Die Kosten, das retroaktiv aufzubauen, sind signifikant höher als es proaktiv aufzubauen.
Die echten Kosten der Schwelle
Monitoring-Tools können bei Scale mehr kosten als die Agents selbst.
Bei einer Organisation mit 23 Agents liefen die monatlichen Kosten für Monitoring und Observability bei 1,3x der Agent-Platform-Kosten. Das Monitoring war nicht einmal gut — es generierte genug Alerts, dass das Team Alert Fatigue entwickelt hatte und reale Failures übersah.
Der Coordination Tax ist die andere cost, die konsistent unterschätzt wird. Bei einem Team verbrachte die Person, die die Agent-Infrastruktur maintainte, 60 % ihrer Zeit mit Koordination — Integration Code zwischen Agents schreiben, Cross-Agent-Failures debuggen, die System Map maintainen — und 40 % mit der eigentlichen Arbeit, die die Agents machen sollten.
Und der ehrliche Hinweis: Für die meisten SMBs ist es die richtige architektonische Entscheidung, unter 10 Agents mit cleanen Point Solutions zu bleiben. Die Orchestration-Infrastruktur, die nötig ist, um 10+ Agents zuverlässig zu betreiben, ist eine signifikante Investition. Wenn dein Use Case von sieben Agents bedient werden kann, die jeweils eine Sache gut machen, brauchst du keine Orchestration.
Das Signal, das sagt, dass du sie überschritten hast
Wenn du die Frage „welche Agents generieren Value?" nicht beantworten kannst — dann hast du sie überschritten.
Nicht wenn du Agent Nummer 10 erreichst. Wenn die Attribution-Frage unbeantwortbar wird.
Wenn du diesen Moment näherst, ist die Investition Orchestration-Infrastruktur: Routing, State, Error Handling, Attribution, Monitoring. Die Teams, die über 10 Agents hinaus skalieren, sind diejenigen, die den 8. oder 9. Agent als den Punkt behandelt haben, an dem deliberate Architecture notwendig wird.