Fokus ist der neue Engpass: Warum du nur so viele KI-Agenten betreiben kannst, wie du kontrollieren kannst

Hatte am Sonntag ein interessantes Gespräch. Ein Satz ist hängengeblieben. Fokus ist der neue Engpass, seit LLMs gut geworden sind. Nicht Code schreiben. Nicht Bugs fixen. Orchestrierung kontrollieren. Ab einer bestimmten Agent-Anzahl sinkt die Output-Qualität, und die Arbeit verlagert sich vom Tippen zum Entscheiden, welcher Agent läuft, mit welchem Kontext, gegen welche Checks. Das neue Skillset ist Fokus, Kontextmanagement und QA. Nach einem Jahr mit echten Kunden-Engagements, in denen die meiste Tastaturzeit jetzt Agent-Supervision ist, stimme ich zu.

Dieser Post handelt davon, warum die Decke existiert, wie sie in der Praxis aussieht und wie wir bei echten Wavect-Builds die Agent-Anzahl unter der Decke halten.

Was hat sich tatsächlich geändert, als LLMs gut wurden?

Für den Großteil der Software-Geschichte war der Engpass Durchsatz. Wie schnell ein Senior-Engineer eine Spec in funktionierenden Code verwandeln kann. Tools wurden danach gemessen, wie viel sie aus diesem Loop entfernen. Autocomplete, Snippets, IDE-Refactoring, dann Copilot, dann volle Coding-Agents.

2026 ist dieser Loop für alles außer die härtesten 10 % der Arbeit größtenteils weg. Ein kompetenter Operator, der einen Coding-Agent betreibt, kann an einem Tag mehr Code produzieren als ein Dreierteam vor wenigen Jahren. Der Constraint hat sich verschoben.

Der neue Constraint ist nicht "kann der Agent den Code schreiben". Er ist "habe ich noch genug Aufmerksamkeit übrig, um zu verifizieren, was der Agent produziert hat, die nächste Aufgabe an den richtigen Agent zu routen und das Kontextfenster jedes Agents sauber genug zu halten, dass der Output ehrlich bleibt". Das ist ein Fokus-Problem, kein Tipp-Problem.

Wie sieht die Orchestrierungs-Decke tatsächlich aus?

Jeder, der mehr als zwei Agenten parallel betrieben hat, kennt diesen Moment. Agent A produziert Code, der okay aussieht. Agent B produziert ein Refactoring, das mit Agent A kollidiert. Agent C schlägt einen Test vor, der keines von beiden fängt. Du verbringst mehr Zeit damit, sie zu versöhnen, als du durch Parallelisierung gespart hast. Du fügst einen vierten Agent hinzu, um die Konflikte zu triagieren. Er führt neue ein.

Das ist die Decke. Es ist keine harte Zahl. Sie bewegt sich anhand von drei Variablen.

• Task-Kopplung. Unabhängige Tasks skalieren fast linear. Gekoppelte Tasks, bei denen jeder Agent-Output von einem anderen Agent-Output abhängt, kollabieren schnell.
• Verifikationskosten. Wenn jeder Agent-Output 30 Sekunden zur Validierung braucht, sind 10 Agenten okay. Wenn es 15 Minuten dauert, sind 3 deine Decke.
• Kontext-Hygiene. Je länger die Konversation, desto schlechter der Output. Ab einer Schwelle degradiert jeder Agent still. Du bemerkst den Drift nicht mehr, bis eine Regression ausgeliefert wird.

Warum degradiert die Output-Qualität jenseits von N Agenten?

Aus Engagements, in denen wir mehr als zwei Coding-Agents parallel betrieben haben, clustern die Failure-Modes in sieben Kategorien. Reihenfolge nach Häufigkeit.

