Produktive AI Agents auf Databricks: Vertriebsreports automatisch in Salesforce

Der Agent ruft eigenständig registrierte Unity-Catalog-Funktionen auf, verdichtet die strukturierten Ergebnisse iterativ zu einem narrativen Kundenreport, lässt den Report zwei Evaluierungen durchlaufen und schreibt ihn per Upsert in Salesforce. Reasoning und Datenzugriff sind getrennt: das LLM entscheidet über den Ablauf, die Tools liefern die geprüften Daten.

Ein Dashboard zeigt Zahlen. Ein Account-Manager braucht eine Einordnung: welcher Kunde jetzt Aufmerksamkeit braucht, warum, und was der wahrscheinliche Hebel ist. Genau dieser Schritt von der aggregierten Kennzahl zur narrativen Empfehlung war bisher analytische Handarbeit. Der Agent übernimmt ihn strukturiert und wiederholbar.

Kein Report landet ungeprüft im CRM. Zwei Evaluierungen laufen vor jeder Salesforce-Auslieferung: eine semantische Prüfung auf fünf Qualitätsdimensionen (Safety, Relevancy, Tone, Analytical Quality, Fluency) über eine zweite Claude-Opus-Instanz als LLM-as-Judge und eine deterministische Prüfung, die jede Report-Sektion algorithmisch gegen den strukturierten Tool-Output vergleicht. Ein Struktur-Score von 1.0 ist Pflicht für die Freigabe.

Unity Catalog Functions sind Datenzugriffs- und Analyse-Bausteine, die versioniert im Katalog registriert sind. Der Agent wählt zur Laufzeit, welche Funktionen er aufruft. Neue Tools lassen sich hinzufügen, ohne den Agent neu zu bauen. Änderungen an einer Datenaggregation ändern nichts am Agent-Code. Das entkoppelt Reasoning und Datenschicht sauber.

Prompts laufen über MLflow Prompt Registry. Sie sind versioniert und unabhängig vom Agent-Code deploybar. Eine Prompt-Änderung triggert die Prompt-Pipeline, keinen Agent-Rebuild. Few-Shot-Beispiele halten den Output konsistent. Jede Prompt-Version ist über MLflow nachvollziehbar.

Nach bestandener Evaluierung werden die Reports per Upsert in dedizierte Salesforce-Objekte geschrieben. Account-Manager finden sie im CRM, ohne dass ein Mensch exportiert, formatiert oder verteilt. Lakeflow Jobs takten den Monatslauf, Databricks SQL Alerts überwachen die Auslieferung.

MLflow ResponsesAgent ist das Framework für den Agent-Kern. Es kapselt Reasoning-Loop, Tool-Aufrufe und Trace-Logging. Der Agent bleibt Databricks-native, integriert sich mit Unity Catalog und Prompt Registry und ist über MLflow deploy- und versionierbar.

Sinnvoll ist ein Reporting-Agent überall dort, wo narrative Kundeneinordnungen, Performance-Reports oder Analysen heute noch aus Datenabfragen, Templates und manueller Textarbeit entstehen, und wo das linear mit Kundenzahl, Produkten oder Regionen skaliert. Voraussetzung ist ein sauberer Datenzugriff, nicht eine bestimmte Konzerngröße.

Für diese Architektur ja: Unity Catalog trägt die Tool-Registry, MLflow trägt Agent und Prompts, Mosaic AI Model Serving trägt das LLM. Ohne Lakehouse-Basis wäre der Aufbau ein anderes Projekt. Wenn ein Lakehouse geplant oder im Aufbau ist, lässt sich der Agent-Ansatz in die Roadmap einbetten.

Ein ETL-Report führt eine feste Pipeline aus und liefert eine feste Struktur. Ein Workflow orchestriert eine Kette definierter Schritte. Ein Agent entscheidet zur Laufzeit, welche Tools er in welcher Reihenfolge aufruft, und formuliert das Ergebnis narrativ. ETL und Workflows sind deterministisch, ein Agent ist reasoning-getrieben. Deshalb ist die Evaluierungsschicht Teil der Architektur, nicht optional.

Model Context Protocol beschreibt ein Muster, in dem ein LLM Werkzeuge zur Laufzeit entdeckt und aufruft, statt sie hart im Code zu haben. Im Projekt sind alle Datenzugriffe als Unity-Catalog-Funktionen registriert, der Agent wählt zur Laufzeit die passenden Tools und reicht die Ergebnisse iterativ ans LLM zurück. Der Reasoning-Kern bleibt schlank, die Tool-Registry ist versionierbar.