Ein Orchestrator, drei Fachagenten für Produktauskünfte

Ausgangslage

Die Daten waren bereits erschlossen. Aus einem vorangegangenen Projekt existierten zwei durchsuchbare Indizes — ERP-Artikelstammdaten mit Beständen, Bestellungen und Absatz, und Produktinhalte mit mehrsprachigen Texten und Dokumentlinks — samt einem Backend, das eine Schnittstelle bereitstellte, die bereits für die Anbindung eines Agenten zugeschnitten war.

Was fehlte, war der Zugang in natürlicher Sprache. Wer wissen wollte, ob ein Artikel verfügbar ist, wann Nachschub kommt und welches Sicherheitsdatenblatt dazugehört, musste weiterhin die Oberfläche bedienen und wissen, wo er suchen muss. Dazu kam eine dritte Quelle, die in keinem Index lag: Dokumente in SharePoint.

Der naheliegende nächste Schritt war ein Agent, der auf alles antwortet.

Ansatz

Gebaut wurde stattdessen eine Struktur aus vier Agenten in Copilot Studio.

Ein übergeordneter Agent nimmt die Frage entgegen und entscheidet, welches Fachwissen sie braucht. Er beantwortet selbst nichts inhaltlich — seine Aufgabe ist die Zuordnung und, wenn die Antwort zurückkommt, deren Zusammenführung zu einer Auskunft.

Darunter liegen drei spezialisierte Agenten, geschnitten nach Quellsystem:

• einer für ERP-Artikeldaten — Bestand je Lagerort, offene Bestellungen und Wiederbeschaffung, Absatz
• einer für Produktinhalte — Beschreibungen, Klassifizierungen, mehrsprachige Texte und die verknüpften Dokumente
• einer für SharePoint als Wissensquelle — Dokumente, die in keinem der beiden Indizes liegen

Die ersten beiden greifen nicht auf das Data Warehouse zu, sondern auf die bereits vorhandene Schnittstelle der Artikelsuche. Sie erben damit den täglichen Neuaufbau des Index, die Zusammenführung auf ein Dokument je Artikel und Land — und die Feldauswahl, die dort ohnehin schon serverseitig entschieden wird.

Der Punkt, an dem es anders hätte laufen können

Ein Agent mit drei Wissensquellen wäre der offensichtliche Bau gewesen. Geschnitten wurde stattdessen nach Quellsystem.

Copilot Studio lässt ohne Weiteres zu, mehrere Wissensquellen an einen Agenten zu hängen. Genau das ist der Standardweg, und er hat einen konkreten Fehlermodus: Die Quellen konkurrieren im selben Kontextfenster. Eine SharePoint-Präsentation, die einen Artikel erwähnt, und ein ERP-Datensatz zu demselben Artikel sind für die Abrufmechanik ähnlich relevant — inhaltlich aber nicht austauschbar. Der eine ist tagesaktuell und strukturiert, der andere ist ein Dokument von unbekanntem Stand.

Die Aufteilung macht diese Unterscheidung zu einer Architekturentscheidung statt einer Abrufwahrscheinlichkeit. Jeder Fachagent hat genau eine Quelle, eine eigene Anweisung und ein eigenes Verhalten bei Nichtwissen. Und sie lassen sich einzeln prüfen: Wenn Bestandsauskünfte falsch sind, ist bekannt, welcher Agent das war.

Der Preis ist real und gehört dazu. Die Weiterleitung ist ein zusätzlicher Schritt, der selbst falsch entscheiden kann — eine Frage, die nach Produktinhalt klingt, aber Bestandsdaten braucht, landet beim falschen Agenten. Und eine Frage, die zwei Systeme gleichzeitig betrifft, verlangt vom übergeordneten Agenten, beide zu befragen und zusammenzuführen, statt dass ein einzelner Agent beides ohnehin im Kontext hätte.

Ergebnis

Vier Agenten, drei angebundene Quellsysteme, keine neue Datenhaltung. Der teuerste Teil einer solchen Lösung — Daten aus SAP und dem Produktdatensystem verlässlich, täglich und in abfragbarer Form bereitzustellen — war bereits gebaut und wurde weiterverwendet. Der Aufwand dieses Projekts lag in der Zuschnitt- und Weiterleitungslogik, nicht in der Datenbeschaffung.

Bewusst nur lesend: Kein Agent schreibt in ein Quellsystem zurück. Bestellungen, Umlagerungen und Stammdatenpflege passieren weiterhin dort, wo sie hingehören.

Die vererbten Grenzen der Datenschicht gelten unverändert weiter und sind es wert, genannt zu werden: Der Index wird einmal täglich aufgebaut, es ist also keine Echtzeit-Verfügbarkeits- prüfung, und weil er bei jedem Lauf überschrieben wird, kann kein Agent sagen, was sich seit gestern geändert hat. Der SharePoint-Agent hat diese Einschränkung nicht — dafür aber die umgekehrte: Er antwortet aus Dokumenten, deren Stand niemand garantiert.