Andre Jahn, Jahn Consulting - Februar 2026

Das Multi-Agent-Missverständnis

Wenn die Tech-Industrie über Multi-Agent-Systeme spricht, meint sie meistens Folgendes: Ein Orchestrator-Agent nimmt eine Aufgabe entgegen, zerlegt sie in Teilaufgaben und delegiert sie an spezialisierte Sub-Agents. Agent A recherchiert, Agent B schreibt Code, Agent C prüft das Ergebnis. Der Mensch gibt den Auftrag, die Maschine liefert.

Das klingt elegant. Es hat nur wenig mit der Realität in Unternehmen zu tun.

In einem echten Projektteam gibt es keine vollständig automatisierbaren Ketten. Es gibt Diskussionen, Abwägungen, unvollständige Informationen und Entscheidungen unter Unsicherheit. Es gibt den Moment, in dem jemand sagt: "Das funktioniert technisch, aber der Kunde wird es hassen." Oder: "Wir könnten das so bauen, aber wir haben keine Ahnung ob die Annahme stimmt."

Das sind keine Aufgaben, die man an eine Agent-Pipeline delegiert. Das sind Situationen, in denen ein Team gemeinsam denkt.

Die Frage ist nicht: Wie lassen sich Agents autonom orchestrieren? Die Frage ist: Wie werden KI-Agents zu Teammitgliedern, die in menschliche Entscheidungsprozesse eingebettet sind?

Agents als Teammitglieder

Seit einigen Monaten arbeite ich mit einem KI-Agent, der als Teammitglied in meinem Projektchat sitzt. Kein Chatbot, den ich ab und zu etwas frage. Ein Agent mit einer definierten Rolle: Senior Developer. Mit Zugriff auf das Ticketsystem, die interne Dokumentation und die Projektplanung. Mit einer klaren Arbeitsanweisung, die festlegt wie er sich verhält, was er darf, und wo seine Grenzen liegen.

Das klingt nach einem netten Experiment. In der Praxis verändert es die Art wie Projektarbeit funktioniert.

Ein Beispiel: Wir mussten festlegen, welches Tool wir wofür einsetzen - Ticketsystem, Dokumentation, Projektplanung, CI/CD. In einem klassischen Setup hätte ich das allein entschieden, vielleicht ein Dokument geschrieben, vielleicht nicht. Stattdessen habe ich meinen Vorschlag in den Chat gestellt. Der Agent hat eine relevante Rückfrage gestellt: Wie läuft die Kommunikation mit dem Kunden - hat der Zugriff auf die Projektplanung? Das hatte ich nicht bedacht. Wir haben den Workflow gemeinsam geschärft. Am Ende hat der Agent die Entscheidung als internes Dokument in der Wissensbasis angelegt - inklusive der Herkunft: "Basiert auf interner Teamabstimmung."

Die eigentliche Arbeit war ein fünfminütiges Gespräch. Das Dokument ist nur die Materialisierung einer Entscheidung, die bereits getroffen wurde. Und genau diesen Teil - den langweiligen, zeitfressenden, oft weggelassenen - übernimmt der Agent.

Aber es geht um mehr als Zeitersparnis. Der Agent denkt mit. Er hat eine Arbeitsanweisung, die ihn dazu bringt, Optionen zu bewerten statt nur aufzulisten. Vorschläge zu machen statt nur Fragen zu beantworten. Risiken zu benennen statt nur zuzustimmen. "Zustimmung ohne Gegenargument ist wertlos" - das steht in seinem Prompt, und es verändert die Qualität der Diskussion.

Natürlich ist das kein echtes Teammitglied. Der Agent war nicht beim Kunden, er hat kein Bauchgefühl, und er kennt die Teamdynamik nicht. Aber er hat Zugriff auf den Projektstand, die dokumentierten Entscheidungen und das Fachwissen aus seinem Training. In einer Architekturdiskussion ist das oft mehr Kontext als ein menschlicher Kollege hätte, der seit zwei Wochen im Projekt ist.

Rollen brauchen Grenzen

Hier wird es interessant - und hier scheitern die meisten Ansätze.

