Artikel 5/7 — Die Agenten und ihre Skills: Wer was baut

2 Min. LesezeitKünstliche Intelligenz

Im fünften Artikel der Serie #BIwithAI geht es um die Rollen, die die unterschiedlichen Agenten einnehmen. Diese Rollen sind wichtig und müssen natürlich miteinander kommunizieren. Nur wie funktioniert das zwischen Agenten? Das erkläre ich euch hier im Artikel. #AI #PowerBI #MSFabric #Fabric #Microsoft

Artikel 5/7 — Die Agenten und ihre Skills: Wer was baut

Kein gutes Team lässt dieselbe Person die Anforderung schreiben, umsetzen und selbst abnehmen. Unser Agentensystem folgt exakt diesem Prinzip — und genau das macht es verlässlich.

Der Alleskönner ist das Problem

Ein einzelner Agent, der plant, baut und sich selbst abnimmt, ist strukturell blind für die eigenen Fehler. Wir haben die Arbeit deshalb auf spezialisierte Agenten mit klar begrenzten Rechten verteilt.

Die Rollen

  • Der Orchestrator (Dirigent). Einziger Einstiegspunkt. Er plant, routet und verwaltet den Zustand — er codet nicht selbst. Schreibrechte: nur im Zustandsbereich. Ausführbare Kommandos: nur die geprüften, freigegebenen Skripte des Systems.
  • Der Power-BI-Spezialist (BI-Spezialist). Baut Semantic Models und Berichte über das offene Power-BI-Projektformat. Werkzeuge: Report- und Modell-Autorenwerkzeuge, eine Desktop-Bridge zu Power BI, Fabric- und Cloud-CLIs, Python/Node. Er darf Report- und Modelldateien schreiben, aber niemals die zentralen Zustandsdateien.
  • Der Data-Engineering-Worker. Übernimmt Spark, Warehouse/SQL, KQL, Eventstreams, Dataflows und Migrationen.
  • Der unabhängige Prüfer. Unabhängig, rein lesend. Er bekommt nur Screenshots und die Akzeptanzkriterien — bewusst ohne die Schlussfolgerungen des Orchestrators — und urteilt je Kriterium: PASS oder NEEDS_CHANGES. Keine Selbstbenotung.

Dazu kommen fachliche Personas als Referenz für Governance, Migration und Datenfragen.

Skills: das geteilte Fachwissen

Die Agenten „wissen" nicht alles selbst — sie laden Skills: über 30 gekapselte, wiederverwendbare Fachworkflows. Für Power BI zum Beispiel:

  • Semantic-Model-Authoring — TMDL, Star-Schema, DAX-Guidelines, Performance-Patterns, Naming-Konventionen.
  • Report-Authoring — Visuals, Slicer, Tabellen, Karten, Formatierung, Theming.
  • Report-Design — Layout, Farbe, Typografie, Accessibility, Visual-Auswahl, Anti-Patterns.
  • Report-Planung und -Management — Planung und Publishing.
  • Template-Compliance — Bindung an eine verbindliche Corporate-Vorlage.

Für die Datenseite gibt es Skills für Spark, SQL-Warehouse, Eventhouse, Dataflows und Migrationen (Synapse/HDInsight/Databricks) und mehr. Welcher Agent welche Skills nutzt, steht deklarativ in einem zentralen Routing-Regelwerk.

Kommunikation über Dateien, nicht über Gerede

Der Orchestrator delegiert nicht per formloser Nachricht, sondern über einen festen Übergabeblock im standardisierten Übergabedokument — Auftrag, zu erfüllende Kriterien, Constraints. Der Worker liest ihn und schreibt sein RESULT im selben Format zurück. Wie bei „Stille Post" geht formlos zu viel verloren; ein strukturiertes Kontrakt-Artefakt ist eindeutig, prüfbar und bleibt erhalten.

Wer baut, sollte nicht abnehmen. Diese Trennung ist kein Misstrauen — sie ist Qualität.

Wie trennen Sie „Bauen" und „Abnehmen" in Ihren BI-Pipelines? 👇

#MicrosoftFabric #PowerBI #MultiAgentSystems #Softwarearchitektur #AIAgents #SeparationOfConcerns

Teilen:

Weitere Artikel