Sechs Monate nach dem Start ihres KI-Rollouts hatte eine Berliner B2B-Softwareberatung acht verschiedene KI-Agenten gebaut: einen für Vertriebsansprache, einen für Marketing-Inhalte, einen für SEO, einen für Angebotserstellung, einen für Upselling, einen für Kundenerfolg, einen für interne Abläufe und einen für HR-Onboarding.
Das Problem: Bei jedem Update ihrer Preise mussten sie alle acht Agenten aktualisieren. Innerhalb von zwei Monaten hörten sie auf, alle acht Agenten zu aktualisieren. Die Agenten entwickelten nach und nach unterschiedliche Vorstellungen davon, was das Unternehmen tut, wer die ideale Zielgruppe ist und wie die Preise tatsächlich aussehen. Der Vertriebsagent versprach Drei-Tage-Implementierungszeiträume, von denen der Delivery-Agent wusste, dass sie nicht erreichbar sind. Der Marketing-Agent beschrieb AI-Readiness-Assessments optimistisch als„kostenlos“, obwohl sie seit drei Jahren für 1.500 € angeboten wurden. Sie verbrachten mehr Zeit damit, die Inkonsistenzen zwischen den Agenten zu verwalten, als sie für die manuelle Arbeit gebraucht hätten.
Das ist kein Versagen der KI-Fähigkeiten. Es ist eine Architekturentscheidung, die zu früh getroffen wurde—auf Basis organisatorischer Instinkte statt technischer Logik.
Warum der Organigramm-Ansatz eine Falle ist
Der natürliche Instinkt beim Entwurf eines KI-Systems ist es, die Organisation zu spiegeln. Vertrieb hat andere Verantwortlichkeiten als Marketing. Marketing hat andere Verantwortlichkeiten als Operations. Also: ein separater Agent für jedes.
Das Problem: Unternehmen haben unendlich viele Rollen, aber Kontextbündel sind endlich. Eine B2B-Beratung mit 10 Mitarbeitern hat nicht wirklich 10 verschiedene Kontextbündel—sie hat vielleicht drei. Die Grenzen zwischen„Vertrieb“ und„Marketing“ sind organisatorische Konstrukte, keine Datengrenzen. Wenn deine KI-Agenten vom Organigramm statt von den Daten ausgehen, wird jede Naht zwischen ihnen zu einem Ort, an dem Fakten abdriften und Widersprüche entstehen.
Die 5 echten Regeln für die Aufteilung in einen neuen Agenten
Die Antwort auf„ein Agent oder viele“ steckt in fünf konkreten Fragen. Wenn die Antwort auf eine davon Ja ist, willst du wahrscheinlich einen separaten Agenten. Wenn die Antwort auf alle Nein ist, willst du wahrscheinlich anders aufteilen.
1. Braucht dieser Agent Zugriff auf Daten, die die anderen nicht sehen sollten?
Ein Delivery-Agent, der Kunden-Repos und Projektpläne liest, sollte diesen Kontext offensichtlich nicht mit einem Marketing-Agenten teilen, der externe Inhalte entwirft. Das ist eine harte Sicherheitsgrenze. Wenn die Datenzugriffsanforderungen divergieren, sollten die Agenten divergieren.
2. Liest dieser Agent aus einer anderen Quelle der Wahrheit?
Wenn die primäre Eingabe eines Agenten ein CRM ist, die eines anderen ein Code-Repository und die eines dritten ein Abrechnungssystem—das sind drei verschiedene Quellen der Wahrheit. Wenn die Fakten im CRM den Fakten im Abrechnungssystem widersprechen, wer gewinnt? Separate Agenten lassen dich das sauber handhaben.
3. Arbeitet dieser Agent in einem grundlegend anderen Denkmodus?
Analytische Arbeit(Dashboards lesen, Berichte erstellen, Anomalien erkennen)und generative Arbeit(E-Mails entwerfen, Texte schreiben, Vorschläge bauen)nutzen unterschiedliche Prompting-Stile und profitieren oft von unterschiedlichen Modellen. Keine absolute Regel—die meisten analytischen Aufgaben kann derselbe Agent in einem anderen Modus erledigen—aber eine Überlegung wert.
4. Braucht dieser Agent eine andere Human-in-the-Loop-Oberfläche?
Ein Agent, der E-Mails an Kunden sendet, sollte einen anderen Freigabeworkflow haben als einer, der interne Dokumente entwirft. Gleiches Modell, gleiche Wissensbasis, aber andere Risiken. Das gehört in einen anderen Agenten.
5. Stellt dieser Agent eine Persona dar, mit der deine Nutzer tatsächlich sprechen wollen?
„Dein KI-Assistent“ versus„dein KI-Kundenbetreuer“ versus„dein KI-technischer Berater“—wenn das unterschiedliche nutzerseitige Erfahrungen sind, die deine Kunden oder Interessenten tatsächlich erleben, verdienen sie eine eigene Agentenidentität. Nicht wegen der internen Organisation, sondern wegen der externen UX.
Keine guten Gründe, einen Agenten hinzuzufügen:„Marketing sollte seinen eigenen Agenten haben“,„wir wollen Kosten pro Abteilung tracken“,„es fühlt sich organisierter an.“Das sind organisatorische Etiketten, die im Nachhinein auf eine Architektur geklebt werden, die von Datengrenzen getrieben sein sollte.
Die richtige Struktur: 3 Agenten, nicht 10
So sieht die richtige Architektur für ein B2B-Unternehmen wie die oben beschriebene Beratung aus:
Agent 1: Growth — Besitzt: ICP-Definition, Positionierung, Pipeline-Strategie, Website-Texte, Inhaltskalender, Outreach-Sequenzen, SEO-Prioritäten. Liest aus: CRM (Gewinn-/Verlustmuster), Google Analytics (Verkehrsquellen),llms.txt(Produktwissen), Markenrichtlinien. Schreibt in: Kampagnen-Briefs, Inhalte, Outreach-Sequenzen, Website-Änderungsanfragen.
Agent 2: Revenue — Besitzt: Lead-Qualifizierung, Angebots- und Preisangebotsgenerierung, Preisentscheidungen, Einwandbehandlung, CRM-Hygiene. Liest aus: CRM(Deals, Kontakte), Preistier-Dokumentation, Angebotsvorlagen, Wettbewerbskontext. Schreibt in: Vorschläge, Angebote, Follow-up-Sequenzen, CRM-Updates, Meeting-Notizen.
Agent 3: Delivery — Besitzt: Projektplanung, Implementierungszeiträume, technische Stack-Entscheidungen, Statusberichte, Runbooks, Incident-Response. Liest aus: Projekt-Tracker, Code-Repos, Monitoring-Dashboards, SLA-Dokumentation, Kundenkommunikations-Threads. Schreibt in: Projektpläne, Status-Updates, Post-Mortems, Wissensbasis-Artikel.
Drei Agenten. Jeder weiß bereits über Vertriebsstrategie, Preise, Angebote, Preisangebote und Upselling Bescheid—weil diese Themen natürlich zum selben Kontextbündel gehören. Der Growth-Agent und der Revenue-Agent kennen beide die Preise. Die Revenue-und Delivery-Agenten kennen beide die Implementierungszeiträume. Die Nähte, die in einem 10-Agenten-System Widersprüche verursachen würden, existieren hier nicht, weil derselbe Agent die zugehörigen Fakten besitzt.
Warum 10 Agenten scheitern
10× der Kontextdrift. Jeder Agent hat sein eigenes Systemprompt, seinen eigenen Produktwissens-Cache, sein eigenes Verständnis der ICP. Jedes Update an Preisen, Positionierung oder Produkt muss 10 Stellen berühren. In der Praxis berührt es null. Die Agenten divergieren langsam, bis sie derselben Interessenten-Frage selbstbewusst unterschiedliche Antworten geben.
Routing-Komplexität. Du brauchst einen Meta-Agenten—oder einen menschlichen Router—um zu entscheiden, welchen von 10 du anrufen sollst. Die Routing-Regeln werden zu einer zweiten Wissensbasis, die ebenfalls gepflegt werden muss. Routing-Fehler bedeuten, dass eine Marketing-Frage vom Vertriebsagenten beantwortet wird, was eine produktzentrierte Antwort ergibt, die nicht zur tatsächlichen Frage des Interessenten passt.
Testbarkeit kollabiert. Statt drei Eval-Suiten hast du zehn. In der Praxis pflegt niemand zehn Eval-Suiten. Also führt sie niemand aus. Also degradieren die Agenten still, bis dir ein Kunde davon erzählt.
Handoff-UX-Probleme. Ein Interessent stellt mitten im Gespräch mit dem Marketing-Agenten eine Preisfrage.Übergibst du? Verlierst du den Gesprächsverlauf? Duplizierst du den Kontext? Jeder Handoff ist eine schlechte Erfahrung, wenn er nicht perfekt gehandhabt wird.
Fehler akkumulieren. Ein Fehler im Verständnis des Growth-Agenten von Preisen wird in einem Kampagnen-Brief verwendet. Dieser Brief beeinflusst die Qualifizierungsfragen des Revenue-Agenten. Der Revenue-Agent leitet einen Deal mit falschen Erwartungen weiter. Der Delivery-Agent erbt ein Zeitversprechen, das nie erreichbar war. Mit 10 Agenten und 10 Nähten wird die Fehlerakkumulationsfläche unüberschaubar.
Das Muster, das tatsächlich funktioniert
Eine gemeinsame Wissensbasis. Eine kleine Anzahl von Agenten. Viele Skills.
Der Unterschied ist wichtig: Skills sind abgegrenzte Anweisungssets+Werkzeugdefinitionen, die innerhalb eines Agenten leben. Agenten sind die kohärenten Kontextbündel, die verwandtes Wissen und Werkzeuge besitzen. Skills sind, wie du Spezialisierung bekommst, ohne Agenten zu multiplizieren.
Denk an einen menschlichen Mitarbeiter: ein Senior-Growth-Berater in einer B2B-Agentur kennt sich mit Positionierung, Inhalte, SEO und Vertriebsstrategie aus—weil diese verwandt sind. Er muss nicht vier verschiedene Personen sein. Aber innerhalb seiner Rolle kann er spezifische Skills haben(A/B-Test-Design, Outreach-Sequenzierung, Website-Audits), die er in verschiedenen Situationen unterschiedlich anwendet.
Agenten sind die Person. Skills sind das, was sie zu tun wissen.
Wenn du diese Architektur baust, testest du sie auf dieselbe Weise: Wenn deine drei Agenten alle dieselben Preise, dieselbe ICP und dieselbe Positionierung zitieren können, ohne dass du dich jedem von ihnen wiederholen musst, hast du die richtige Anzahl. Wenn sie sich widersprechen, hast du bereits zu viele.
Entwirf deine KI-Architektur, bevor du sie baust
Die richtige Agentenanzahl vor dem Bau festzulegen, ist der Unterschied zwischen einem System, das kohärent bleibt, und einem, das ständige Aufräumarbeit erfordert. Der Zeitpunkt, um zu fragen„wie viele Agenten sollten wir eigentlich haben“, ist, bevor du den ersten gebaut hast.
LaunchCI hilft B2B-Unternehmen, ihre KI-Architektur beim ersten Mal richtig zu entwerfen—Kontextbündel zu kartieren, Wissensgrenzen zu definieren und die gemeinsame Wissensbasis zu bauen, die Agenten ausgerichtet hält.
Wenn du ein KI-System baust oder planst und einen Realitätscheck der Architektur willst, bevor du tiefer gehst, melde dich: hello@launch.ci.