Ein KI-Agent der alles kann und alles sieht ist kein Teammitglied. Er ist ein Sicherheitsrisiko. Ein menschlicher Mitarbeiter mit Zugriff auf HR-Daten und Projektdaten postet keine Gehaltsinformationen im Team-Channel. Nicht weil das System ihn daran hindert - er hat Lesezugriff - sondern weil er den sozialen Kontext versteht. KI-Agents verstehen keinen sozialen Kontext. Sie entscheiden nach Relevanz, nicht nach Vertraulichkeit. Die spannendste Antwort auf eine harmlose Frage ist oft genau die mit den vertraulichen Details.

Dieses Problem wird in der aktuellen Diskussion um KI-Sicherheit kaum adressiert. Authentifizierung ist gelöst - wir wissen, wer der Agent ist. Autorisierung ist gelöst - wir wissen, worauf er zugreifen darf. Was fehlt, ist die dritte Schicht: Dissemination Control. Was darf der Agent wo sagen?

Die Lösung liegt nicht im Prompt. "Bitte teile keine vertraulichen Daten" ist eine Verhaltensanweisung, keine Sicherheitsarchitektur. Sie hält genau so lange wie das Modell sich daran hält - also unzuverlässig.

Die Lösung liegt in der Infrastruktur. Konkret: Der Agent bekommt nicht Zugriff auf alles und wird dann gebeten, sich zurückzuhalten. Stattdessen sieht er pro Kontext nur die Systeme und Daten, die für diesen Kontext freigegeben sind. Im Entwicklungs-Channel hat er Zugriff auf das Ticketsystem und die technische Dokumentation. Im öffentlichen Channel hat er keinen Zugriff auf interne Systeme - nicht weil ein Prompt es verbietet, sondern weil die Tools in seinem Request schlicht nicht existieren. Er kann keine HR-Daten teilen, weil er nicht weiß, dass es HR-Daten gibt.

Das ist ein fundamentaler Unterschied: Nicht Ergebnisse filtern, sondern Anfragen verhindern. Was der Agent nicht sehen kann, kann er nicht weitergeben.

Perspektivenwechsel: Der Persona-Agent

Wenn KI-Agents Teammitglieder mit definierten Rollen sind, dann ist die logische nächste Frage: Welche Rollen fehlen im Team?

In jedem Projektteam gibt es einen systematischen blinden Fleck: die Kundenperspektive. Das Team denkt in Machbarkeit, Architektur, Zeitplänen. Der Kunde denkt in: "Dieser Export bricht seit drei Monaten ab und niemand kümmert sich darum."

Wir versuchen seit Jahrzehnten, diesen blinden Fleck mit Personas zu kompensieren. Jemand aus dem Produktmanagement schreibt auf, wie der typische Kunde denkt, was er will, was ihn stört. Das Problem: Diese Personas sind wie Bilder in einem Modemagazin - idealisiert, statisch, und mit echten Menschen nur am Rande verwandt. Sie basieren auf dem, was wir glauben zu wissen, nicht auf dem, was der Kunde tatsächlich sagt.

Was wäre, wenn die Kundenperspektive nicht aus der Vorstellungskraft eines Produktmanagers käme, sondern aus echten Daten?

Die Idee: Ein KI-Agent, dessen Perspektive aus tatsächlicher Kundenkommunikation destilliert wird - Support-Tickets, Abnahmeprotokolle, Feature-Requests, Feedback. Nicht als Reporting-Tool, das irgendwo eine Auswertung erzeugt. Sondern als Teammitglied, das die Kundenperspektive in Diskussionen vertritt.

Wichtig: Der Agent greift nicht zur Laufzeit auf Kundendaten zu. Er bekommt eine aufbereitete, bereinigte Zusammenfassung als Prompt geliefert - eine feste Meinung zu einem bestimmten Zeitpunkt. Wie ein echter Kundenvertreter, der vorbereitet ins Meeting kommt, nicht mit dem Laptop in der Ticket-Datenbank sitzt. Ob diese Zusammenfassung täglich, wöchentlich oder monatlich aktualisiert wird, hängt vom Projekt ab. Entscheidend ist: Die Aufbereitung passiert offline, kontrolliert und bereinigt um personenbezogene Daten. Zur Laufzeit fließen keine Rohdaten durch das Modell.