1. Aufmerksamkeitssplitting. Der Operator wechselt zwischen Agenten so schnell, dass keiner einen vollen Read bekommt. Subtile Fehler landen in Produktion. Der günstige Fix ist ein harter Cap auf gleichzeitige Agenten, meist zwei für neue Operatoren und drei bis vier für erfahrene.
2. Kontext-Bleed. Ein Agent, der eine Stunde an Task A lief, nimmt jetzt Task B mit eingebackenen veralteten Annahmen auf. Der Output sieht selbstbewusst aus und ist falsch. Günstiger Fix: harter Reset zwischen Tasks. Behandle das Kontextfenster als Werkzeug, nicht als Gedächtnis.
3. Eval-Schulden. Der Operator betreibt mehr Agenten, als die Eval-Suite mithalten kann. Qualität sinkt, ohne dass es jemand merkt. Der Fix ist, in TDD und kontinuierliche Evals zu investieren, bevor du die Agent-Anzahl skalierst, nicht danach.
4. Konflikt-Versöhnungs-Steuer. Zwei Agenten berühren dasselbe Modul. Ihre Outputs zu versöhnen, kostet mehr als die Arbeit, die einer allein produziert hat. Günstiger Fix: Partitioniere die Codebase nach Agent, nicht nach Task.
5. Tool-Use-Latenz-Stack-up. Jeder Agent wartet auf Tools. Drei Agenten, die auf dieselbe Datenbank-Fixture warten, serialisieren auf der langsamsten. Günstiger Fix: Per-Agent-Fixtures oder weniger Agenten.
6. Halluzinierte Koordination. Ein Agent denkt, ein anderer Agent habe die Arbeit schon erledigt, weil er die Nachricht in der gemeinsamen History sehen kann. Nichts wurde gemacht. Günstiger Fix: expliziter Handoff-State, keine angenommene Koordination.
7. Reviewer-Müdigkeit. Der Operator hört nach 90 Minuten Agent-Supervision auf, sorgfältig zu lesen. Der Fix sind kürzere Sessions, nicht mehr Agenten.

Was sind die drei neuen Skills, die der Orchestrator braucht?

Wenn der Tipp-Loop größtenteils automatisiert ist, ist der Engpass die Aufmerksamkeit des Operators. Drei Skills entscheiden, ob der Operator skaliert oder steckenbleibt.

1. Fokus-Disziplin. Zu wissen, wie viele Agenten du ohne Qualitätsverlust überwachen kannst. Diese Zahl als harten Constraint zu behandeln, nicht als Ziel zum Übertreffen. Die meisten Operatoren, die wir eingestellt haben, treffen ihre Decke bei drei gleichzeitigen Agenten. Wenige sitzen komfortabel bei fünf. Niemanden haben wir bei zehn ohne Qualitätsverlust gesehen.

2. Kontext-Management. Zu wissen, wann ein Agent zurückzusetzen ist, wann eine lange Konversation zu summarisieren ist, wann ein frischer Kontext für dieselbe Aufgabe gespawnt wird und wann History zu behalten ist. Das ist der Teil des Jobs, der vor drei Jahren nicht existierte. Das MCP-Ökosystem beginnt, strukturierte Kontext-Handoffs auszuliefern, was hilft, aber der Operator muss immer noch wählen, was zu behalten ist.

3. Quality-Assurance-Design. Wenn der Operator nicht jeden Output lesen kann, muss es die Eval-Suite tun. QA hört auf, eine Phase zu sein, und wird zum Loop. Tests, Snapshot-Checks, Regressions-Suites, Behavioral Evals, Smoke-Runs nach jedem Agent-Commit. Je mehr Agenten du betreibst, desto mehr trägt dein QA-Stack das Gewicht.

"Die Decke ist kein Tool-Problem. Sie ist ein Aufmerksamkeits-Problem. Einen besseren Agenten zu kaufen hebt sie nicht. In Evals zu investieren schon."

Wie rationieren wir die Agent-Anzahl auf echten Engagements?

Bei jedem KI-Engagement, das wir bei Wavect betreiben, wird das Operator-zu-Agent-Verhältnis vorab festgelegt und wöchentlich angepasst. Die Regeln, zu denen wir immer wieder zurückkommen.

