Agent Bricks auf Databricks: Wann Templates ausreichen und wann ein eigener Agent sinnvoller ist
Die Kernaussagen auf einen Blick.
- Databricks Agent Bricks bietet vorkonfigurierte Templates für Wissensassistenten, Extraktion und Agent-Routing direkt in der eigenen Databricks-Umgebung.
- Der größte Vorteil ist die integrierte Evaluation: synthetische Testfälle, automatisierte Bewertung und wiederholbare Optimierungsläufe über MLflow.
- Drei Fragen entscheiden vor jeder Auswahl: Passt der Use Case zum Template, stehen die nötigen Modelle in der eigenen Region bereit, und ist die Verantwortung für Testdaten und Freigaben geklärt?
- Individuelle Agenten bleiben die bessere Wahl, wenn eigene Orchestrierung, Zustandslogik oder spezialisierte Evaluationsanforderungen über die Template-Grenzen hinausgehen.
- Ein Wissensassistent auf internen Dokumenten eignet sich als erster Referenzfall für den Knowledge Assistant, bevor größere Custom-Agent-Investitionen folgen.
Inhaltsverzeichnis
Im Notebook läuft er, produktiv noch nicht
In vielen Projekten zeigt sich ein ähnliches Muster. Der Wissensassistent läuft im Notebook und beantwortet erste Beispielfragen aus dem internen Handbuch. Die erste Demo überzeugt fachlich. Einige Wochen später steht die Frage, ob die Anwendung produktiv genutzt werden kann. Für den produktiven Einsatz fehlen jedoch häufig Evaluation, stabile Datenanbindung und ein geregelter Änderungsprozess. Es gibt noch kein repräsentatives Testset und keine klaren Freigabekriterien. Die Datenanbindung basiert noch auf provisorischem Code oder manuellen Schritten. Änderungen an Prompt, Modell oder Retrieval werden nicht systematisch gegen eine bekannte Baseline geprüft.
Mit mehreren parallelen Agentenprojekten wiederholen sich dieselben Aufgaben. Jedes Team entwickelt eigene Datenanbindung, Orchestrierung, Logging und Evaluation. Ein erheblicher Teil der Entwicklungszeit fließt in wiederkehrende Qualitäts- und Betriebsfunktionen. Die fachliche Weiterentwicklung des eigentlichen Anwendungsfalls beginnt dadurch später.
Agent Bricks soll Teile dieser wiederkehrenden Aufgaben innerhalb der Databricks-Plattform reduzieren. Die relevante Architekturfrage lautet daher: Für welche standardisierten Anwendungsfälle reduziert Agent Bricks Entwicklungs- und Betriebsaufwand? Und bei welchen Anforderungen bleibt ein individuell entwickelter Agent die bessere Wahl?
Was ist Databricks Agent Bricks?
Agent Bricks stellt vorkonfigurierte Bausteine für bestimmte Agenten- und GenAI-Anwendungsfälle bereit. Typische Einsatzfelder sind Wissensassistenten auf interner Dokumentation, strukturierte Extraktion aus Verträgen oder Formularen und das Routing von Anfragen zwischen mehreren spezialisierten Agenten. Das Team beschreibt den Anwendungsfall, verbindet die benötigten Daten und hinterlegt repräsentative Beispiele. Die Plattform kann daraus zusätzliche synthetische Testfälle erzeugen. Je nach Template und Konfiguration werden geeignete Modelle oder Modellvarianten verglichen. Prompts und weitere Parameter können anhand automatisierter Bewertungen iterativ angepasst werden. Runs, Konfigurationen und Evaluationsergebnisse lassen sich über MLflow dokumentieren. Die ausgewählte Konfiguration kann anschließend über Model Serving bereitgestellt werden. Unity Catalog kann Daten, Funktionen, Berechtigungen und weitere Plattformobjekte in einer gemeinsamen Governance-Struktur verbinden. Wie vollständig Versionierung, Lineage und Auditinformationen vorliegen, hängt von der konkreten Konfiguration und den eingesetzten Komponenten ab. Damit deckt Agent Bricks die vier häufigsten Agenten-Baumuster ab, ohne dass Teams die Evaluations- und Betriebsschicht selbst entwickeln müssen.
Agent Bricks ersetzt kein frei programmierbares Agentenframework. Die Templates sind auf eine begrenzte Zahl klar abgegrenzter Anwendungsfälle ausgerichtet. Für individuelle Orchestrierung, komplexe Zustandslogik oder besondere Toolabläufe ist weiterhin ein eigener Agent über das Databricks Agent Framework sinnvoll. Agent Bricks und Genie adressieren unterschiedliche Aufgaben. Genie richtet sich auf natürlichsprachliche Analysen strukturierter Unternehmensdaten. Agent Bricks konzentriert sich je nach Template auf dokumentenbasierte Fragen, Extraktion, Agentenrouting oder klar definierte Sprachaufgaben.
Der wichtigste Unterschied zu einem reinen Framework-Setup ist die stärkere Integration von Evaluation und Optimierung. Wie viel Entwicklungsaufwand dadurch eingespart wird, hängt vom vorhandenen Framework, der Teamreife und den Qualitätsanforderungen ab. Wie sich diese Komponenten in die übrige GenAI-Strecke einordnen (von Foundation Model APIs bis Vector Search), zeigen wir im Überblick zu künstlicher Intelligenz auf Databricks.
Vom Modell bis zur Auslieferung, in einem Loop.
Sechs Stages: Modellzugriff, Tools, Kontext, Orchestrierung, Publishing und Observability. Unity Catalog spannt Governance über jede Stage.
Pick your brain
Native Access zu Frontier-Modellen
Give it governed actions
Managed Tools + Integrationen
Give it context & memory
Knowledge, Enterprise-Context, Memory
Observe & Improve
MLflow Judge, Trace, Review App
Publish it
Channels & Interfaces
Orchestrate it
Supervisor, Custom Agents, Open Frameworks
Pick your brain
Native Access zu Frontier-Modellen
Give it governed actions
Managed Tools + Integrationen
Give it context & memory
Knowledge, Enterprise-Context, Memory
Orchestrate it
Supervisor, Custom Agents, Open Frameworks
Publish it
Channels & Interfaces
Observe & Improve
MLflow Judge, Trace, Review App
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Welche Agent-Bricks-Templates gibt es?
Databricks beschreibt mehrere spezialisierte Templates; Anzahl, Funktionsumfang und Reifegrad sollten für die eigene Region aktuell geprüft werden. Jedes Template ist auf eine bestimmte Aufgabenklasse und Bewertungslogik ausgerichtet.
| Template | Anwendungsfall | Eingabe | Bewertungslogik | Modell-Auswahl | Reifegrad |
|---|---|---|---|---|---|
| Knowledge Assistant unterstützt Fragen und Antworten auf internen Dokumenten und Wissensbeständen. | Q&A auf interner Doku, Wissensassistent | Unity-Catalog-Tabellen, Vector-Search-Index, Dokumente | Synthetisches Q&A-Set, LLM-basierte Antwortbewertung | Foundation Model APIs + Unity AI Gateway | je nach Region und Produktstand zu prüfen |
| Information Extraction überführt Inhalte aus Dokumenten in ein definiertes strukturiertes Schema. | Strukturierte Extraktion aus Verträgen, Rechnungen, Berichten | Unstrukturierte Dokumente + Ziel-Schema | Synthetische Beispiele aus Domäne, Feld-für-Feld-Bewertung | Foundation Model APIs + Unity AI Gateway | je nach Region und Produktstand zu prüfen |
| Ein Multi-Agent Supervisor kann Anfragen zwischen spezialisierten Agenten verteilen. | Routing zwischen spezialisierten Agenten | Sub-Agenten + Routing-Regeln | Routing-Treffer + End-to-End-Antwortqualität | Foundation Model APIs + Unity AI Gateway | je nach Region und Produktstand zu prüfen |
| Ein Custom-LLM- oder Optimierungs-Template kann für eng definierte Aufgaben, Formate oder Tonalitäten eingesetzt werden, sofern es in der eigenen Umgebung verfügbar ist. | Klar abgegrenzte Sprach- und Antwortaufgaben | Domänen-Texte, Beispiele, Task-Beschreibung | Synthetische Task-Eval-Sets, Vergleichsbewertung | Foundation Models (eingeschränkte Auswahl) | je nach Region und Produktstand zu prüfen |
Reifegrad und regionale Verfügbarkeit sollten unmittelbar vor der Projektentscheidung in der offiziellen Dokumentation geprüft werden.
Knowledge Assistant
Der Knowledge Assistant eignet sich besonders für klassische Wissensassistenten auf internen Dokumenten. Als Datenbasis kann ein geeigneter Suchindex oder eine vorbereitete Tabelle dienen. Ein kleiner Satz repräsentativer Fragen und gewünschter Antworten bildet den Ausgangspunkt für die Evaluation. Den vollständigen Setup-Pfad dokumentiert Databricks unter Knowledge Assistant. Aus diesen Beispielen und den Quelldaten können weitere synthetische Testfälle erzeugt werden. Prompt, Retrieval und Modellkonfiguration lassen sich anschließend anhand des Testsets vergleichen. Die ausgewählte Version kann als Endpoint bereitgestellt und mit MLflow-, Serving- und Kosteninformationen verknüpft werden. Ein standardisierter Aufbau kann schneller produktionsreif werden als ein vollständig eigener RAG-Stack; konkrete Zeitangaben hängen jedoch stark von Datenqualität, Berechtigungen und Freigabeprozessen ab.
Information Extraction
Information Extraction richtet sich an dokumentenbasierte Strukturierungsaufgaben. Das Team legt fest, welche Felder und Datentypen aus den Dokumenten extrahiert werden sollen. Die Plattform kann zusätzliche Beispiele erzeugen und Extraktionsvarianten anhand der definierten Felder vergleichen. Die Qualität kann pro Feld, Format und Dokumenttyp bewertet werden. Felder mit niedriger Genauigkeit lassen sich separat analysieren und verbessern (etwa Datumsformate, Beträge in unterschiedlichen Währungen oder Vertragsklauseln in mehreren Sprachvarianten). Pro Feld lassen sich Pflichtkriterien, zulässige Wertebereiche und Formatregeln vorgeben; das Modell wird gegen diese Vorgaben optimiert.
Das Template eignet sich gut für strukturierte Massenverarbeitung, Vertragsdaten, Lieferanten-Dokumente und klinische Berichte. Bei unterschiedlichen Layouts, Sprachen oder Dokumentarten kann eine vorgelagerte Typisierung die Extraktionsqualität verbessern, weil sich die Genauigkeit pro Subtyp deutlich unterscheiden kann. Der Aufwand eines Eigenbaus hängt stark von Dokumentvielfalt, OCR-Qualität, Schema und vorhandenen Bibliotheken ab.
Multi-Agent Supervisor und Custom LLM
Der Multi-Agent Supervisor koordiniert mehrere spezialisierte Agenten. Sub-Agenten und ihre Zuständigkeiten werden beschrieben und getestet (z. B. ein Knowledge Assistant für Produktfragen, ein Information-Extraction-Template für Vertragsanfragen, ein externer API-Agent für Statusabfragen). Auf Basis der Anfrage wird ein geeigneter Agent ausgewählt oder ein definierter Ablauf gestartet. Typische Anwendungsfälle sind einheitliche Kunden- oder Mitarbeiter-Chats, die mehrere Backends ansprechen.
Funktionen zur Anpassung oder Optimierung eines Modells können sich je nach Produktstand noch in Preview befinden. Der Ansatz richtet sich an klar definierte Aufgaben, bei denen Prompting allein nicht stabil genug ist, ein vollständiges Fine-Tuning aber unverhältnismäßig wäre. Je nach Funktion kann das Ergebnis aus einer optimierten Modell-, Prompt- und Parameterkonfiguration bestehen. Das Template eignet sich besonders für klar abgegrenzte Aufgaben (z. B. Klassifikation in eine feste Kategorienliste, formatierte Zusammenfassungen, strukturierte Antworten in einer Vorlagensprache). Für offene, mehrstufige oder schwer messbare Aufgaben ist ein spezialisiertes Template häufig nicht flexibel genug.
Wie funktioniert die Evaluation?
Die integrierte Evaluation ist einer der wichtigsten Vorteile des Ansatzes. Der Mechanismus lässt sich grob in drei Schritte gliedern.
Synthetische Testfälle erzeugen
Aus Beispielen und Domänendaten werden zusätzliche Testfälle erzeugt (für Knowledge Assistant aus Index und Tabellen, für Information Extraction aus Schemas und Beispielen). Die erzeugten Testfälle sollten fachlich geprüft, ergänzt und bei Bedarf entfernt werden.
Antworten automatisiert bewerten
Ein Bewertungsmodell schätzt Antworten anhand definierter Kriterien ein: Faktentreue, Vollständigkeit, Format oder anwendungsspezifische Anforderungen. Welche Bewertungsmodelle verfügbar sind, sollte für den aktuellen Produktstand geprüft werden.
Varianten vergleichen
Mehrere Prompt-, Retrieval- oder Modellvarianten werden gegen dieselbe Testgrundlage verglichen. Die finale Auswahl braucht neben dem aggregierten Score immer auch eine fachliche Prüfung.
Änderungen sollten vor einer Freigabe erneut gegen das definierte Testset ausgeführt werden. In einem Eigenbau muss diese Bewertungs- und Vergleichslogik separat entwickelt und betrieben werden.
MLflow Tracing ergänzt die Evaluation um eine detaillierte Sicht auf einzelne Agentenschritte. Unterstützte Modell-, Retrieval- und Toolaufrufe können als zusammenhängende Traces erfasst werden. Je nach Framework und Integration reduziert sich der Bedarf an selbst gebauter Instrumentierung. Die Traces unterstützen Fehleranalysen, Qualitätsprüfungen und technische Auditfragen. Bei ausreichend vollständiger Protokollierung lässt sich nachvollziehen, welche Schritte zu einer Antwort geführt haben. Dabei können Modellversion, Toolparameter, Retrievalergebnisse und Laufzeiten sichtbar werden.
Den gleichen Eval-Mechanismus gibt es als eigenständige API über MLflow Agent Eval. In einem Custom-Agent lässt sich die Logik nutzen, ohne ganz auf Agent Bricks zu setzen. Wie sich Modelle und Agenten über den Lifecycle hinweg betreiben lassen, von Eval bis Drift, behandeln wir im Überblick zu Managed MLflow auf Databricks.
Wie entsteht ein Knowledge Assistant?
Der konkrete Aufbau eines Knowledge Assistant gliedert sich in mehrere Schritte. Die Reihenfolge ist für alle Q&A-Anwendungsfälle weitgehend vergleichbar.
Datenbasis vorbereiten
Dokumente strukturiert, versioniert und mit geeigneten Metadaten bereitstellen, etwa über Auto Loader, Lakeflow oder eigene Verarbeitung. Wichtige Metadaten: Quelle, Dokumentversion, Abschnitt, Sprache, Berechtigungsinformationen.
Domäne und Beispielfragen definieren
Fachbereich und Plattformteam legen repräsentative Fragen, erwartete Antworten und problematische Grenzfälle gemeinsam fest, inklusive typischer Fragetypen, Begriffsvarianten und Sonderfälle.
Retrieval konfigurieren
Suchindex, Embedding-Modell, Chunking, Filter und gegebenenfalls Reranking festlegen. Voreinstellungen nicht ohne fachliche Evaluation übernehmen.
Testset generieren und sichten
Synthetische Testfälle stichprobenartig oder kategoriebasiert fachlich prüfen: Passen die Fragen zur Zielgruppe, decken sie relevante Themen ab, sind die Antworten korrekt?
Optimierungsläufe starten und vergleichen
Die automatischen Iterationen laufen typischerweise über Stunden. Im MLflow-Vergleich werden Scores pro Dimension, Kosten pro Run und Antwortbeispiele sichtbar.
Endpoint deployen und absichern
Vor der Freigabe Berechtigungen, Logging, Limits, Guardrails und Monitoring einrichten. Berechtigungs- und Identitätsverhalten mit realistischen Testnutzern und geschützten Inhalten überprüfen.
Ein kontrollierter Pilot mit realen Anfragen hilft, Datenlücken und neue Frageklassen vor dem breiten Rollout zu erkennen.
Tools und externe Dienste
Viele Agentenanwendungen benötigen neben Wissenszugriff auch Berechnungen, APIs oder Aktionen. Agent Bricks unterstützt mehrere Tool-Typen, die als Objekte in Unity Catalog verwaltet werden können.
SQL- / Python-Funktionen
Registrierte Funktionen liefern strukturierte Datenabfragen und Geschäftslogik, etwa Aggregationen (`get_open_tickets_for_customer`), Statusabfragen (`order_status_by_id`) oder Berechnungen (`tariff_recommendation`). Klare Namen, Parameter und Toolbeschreibungen entscheiden, ob das Modell die Funktion korrekt auswählt.
MCP-Anbindungen
Externe Systeme wie Ticket-Tools, CRM-Systeme oder Wiki-Plattformen lassen sich strukturiert anbinden. Zugangsdaten zentral speichern, minimal berechtigen und regelmäßig überprüfen. Nur tatsächlich benötigte Werkzeuge freigeben.
Vector- und Suchindizes als Tools
Neben dem primären Wissensindex eines Knowledge Assistants können zusätzliche Indizes als Such-Tools registriert werden (FAQ-Index, Produktkatalog, Glossar). Das Template entscheidet zur Laufzeit, welcher Index die passende Quelle ist.
Tool-Disziplin
Eingabeparameter, Rückgabewerte, Berechtigungen und Fehlerverhalten pro Tool dokumentieren. Schreibende oder irreversible Aktionen durch Bestätigung, Genehmigung oder einen getrennten Kontrollschritt absichern.
Lebenszyklus eines Agenten
Für Agenten sollten getrennte Entwicklungs-, Test- und Produktionsstufen vorgesehen werden. Eine klare Trennung dieser Stufen erleichtert Tests, Freigaben und Rollbacks.
Entwicklungs-Endpoint
Prompt, Tools, Datenanbindung und Testset werden iteriert. Wesentliche Änderungen als neue Runs oder Versionen nachvollziehbar dokumentieren, um Vergleichbarkeit zu erhalten.
Test-Endpoint mit Aliasen
Eine geprüfte Kandidatenversion wird über einen stabilen Alias für Fachtests bereitgestellt. Fachbereich und Compliance prüfen reale Anfragen und entscheiden gemeinsam mit dem Plattformteam über die Freigabe.
Produktions-Endpoint
Die produktive Anwendung referenziert eine freigegebene Version oder einen kontrolliert verwalteten Alias. Ein Rückfall auf eine geprüfte Version läuft über eine kontrollierte Aliasänderung, ohne die Anwendung selbst anzupassen.
Kontrollierte Updates
Neue Testsets oder Modellwechsel laufen zunächst gegen den Test-Endpoint. Größere Änderungen können schrittweise oder parallel getestet werden, sofern Serving und Gateway das unterstützen.
Dokumentationspflichten
Für jede produktive Version werden Testset, Scores, Modelle, Tools, Berechtigungen und bekannte Grenzen dokumentiert, größtenteils in MLflow und Unity Catalog, zusätzlich in einem strukturierten Versionssteckbrief für Audits.
Diese gestufte Vorgehensweise erscheint im ersten Moment aufwendig. Sie reduziert jedoch den späteren Aufwand bei Vorfällen, Audits oder unerwarteten Qualitätsänderungen erheblich.
Monitoring und Betrieb
Nach der Freigabe müssen technische Stabilität, Inhalte und Datenveränderungen laufend beobachtet werden. Mindestens drei Perspektiven sind relevant. In der Praxis kommen meist fünf zusammen.
Technisches Monitoring
Latenz, Fehlerquote, Tokenverbrauch, Auslastung und Providerfehler überwachen. Schwellenwerte so setzen, dass Latenzspitzen, Throttling oder ungewöhnlich hohe Antwortlängen frühzeitig auffallen.
Inhaltsbezogenes Monitoring
Traces und Antwortstichproben prüfen Retrieval-, Tool- und Antwortqualität. Regelmäßige Stichproben durch Fachbereich und Plattformteam, teils automatisiert bei klar dokumentierten Antwortregeln.
Drift gegenüber Testset-Baseline
Neue Themen, Begriffe und Frageformen zeigen, ob Datenbasis oder Testset erweitert werden müssen. Verteilungen von Eingabefragen und Antwortlängen lassen sich mit Lakehouse Monitoring auf den Inferenztabellen verfolgen.
Regelmäßige Reevaluierung
Das produktive System in festen Intervallen erneut gegen das freigegebene Testset prüfen (z. B. quartalsweise). Veränderte Datenstände oder neue Modellversionen können Qualität beeinflussen, ohne sichtbar angefasst zu werden.
Reaktionsprozess festlegen
Klare Owner, Eskalationswege und Entscheidungskriterien für Warnungen definieren. Wer auf Latenzwarnungen reagiert, wer Drift prüft und wer über Rollbacks entscheidet, muss vor dem produktiven Start geklärt sein.
Wie sich diese Verteilungen technisch verfolgen lassen, zeigt der Überblick zu Lakehouse Monitoring auf den Inferenztabellen.
Einbettung in die Databricks-Plattform
Agent Bricks nutzt dieselben Plattformkomponenten wie individuell entwickelte Agenten. Modellzugriff, Retrieval und Serving werden über die vorhandenen Databricks-Dienste umgesetzt.
Modellzugriff über das Unity AI Gateway. Je nach Produktstand und Konfiguration werden Modellzugriffe über unterstützte Gateway- und Serving-Endpunkte geführt (Unity AI Gateway). Limits, Kosteninformationen und Protokollierung können zentral verwaltet werden, sofern die entsprechenden Funktionen aktiviert sind. Welche Modelle nutzbar sind, hängt von den freigegebenen Endpoints, der Region und dem Produktstand ab. Wie sich das Gateway in eine Multi-Modell-Strategie einfügt, klären wir im Überblick zu Unity AI Gateway auf Databricks.
Retrieval über AI Search. Knowledge-Assistant-Szenarien greifen auf dieselben Such- und Indexkomponenten zurück, die auch ein eigener RAG-Agent nutzen kann. Sie können semantische und lexikalische Suche kombinieren. Wie sich die Retrieval-Schicht für RAG-Workloads aufbauen lässt, zeigen wir im Überblick zu Retrieval-Augmented Generation auf Databricks.
Bereitstellung über Model Serving. Die produktive Bereitstellung erfolgt über die bestehende Serving-Infrastruktur. Ob technisch derselbe Endpoint-Typ und dieselben Funktionen wie bei individuellen Agenten genutzt werden, sollte für den aktuellen Produktstand geprüft werden. Welche Inferenzstrategie für welchen Workload geeignet ist, betrachten wir im Überblick zu Model Serving auf Databricks.
Governance. Daten, Funktionen, Modelle und weitere Objekte können in ein gemeinsames Berechtigungs- und Metadatenmodell eingebunden werden. Berechtigungen, Lineage und Auditinformationen sollten dabei konsistent mit den übrigen Plattformobjekten verwaltet werden.
Ein späterer Wechsel zu einem eigenen Agenten kann bestehende Daten-, Retrieval-, MLflow- und Serving-Komponenten weiterverwenden. Die Modelle und der Retrieval-Stack bleiben in der Regel identisch; geändert wird vor allem die Builder- und Orchestrierungsebene.
Wann passt Agent Bricks besser?
Im Vordergrund steht weniger eine Bewertung „besser oder schlechter" als die Frage nach Time-to-Production und Betriebsaufwand.
Agent Bricks wählen, wenn
- Der Anwendungsfall klar einem unterstützten Template entspricht (Knowledge Assistant, Information Extraction, Multi-Agent Supervisor)
- Eine integrierte, wiederholbare Evaluation zu den zentralen Anforderungen gehört
- Das Team Standardfunktionen wie Eval, Tracing und Endpoint-Bereitstellung nicht selbst entwickeln und betreiben möchte
- Die verfügbaren Modelle im AI Gateway die fachlichen Anforderungen bereits erfüllen
- Daten, Tools und Berechtigungen ohnehin in Databricks verwaltet werden
Custom-Agent wählen, wenn
- Komplexe Zustandslogik, eigene Reasoning-Schritte oder dynamische Orchestrierung mehr Freiheit brauchen
- Mehrstufige, fachlich kontrollierte Argumentation gefordert ist (Compliance-Prüfungen, Forschungs-Recherche, komplexe Diagnostik)
- Nicht unterstützte oder lokal gehostete Modelle eingesetzt werden sollen
- Der Agent überwiegend externe APIs orchestriert und eine schlanke eigene Logik ausreicht
- Eigene Judges, regulatorische Kennzahlen oder verbindliche Goldsets gebraucht werden
Zeitvergleiche sollten als projektspezifische Erfahrungswerte und nicht als allgemeine Zusage behandelt werden.
Wann passt ein Custom-Agent besser?
Mehrere Anforderungen liegen außerhalb eines standardisierten Template-Ansatzes. Die Entscheidungskriterien für beide Wege stehen im Vergleich oben. Ein eigener Agent kann weiterhin MLflow, Model Serving, Gateway und Unity Catalog verwenden. Damit bleibt ein großer Teil der Plattformkomponenten unabhängig vom gewählten Builder nutzbar.
Unity Catalog und Governance
Unity Catalog kann als gemeinsame Governance-Grundlage für Daten, Funktionen und Modelle dienen. Daraus ergeben sich mehrere betriebliche Aspekte.
Versionierung über MLflow
Runs, Modellversionen und Evaluationsergebnisse bleiben über MLflow und die Registry nachvollziehbar. Bei einem Rollback ist ersichtlich, welcher Evaluationsstand dahintersteht und welche Daten in welche Optimierung geflossen sind.
Berechtigungen und Lineage
Zugriff und Datenherkunft werden über Unity Catalog gesteuert und dokumentiert. Welche Tabellen und Vector-Indizes ein Agent liest, kann über Lineage sichtbar werden, abhängig von unterstützter Lineage, Logging und Metadatenpflege.
Tools als Katalog-Objekte
Registrierte SQL- oder Python-Funktionen sowie MCP-Anbindungen werden als Katalog-Objekte mit Berechtigungen und Audit verwaltet. Individuelle Orchestrierungslogik kann außerhalb des Katalogs liegen, muss dann aber separat dokumentiert werden.
Identitätsweitergabe an den Endnutzer
Berechtigungen sollten mit der Identität des aufrufenden Nutzers oder einer klar definierten Service-Identität durchgesetzt werden, explizit für Endpoints, Tools, Indizes und Identitäten getestet, nicht pauschal angenommen.
MCP als Schnittstelle für externe Tools
MCP dient als einheitliche Schnittstelle für externe Tools, sofern die benötigten Funktionen in der eigenen Umgebung unterstützt werden. Zugangsdaten und Audit-Informationen zentral verwalten und regelmäßig überprüfen.
Agent Bricks und individuelle Agenten können in derselben Governance-Struktur betrieben werden. Damit lassen sich Audit- und Reviewprozesse über Anwendungsfälle hinweg konsistent halten.
Was kostet Agent Bricks?
Zu berücksichtigen sind Evaluation, produktive Modellaufrufe sowie Retrieval- und Serving-Compute.
Evaluation
Synthetische Datengenerierung, Antworterzeugung und LLM-basierte Bewertung verursachen Modellaufrufe. Der Verbrauch hängt von Testset, Anzahl der Varianten, Judge-Modell und Antwortlänge ab. Spätere Optimierungs-Iterationen sind meist günstiger als der erste vollständige Aufbau.
Produktive Modellaufrufe
Im produktiven Betrieb fallen die regulären Modell-, Serving- und Gatewaykosten des gewählten Setups an, unabhängig davon, ob der Endpoint über Agent Bricks oder einen eigenen Agenten erzeugt wurde.
Retrieval- und Serving-Compute
Wissensassistenten verursachen zusätzlich Kosten für Index, Synchronisation und Suchendpoints. Diese Kostenstellen entsprechen einem klassischen RAG-Stack.
Der wirtschaftliche Vorteil liegt vor allem in geringerem Entwicklungs- und Betriebsaufwand für Standardfunktionen. Personalkostenschätzungen sollten projektspezifisch und nicht als allgemeine Vergleichsgröße formuliert werden. Für niedrige Evaluationskosten gilt: Testset-Größe konservativ wählen, Optimierungsiterationen begrenzen, kostengünstigere Judge-Modelle prüfen.
Abgrenzung zu Frameworks und Genie
Komplexe Bedingungen, Schleifen, Zustandsmaschinen und individuelle Multi-Agent-Protokolle benötigen weiterhin ein programmierbares Framework. Der Multi-Agent Supervisor eignet sich eher für klar abgegrenztes Routing als für beliebig komplexe Workflow-Orchestrierung. Für umfangreiche Orchestrierungen über mehrere Agenten, Bedingungen, Schleifen und externe Services ist eine eigene Lösung mit dem Agent Framework geeigneter.
Genie und Knowledge Assistant bedienen unterschiedliche Datenarten und Nutzerbedürfnisse. Genie eignet sich für natürlichsprachliche Fragen auf kuratierten strukturierten Daten. Ein Knowledge Assistant beantwortet Fragen auf dokumenten- und wissensbasierten Quellen. Beide Ansätze können sich innerhalb derselben Plattform ergänzen.
Wie Genie und Agent Bricks sich in die breitere Business-Intelligence-Strecke auf Databricks einordnen, behandeln wir im Überblick zu Genie.
Grenzen
Mehrere Einschränkungen sollten vor einer Entscheidung für Agent Bricks berücksichtigt werden.
Begrenzte Individualisierung
Standardisierung beschleunigt passende Use Cases, begrenzt aber individuelle Erweiterungen. Anforderungen außerhalb der vorgesehenen Konfiguration können einen vollständigen Wechsel in einen Custom-Agenten notwendig machen.
Modell-Verfügbarkeit je Region
Die nutzbaren Modelle hängen von unterstützten Endpoints, Region und Produktstand ab. Ob eigene und lokal bereitgestellte Modelle unterstützt werden, sollte aktuell geprüft werden.
Zusätzliche Eval-Kosten
Automatische Optimierung verursacht zusätzliche Modell- und Compute-Kosten. Bei knappem Budget sollten Testset-Größe und Iterationszahl bewusst begrenzt werden.
Preview-Status und Limits
Verfügbarkeit, Preview-Status und Limits können sich je Template, Cloud und Region unterscheiden. Reifegradangaben sollten unmittelbar vor der Projektentscheidung anhand offizieller Quellen verifiziert werden (siehe Quellen).
Diese Einschränkungen helfen dabei, den passenden Builder und Betriebsweg zu wählen.
Fazit
Agent Bricks lohnt sich, wenn standardisierte Agenten produktiv sollen und Evaluation der Engpass ist. Ein Custom-Agent bleibt die Wahl für individuelle Orchestrierung und Spezialanforderungen.
Individuelle Orchestrierung, spezielle Modelle und besondere Evaluationsanforderungen sprechen weiterhin für einen eigenen Agenten. Beide Ansätze können MLflow, Model Serving, Unity AI Gateway, Vector Search und Unity Catalog gemeinsam nutzen. Eine Plattform kann Agent Bricks für Standardfälle und Custom-Agenten für Spezialfälle parallel unterstützen.
Ein Wissensassistent auf internen Dokumenten kann als erster Referenzfall mit dem Knowledge Assistant umgesetzt und bewertet werden. Ein Eigenbau sollte dort eingesetzt werden, wo er einen klaren funktionalen oder regulatorischen Mehrwert bietet. Zwei parallele Implementierungen desselben Anwendungsfalls erhöhen Test-, Betriebs- und Governanceaufwand und sollten nur mit einem klaren Migrations- oder Vergleichsziel betrieben werden.
Agent Bricks ist nicht als Ersatz für frei programmierbare Agentenframeworks gedacht. Entscheidend ist, ob der standardisierte Ansatz beim konkreten Anwendungsfall nachweisbar Entwicklungszeit spart, ohne Qualität, Kontrolle und Erweiterbarkeit unangemessen einzuschränken.
Startet mit einem Wissensassistenten auf internen Dokumenten als Referenzfall für den Knowledge Assistant, bevor ihr größere Custom-Agent-Investitionen prüft.
FAQ
Agent Bricks ist die kuratierte Agenten-Builder-Oberfläche in Mosaic AI mit vier Templates (Knowledge Assistant, Information Extraction, Multi-Agent Supervisor, Custom LLM). Du beschreibst den Use Case, gibst Datenbasis und Beispiele mit, und die Plattform generiert ein synthetisches Eval-Set, optimiert Prompts und Modell-Auswahl gegen das Set, versioniert über MLflow und deployt als REST-Endpoint über Model Serving.