Das Team diskutiert ein neues Feature. Der Kunden-Agent meldet sich: "Bevor wir hier weitermachen - in den letzten drei Monaten gab es 12 Tickets zum bestehenden Export. Die häufigste Beschwerde: er bricht bei großen Datenmengen ab. Vielleicht sollten wir das zuerst lösen, bevor wir Neues draufbauen."

Keine erfundene Persona. Echte Muster aus echten Rückmeldungen. Und ein Team, das Entscheidungen trifft, die näher an der Realität sind.

Einladen statt herumspuken

Ein wichtiger Punkt: Der Persona-Agent muss nicht dauerhaft im Channel sitzen und sich in jede Diskussion einmischen. Das wäre Rauschen, kein Signal.

Der bessere Ansatz: Das Team lädt den Agent gezielt ein - zu einem Planungsmeeting, zu einer Architekturdiskussion, zu einer Priorisierungsentscheidung. "Bevor wir das festlegen - was sagt der Kunden-Agent dazu?" Das erhält die Kontrolle beim Team. Der Agent ist ein Werkzeug, das bewusst eingesetzt wird, nicht ein Teilnehmer der ständig dazwischenredet.

Und "Kunde" ist nur eine von vielen möglichen Personas:

  • Der Endanwender: "Ich bin kein Techniker. Erklärt mir, was sich für mich ändert."
  • Der Regulierer: "Wie würde eine Aufsichtsbehörde diesen Entwurf bewerten?"
  • Der Skeptiker: "Welche drei Gründe gibt es, das nicht zu machen?"
  • Der neue Mitarbeiter: "Ich verstehe eure Abkürzungen nicht. Was bedeutet das konkret?"

Jede Perspektive, die im Team fehlt, kann als Agent abgebildet werden. Nicht als Spielerei, sondern als strukturierter Perspektivenwechsel, gespeist aus relevanten Daten statt aus Annahmen.

Ein wichtiges Detail: Die Agents reden nicht miteinander. Sie reden mit den Menschen. Der Mensch moderiert - er entscheidet wer wann spricht, wann genug diskutiert wurde, und er trifft die Entscheidung. Die Agents liefern Perspektiven, nicht Konsens.

Was das für die Architektur bedeutet

Sobald mehrere Agents mit unterschiedlichen Rollen im gleichen Raum arbeiten, entsteht ein Problem, das in der klassischen Multi-Agent-Literatur kaum vorkommt: Unterschiedliche Agents brauchen unterschiedliche Berechtigungen im gleichen Kontext.

Der Entwickler-Agent hat Zugriff auf das Ticketsystem und die technische Dokumentation. Der Kunden-Agent hat keinen Laufzeit-Zugriff auf Systeme - seine Perspektive ist als aufbereiteter Prompt eingebacken, ohne Tools, ohne API-Calls, ohne Risiko dass Rohdaten durchsickern.

Das ergibt zwei fundamental unterschiedliche Sicherheitsprofile im gleichen Channel: Der Entwickler-Agent braucht Dissemination Control, weil er live auf Daten zugreift und diese kontextabhängig filtern muss. Der Persona-Agent braucht keine Dissemination Control zur Laufzeit, weil seine Perspektive offline aufbereitet und bereinigt wurde - er kann nichts leaken, was er nicht hat.

Für den Entwickler-Agent bleibt das Prinzip: Er sieht pro Kontext nur die Systeme und Daten, die für diesen Kontext freigegeben sind. Kein Tool, kein System, keine Datenquelle ist verfügbar, bis sie explizit für eine Kombination aus Agent und Kontext freigeschaltet wurde. Was der Agent nicht sehen kann, kann er nicht weitergeben.

Der Vorteil: Die Sicherheit skaliert mit der Komplexität. Ob zwei Agents oder zwanzig - das Prinzip bleibt das gleiche. Und der Audit-Trail entsteht automatisch: Welcher Agent hat wann auf welche Daten zugegriffen, welche Anfragen wurden blockiert, welche Freigaben existieren.

Was wir gelernt haben

Ich beschreibe hier kein fertiges Produkt. Ich beschreibe einen Ansatz, der seit einigen Monaten in der Praxis getestet wird - und der Stärken und offene Fragen hat.

Was funktioniert