• Zwei gleichzeitige Agenten pro Operator, Default. Drei, wenn der Operator schon einen KI-lastigen Build ausgeliefert hat. Nie mehr als fünf ohne einen Co-Operator, der Reviews macht.
• Ein Spezialagent pro Rolle, nicht pro Task. Ein Coding-Agent, ein Testing-Agent, ein Planning-Agent. Jeder behält eine stabile Rolle, statt durch jeden Task-Typ zu churnen.
• Harter Kontext-Reset zwischen Epics. Wenn die Arbeit zu einem neuen Feature wechselt, starten die Agenten frisch, auch wenn ihr vorheriger Kontext "fast passt".
• Evals vor Parallelismus. Bis die Test-Suite Regressionen zuverlässig fängt, laufen wir sequentiell. Parallelismus ohne Evals ist eine Sandburg.
• Reviewer-Stunden gedeckelt. Kein Operator betreibt Agent-Supervision mehr als 4 Stunden pro Tag. Die verbleibende Zeit geht in Architektur, Eval-Design und Review.

Nichts davon ist bahnbrechend. Es spiegelt, wie Teams ohne KI arbeiten. Das Interessante ist, dass es jetzt auf eine einzelne Person zutrifft, die einen Schwarm von Agenten betreibt.

Wie ändert das, wofür wir einstellen?

Es verschiebt die Einstellungslatte. Der wertvollste Engineer 2026 ist nicht der schnellste Tipper. Es ist der, der fünf Agenten produktiv halten kann, ohne dass deren Output-Qualität driftet. Das ist eine Fokus-Disziplin, eine Kontext-Management-Disziplin und eine QA-Disziplin in einem. Jedes davon können wir trainieren. Was wir nicht voll trainieren können, ist die Fähigkeit zu merken, dass ein Agent angefangen hat zu lügen, was er gemacht hat. Dieser Teil kommt aus Erfahrung.

Das ist auch, warum sich die Fractional-CTO-Rolle ändert. Vor wenigen Jahren war der Wert technisches Urteil und Liefergeschwindigkeit. Heute ist die Hälfte des Werts, die Agent-Supervisions-Kapazität eines frühen Teams zu kalibrieren und das Eval-Gerüst zu bauen, das diese Kapazität sicher skalieren lässt. Wir sehen das in fast jedem KI-lastigen Engagement.

Founder Q&A

Heißt das, kleine Teams schlagen große Teams jetzt? Kleine Teams mit starkem Eval-Gerüst schlagen große Teams mit schwachem. Headcount hört auf, der Proxy zu sein. Supervisions-Kapazität wird es.

Werden bessere Coding-Agents das einfacher machen? Bessere Coding-Agents heben die individuelle Output-Qualität, aber nicht die Supervisions-Kapazität. Die Decke bewegt sich langsam, weil Aufmerksamkeit der bindende Constraint ist.

Was ist mit Agent-auf-Agent-Supervision? Manche Teams liefern "Reviewer-Agents" aus, die Coding-Agents prüfen. Sie helfen am Rand. Sie lösen das Fokus-Problem nicht, weil jemand immer noch den Reviewer überwachen muss. Schichten eliminieren das Aufmerksamkeitsbudget des Operators nicht, sie geben es anders aus.

Wie weißt du, dass ein Agent angefangen hat zu driften? Drei Anzeichen. Der Output ist selbstbewusster, als der Kontext rechtfertigt. Der Agent hört auf, klärende Fragen zu stellen. Tests, die vorher fehlschlugen, gehen jetzt ohne Codeänderung durch. Eines davon ist der Cue zum Kontext-Reset.

Ist das nur Engineering, oder gilt es auch für nicht-Code-Arbeit? Es gilt überall, wo Agenten anfassen. Wir sehen dasselbe Muster in Support-Automation, in Research-Workflows und in RAG-Pipelines, die zwischen Spezialagenten routen. Die Zahlen verschieben sich, die Form ist dieselbe.