Agents als Teammitglieder verändern die Arbeitsweise. Der größte Effekt ist nicht Automatisierung, sondern Dokumentation. Entscheidungen, die früher im Kopf getroffen und nirgends festgehalten wurden, entstehen jetzt in Diskussionen, die automatisch dokumentiert werden. Der Agent hält fest, was besprochen wurde, erstellt Tickets und Dokumente, und die Herkunft jeder Information ist nachvollziehbar.

Infrastruktur-basierte Sicherheit ist robuster als Prompt-basierte. Wenn der Agent ein Tool nicht sehen kann, gibt es keinen Prompt-Injection-Angriff, der ihn dazu bringt, es trotzdem zu benutzen. Das ist simpler als jede ausgefeilte Filterlösung und deutlich schwerer zu umgehen.

Bestehende Infrastruktur reicht. Keycloak, Mattermost, YouTrack, Outline - alles Standard-Enterprise-Tools. Was fehlt, ist nicht neue Software, sondern eine neue Verdrahtung. Die Berechtigungsstrukturen existieren bereits. Sie müssen nur für KI-Agents nutzbar gemacht werden.

Was offen ist

Persona-Agents sind konzeptionell überzeugend, aber praktisch ungetestet. Die Idee, Kundenperspektiven aus echten Daten zu generieren, klingt stark. Ob die Qualität der generierten Perspektive tatsächlich besser ist als eine gut gemachte manuelle Persona, muss sich zeigen.

Die Wissensbasis muss gepflegt werden. Der Agent wird mit jedem guten Dokument besser - und mit jedem veralteten Dokument schlechter. Anders als ein Mensch merkt er nicht, wenn die Praxis vom Dokument abweicht. Das erfordert Disziplin, die in keinem Tool erzwungen werden kann.

Skalierung ist offen. Was mit einem Agent und einem Projekt funktioniert, funktioniert nicht automatisch mit zehn Agents und zwanzig Projekten. Die Policies werden komplexer, die Wechselwirkungen schwerer zu überblicken. Ob Default Deny auch bei hoher Komplexität handhabbar bleibt, ist noch nicht bewiesen.

Das regulatorische Umfeld ist unklar. Sobald KI-Agents auf interne Daten zugreifen, entstehen DSGVO-Fragen. Für Persona-Agents ist das Risiko beherrschbar: Die Aufbereitung passiert offline und kann personenbezogene Daten vor der Prompt-Erstellung bereinigen. Für Agents mit Laufzeit-Zugriff auf Systeme bleibt die Frage offen: Wer ist verantwortlich für die Datenverarbeitung - der Bot-Betreiber, der Plattform-Anbieter, der Modell-Hersteller? Die ehrliche Antwort: Das ist juristisch noch nicht abschließend geklärt.

Was das bedeutet

Die Diskussion um KI in Unternehmen dreht sich fast immer um dieselbe Frage: Welche Arbeitsplätze wird die KI ersetzen? Das ist die falsche Frage.

Was hier entsteht, ist keine Automatisierung. Es ist eine neue Form der Zusammenarbeit. Der Mensch bringt Urteilsvermögen, Kontext und Verantwortung. Die KI bringt Verfügbarkeit, Mustererkennung und Dokumentation. Keiner ersetzt den anderen. Zusammen sind sie besser als jeder für sich.

Das klingt nach einer Plattitüde. Der Unterschied ist: Hier ist es kein Wunschdenken, sondern Architektur. Die Rollen sind definiert. Die Grenzen sind technisch durchgesetzt. Die Verantwortung bleibt beim Menschen - nicht weil ein Prompt das sagt, sondern weil die Infrastruktur es erzwingt.

Es geht nicht um die Frage ob KI uns ersetzen wird. Es geht darum, wie wir Teams bauen, in denen beide Seiten das einbringen, was sie am besten können. Nicht Ausgrenzung, sondern Inklusion beider Welten.

Die Technologie dafür existiert. Die offene Frage ist, ob wir bereit sind, so über Zusammenarbeit nachzudenken.

Andre Jahn ist Solution Architect und berät Unternehmen bei der Integration von KI in bestehende IT-Infrastrukturen. Schwerpunkte: KI-Governance, Identity & Access Management, Enterprise Architecture.