ML Engineering Agents auf Databricks: Aufgaben, Grenzen und MLOps
Welche Aufgaben ML Engineering Agents auf Databricks in Build, Deploy und Monitoring übernehmen, und wo Ownership, Governance und MLflow wichtig bleiben.
Die Kernaussagen auf einen Blick.
- ML Engineering Agents auf Databricks unterstützen wiederkehrende Aufgaben im ML-Lifecycle. Sie können Trainingsvorlagen, Registry-Schritte, Serving-Endpunkte und Monitoring-Konfigurationen in einem Format erzeugen, das in Asset Bundles übernommen werden kann.
- Ihr Nutzen hängt vor allem an zwei Punkten: Sie kennen die zentralen Databricks-Bausteine für Training, Deployment und Monitoring. Und sie erzeugen Artefakte, die in den bestehenden Deployment-Prozess passen.
- Vor dem Einsatz müssen drei Dinge geklärt werden: wo der Code landet, in welcher Registry-Stufe der Agent arbeiten darf und wer die Ergebnisse prüft.
- Mein Vorschlag: Den Agenten zunächst an einem klar abgegrenzten Lifecycle-Prozess einsetzen, der schon Asset-Bundle-Disziplin hat. Qualitätsbewertung, Freigabe und Produktionswechsel bleiben beim verantwortlichen Team.
Inhaltsverzeichnis
Gleiche Plattform, jedes Projekt ein Unikat
Ein typischer Steering-Termin im ML-Team. Das Team betreibt bereits mehrere produktive Modelle, drei davon im letzten Quartal neu in Produktion. Jedes Modell hat ein eigenes Repo, einen eigenen Trainings-Job, einen eigenen Serving-Endpoint, einen eigenen Monitor. Die Plattform ist einheitlich, aber jedes Modellprojekt ist anders aufgebaut.
In wachsenden ML-Plattformen entsteht diese Uneinheitlichkeit meist schrittweise. Sobald mehrere Modelle parallel in Produktion gehen, kennt jeder im Team das Bild: MLflow wird in jedem Projekt etwas anders verwendet. Die Freigabe eines Modells läuft je nach Projekt über UI, Skript oder Asset Bundle. Ein Serving-Endpunkt enthält noch Tags oder Einstellungen aus älteren Versionen. Monitoring wurde einmal eingerichtet, aber später nicht mehr gepflegt.
Die Fragen, die im Steering auf den Tisch kommen:
Wie viel Zeit geht für wiederkehrende Standardarbeit verloren? Welche Schritte kann ein Agent vorbereiten, ohne Kontrolle und Verantwortung zu verlieren? Wer ist verantwortlich für einen Endpunkt, den ein Agent vorgeschlagen oder erzeugt hat? Welche Ergebnisse müssen versioniert in Asset Bundles übernommen werden?
Die These dieses Artikels: Ein ML-Engineering-Agent auf Databricks schafft nur Wert, wenn er die zentralen ML-Bausteine der Plattform kennt und seine Artefakte in genau dem Format ausliefert, das die Plattform produktiv konsumiert.
Was sind ML Engineering Agents auf Databricks?
Ein ML-Engineering-Agent auf Databricks ist ein Agent, der Code, Konfigurationen und Infrastrukturdefinitionen entlang des ML-Lifecycles erstellt, und zwar so, dass sie in den bestehenden Databricks-Betrieb übernommen werden können. Im Mosaic-AI-Ökosystem zählen dazu vorbereitete Trainingsskripte, MLflow-Tracking-Code, Logik für die Freigabe und Versionierung von Modellen, Konfigurationen für produktive Modellendpunkte, Monitoring-Konfigurationen und passende Einträge für Asset Bundles. Die technischen Anknüpfungspunkte sind dieselben, die auch das Databricks Agent Framework für GenAI-Agenten nutzt (Mosaic AI Model Serving, MLflow Registry, Unity Catalog), aber mit klassischen ML-Modellen, Trainingsprozessen und Evaluationen als Ziel anstelle von RAG-Systemen. Databricks selbst hat „Agents for ML Engineering" im Juni 2026 als Bestandteil der AI-Plattform angekündigt, zusammen mit einer auf ML-Lifecycle erweiterten Variante von Genie Code.
Der Agent hilft vor allem dort, wo im Lifecycle wiederkehrende manuelle Arbeit entsteht. Er sollte Ergebnisse liefern, die direkt in den richtigen Code- und Review-Prozess passen. Er übernimmt den wiederkehrenden Grundaufbau: zum Beispiel eine weitere Trainingspipeline nach bekanntem Muster, oder einen weiteren Serving-Endpunkt mit ähnlicher Struktur, das Monitor-Setup, das in jedem Repo neu geschrieben wird. Was er nicht entscheiden sollte: Modellqualität, Bewertungsmaßstäbe, Produktionsfreigabe und Verantwortung im laufenden Betrieb. Diese Schritte müssen weiterhin von verantwortlichen Personen geprüft und freigegeben werden.
Wie wir den ML-Lifecycle auf Databricks technisch aufstellen (von Training über Serving bis zur Eval-Pipeline) beschreiben wir ausführlich in Managed MLflow auf Databricks. Den größeren Plattform-Rahmen liefert die Data Intelligence Platform, den vollständigen Überblick über alle AI-Bausteine der AI-Stack auf Databricks.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Was ein ML-Engineering-Agent nicht ist
Drei Werkzeuge werden häufig mit ML Engineering Agents verwechselt. Die Unterscheidung ist wichtig für die Architekturentscheidung. Sie entscheidet, wo der Agent in Entwicklung, Deployment und Betrieb sinnvoll eingesetzt wird.
Genie Code ist ein Assistent für längere Daten- und ML-Aufgaben direkt im Databricks Workspace, im März 2026 vorgestellt und mittlerweile auch stärker auf ML-Engineering-Aufgaben ausgerichtet. Genie Code arbeitet vor allem direkt im Databricks Workspace, kennt Tabellen, Notebooks und bestehende Workflows im Workspace und kann mehrstufige Aufgaben vorbereiten und teilweise ausführen. Ein weiteres Einsatzfeld ist die Fehlersuche im Betrieb: Genie Code kann Inference Tables prüfen, Performance-Probleme bei Serving-Endpunkten analysieren und mögliche Ursachen für Alerts eingrenzen. Databricks führt diesen Modus als „Genie ZeroOps for ML". Ein ML Engineering Agent im Repository arbeitet dagegen näher an versioniertem Code, Asset Bundles und CI/CD. Beide Ansätze können sinnvoll nebeneinander bestehen; die Frage ist, welcher Modus zu welcher Aufgabe passt.
Asset Bundles bleiben die Grundlage für produktive Databricks-Deployments. Sie beschreiben Jobs, Modelle, Endpunkte, Monitore und Berechtigungen versioniert in YAML. Der Agent kann solche Einträge vorbereiten, sollte sie aber nicht ohne Review in Produktion bringen. Agenten-Ergebnisse direkt in den Workspace zu übernehmen, umgeht den notwendigen CI/CD- und Code-Review.
Coding Agents wie Claude Code, Cursor oder GitHub Copilot sind allgemeine Assistenten für Softwareentwicklung. Sie kennen den Databricks-ML-Lifecycle nicht automatisch. Sie können Trainingscode erzeugen, aber nicht wissen, welche Registry-Stufen, Freigaberegeln und Bundle-Vorlagen in eurem Projekt verbindlich sind oder wie eure Asset-Bundle-Vorlagen aufgebaut sind. Wo wir den allgemeinen Frame für Coding Agents in produktiven Engineering-Strecken behandeln, zeigen wir in Coding Agents als Engineering-Disziplin.
| Aspekt | ML Engineering Agents | Genie Code | Asset Bundles | Coding Agents |
|---|---|---|---|---|
| Scope | ML-Lifecycle auf Databricks | Workspace-Workflows (Data + ML) | Deployment-Spezifikation | allgemeine Entwicklungsaufgaben |
| Nähe zum ML-Lifecycle | direkt: MLflow, Serving, Monitoring | Workspace-Kontext, teilweise ML-spezifisch | indirekt: beschreibt das Deployment | keine |
| Output-Format | Code, YAML, Registry-Aufrufe, Monitoring-Konfigurationen | Notebook-Code und Workflow-Definitionen | YAML-Bundles | Code-Diffs |
| Ownership-Modell | Reviewer-PR-Modell | Workspace-User | Plattformteam | Entwickler-User |
| Typischer Einsatz | Modell-Onboarding und Lifecycle-Automation | Ad-hoc-Analyse, Workflow-Aufbau und Endpoint-Diagnose | produktive Bereitstellung | Entwicklung in der IDE und Code-Überarbeitung |
Wo hilft der Agent im ML-Lifecycle?
Die entscheidende Frage ist nicht, ob ein Agent helfen kann. Entscheidend ist, an welcher Stelle er welches Artefakt vorbereitet und wer dieses Artefakt prüft. Im ML-Betrieb auf Databricks zieht sich derselbe Ablauf durch acht typische Schritte: Der Agent legt vor, das Ergebnis läuft als Pull Request durch Review, der MLE gibt frei, das Asset Bundle deployt. An drei Stellen reicht das normale PR-Review nicht und es braucht ein explizites Gate.
Alle acht Stationen durchlaufen denselben Review-Pfad: Agent bereitet vor, Pull Request und Review folgen, das MLE gibt frei, das Asset Bundle deployt. Die drei Gates sitzen vor der Compute-Auswahl (Budget-Gate), vor der Registry-Promotion (Promotion-Gate) und vor dem Serving-Rollout (SLA-Gate). Die Tabelle darunter zeigt je Schritt, was der Agent beiträgt, was beim MLE bleibt und in welchem Format das Artefakt landet.
| Lifecycle-Schritt | Agent-Anteil | MLE-Verantwortung | Artefakt-Format |
|---|---|---|---|
| Features aus dem Feature Store lesen | Erzeugung passender Feature-Store-Abfragen, Verknüpfung der Features mit dem Trainingsdatensatz, deklarative Feature-Specs | Feature-Auswahl, Versionierung und Nachvollziehbarkeit bleiben Aufgabe des Teams. | Python-Modul + Bundle-Eintrag mit Feature-Spec |
| Compute-Auswahl (CPU/GPU/AI Runtime) | Vorschlag für CPU- oder GPU-Konfiguration über AI Runtime, inkl. distributed-Training-Setup | Entscheidung über Kapazität, Budget und wirtschaftliche Sinnhaftigkeit einer GPU-Nutzung | Notebook-Konfig + Bundle-Compute-Block |
| Training-Skript | Skript-Grundstruktur mit MLflow-Tracking, Hyperparameter-Sweep, Tags für MLflow-Runs | Modellarchitektur, Loss-Funktion und Trainingsstrategie | Python-Skript + Asset-Bundle-Job-Definition |
| MLflow-Logging | Logging-Calls für Metriken, Artefakte, Signaturen, Input-Examples | Welche Metriken relevant sind und welche Schwellenwerte gelten | MLflow-API-Calls im Trainings-Skript |
| Promotion in der Model Registry | , Setzen von Aliasen und Wechseln zwischen Registry-Stufen | Freigabe, Qualitätsprüfung und Entscheidung zur Promotion | Python-Skript + Workflow-Step |
| Model Serving Endpoint | Endpoint-Konfiguration (Compute-Größe, Scale-to-Zero, Routing für hohe Anfragevolumen, Inference-Tables) | Capacity-Planung, Antwortzeit-SLA und Kostenzuordnung | YAML-Bundle-Eintrag für |
| Monitor-Definition | -Konfiguration, Baseline-Tabelle, Metrik-Set, Inference-Tables-Anbindung | Welche Drift-Metriken fachlich relevant sind, Schwellenwert für Alerts | YAML-Bundle-Eintrag für + Python-Setup |
| Kosten-Tags und Audit-Informationen | Tag-Konsistenz über Bundle, Endpoint und Monitor | Zuordnung zu Kostenstelle und Verantwortlichem | Bundle--Block, Owner-Eintrag in Unity Catalog |
Das Muster wiederholt sich über alle acht Schritte: Der Agent bereitet technische Artefakte vor. Das Team entscheidet über Qualität, Risiko und Freigabe. Ein automatisch erzeugter Endpunkt ohne Kosten-Tag und Owner wird schnell zu unkontrollierter Infrastruktur. Später entstehen Kosten, die niemand eindeutig zuordnen, optimieren oder zurückbauen kann.
Zwei Stellen verdienen besondere Aufmerksamkeit. Bei der Compute-Auswahl sollte der Agent nicht über Budget oder GPU-Bedarf entscheiden. Diese Entscheidung hängt von Anwendungsfall, Budget, erwarteter Laufzeit und Nutzen ab. Was er liefern kann: passende technische Konfiguration für serverless GPU-Trainings über AI Runtime, inklusive Multinode-Setup, RDMA-Bündelung und Distribution-Logik. Für Deep-Learning-Workloads ohne eigene Cluster-Verwaltung entsteht damit ein weiteres Einsatzfeld für Agenten, neben dem klassischen ML-Training auf CPU. Beim Serving kann der Agent neben dem Endpunkt auch die Anbindung an Inference Tables vorbereiten, die wiederum der Monitor konsumiert. Diese Verbindung ist wichtig, damit Monitoring auf den tatsächlich im Betrieb verwendeten Daten arbeitet.
Wie der konkrete Schnitt zwischen Trainings-Job, Registry-Promotion und Workflow aussieht, erklären wir in Mosaic AI Training und in Mosaic AI Model Registry.
Wo die Verantwortung beim Team bleibt
Der Agent kann wiederkehrende Aufgaben im ML-Lifecycle vorbereiten. Er sollte aber nicht über Modellqualität, Freigabe oder produktives Verhalten entscheiden. Diese Trennung ist die Grundlage für ein belastbares Betriebsmodell. Wenn diese Grenze verwischt wird, entstehen unkontrollierte Artefakte oder Reviewer müssen jeden einzelnen Schritt kontrollieren, dadurch geht der Produktivitätsgewinn wieder verloren.
Delegierbar ist der wiederkehrende technische Grundaufbau. Ein weiteres Training-Skript nach bekanntem Muster, ein weiterer Serving-Endpunkt mit ähnlicher Konfiguration, wiederkehrende Monitoring-Konfiguration. Hier ist der Nutzen hoch und das Risiko vergleichsweise niedrig, solange das Ergebnis denselben Standards folgt wie manuell erstellter Code.
Delegierbar sind technische Standardkonfigurationen. YAML-Einträge für Asset Bundles, Vorschläge für Endpoint-Größen nach bekannten Regeln, Monitor-Definitionen mit Standardmetriken. Der Agent kann hier konsistente Standardwerte vorschlagen, die nach Repo-Konvention konfiguriert sind.
Modellqualität
Welche Modellarchitektur passt, welche Trainingsdaten geeignet sind und welche Fehler fachlich kritisch sind, bleibt Aufgabe von ML Engineers, Data Scientists und fachlichen Verantwortlichen, weil dafür Domänenwissen nötig ist.
Evaluation
Welche Metriken zählen, ab welchem Schwellenwert ein Modell produktionsreif ist und ob es gegen die Baseline gewinnt: Diese Definition gehört zu den Personen, die die geschäftlichen Folgen der Vorhersage verstehen.
Produktionsfreigabe
Die Promotion in den Production-Alias bedeutet, Verantwortung für die Vorhersagen im Produktivbetrieb zu übernehmen. Diesen Schritt sollte kein Agent eigenständig oder indirekt übernehmen.
Produktionswechsel
Wann ein altes Modell ersetzt, ein neues aktiviert oder ein Rollback ausgelöst wird, ist eine Betriebsentscheidung mit Auswirkungen auf nachgelagerte Systeme.
Ohne diese Trennung im Operating Model wiederholt sich das gleiche Muster wie bei früheren MLOps-Modernisierungen: ein technisch sauberer Prozess, der Verantwortung verschiebt, ohne sie sauber zuzuordnen.
Reviews, Asset Bundles und klare Registry-Stufen
Wenn der Agent regelmäßig im ML-Lifecycle eingesetzt wird, dann darf er nicht als Nebenweg am Engineering-Prozess vorbeilaufen. Seine Ergebnisse müssen denselben Code-, Review- und Deployment-Prozess durchlaufen wie manuell erstellte Änderungen. Sonst entsteht ein zweiter Qualitätsstandard für Agenten-Artefakte.
PR-Pflicht
Jede Änderung an Training, Monitoring oder Endpoint läuft als Pull Request ins Asset-Bundle-Repository, nie direkt im Workspace. Reviewer sehen Codeänderung, Bundle-Konfiguration und Auswirkungen vor dem Rollout.
Verbindliche Asset Bundles
Jobs, Modelle, Endpunkte und Monitore werden als Bundle-Artefakte versioniert. Ohne Bundle-Eintrag entsteht Drift zwischen Repository und Workspace.
Getrennte Registry-Stufen
Der Agent erzeugt Entwürfe und Staging-Versionen. Produktionsversionen laufen ausschließlich über einen geprüften Freigabeprozess.
Service-Principal-Identität
Der Agent arbeitet mit einer technischen Identität statt einem persönlichen Token. Sonst hängen produktive Artefakte an einer Person und werden bei Rollenwechsel schwer nachvollziehbar.
Reviewer nach Änderungsart
Trainingscode geht an Data Scientists und ML Engineers, Serving-Infrastruktur ans Plattformteam, Monitoring-Regeln an die Modellverantwortlichen.
Die operative Folge: Der Lifecycle wird reproduzierbar, weil Agenten-Ergebnisse und manuelle Änderungen denselben Prozess nutzen. Das ist die Voraussetzung, damit Geschwindigkeitsgewinn nicht zulasten von Auditierbarkeit geht.
Berechtigungen, Secrets, Audit und Kosten
ML Engineering Agents erweitern die Automatisierung im Databricks-ML-Lifecycle. Für Governance, Verantwortung und Kostenkontrolle reicht der Agent allein aber nicht aus.
Unity-Catalog-Pfade
Jeder Datenzugriff, jede Feature-Store-Abfrage, jede Registry-Operation läuft über UC. Sonderrechte oder Umgehungspfade kosten Berechtigungen, Lineage und Audit gleichzeitig.
Secrets nur in Secret Scopes
Der Agent liest Secrets über die Workspace-API, niemals als Klartext im generierten Code. Inline-Tokens erzeugen ein Sicherheitsrisiko, das später aufwendig bereinigt werden muss.
Lückenloser Audit-Pfad
Jede Agenten-Aktion muss einer technischen Identität zuordenbar bleiben. Persönliche Tokens machen die Nachvollziehbarkeit unsauber, sobald die Person das Team verlässt.
Kosten-Tags und Owner
Jeder Endpunkt und jedes Monitoring-Artefakt braucht Kostenstelle, Owner und Zweck. Sonst tauchen Kosten im FinOps-Report ohne klare Verantwortlichkeit auf.
Evaluation bleibt Teamsache
Der Agent kann eine Eval-Pipeline vorbereiten, entscheidet aber nicht, ab wann ein Modell produktionsreif ist. Würde er das selbst festlegen, setzte er faktisch seine eigenen Qualitätsmaßstäbe.
Genie Code ersetzt keinen Lifecycle-Agenten
Ein Workspace-Assistent für spontane Aufgaben ist nicht dasselbe wie ein Agent, der versionierte Lifecycle-Artefakte für Asset Bundles erzeugt. Beide haben ihren Platz, aber ersetzen sich nicht.
Trotz dieser Grenzen ist der Wert eines Lifecycle-eingebetteten Agents hoch, solange er gegen ein bestehendes Operating Model mit Bundle-Disziplin, Stage-Trennung und Reviewer-Pflicht arbeitet. Fehlt dieses Fundament, verstärkt der Agent bestehende Schwächen.
Fazit
ML Engineering Agents sind vor allem dann sinnvoll, wenn die ML-Plattform bereits produktiv im Einsatz ist und wiederkehrende Standardarbeit spürbar Zeit bindet.
Sie werden besonders relevant, wenn mehrere Modelle gleichzeitig produktiv betrieben werden und Training-, Registry-, Serving- und Monitoring-Code in jedem Repository neu aufgebaut wird, obwohl der Ablauf fachlich ähnlich ist.
Besonders sinnvoll ist das für Teams, die MLflow, Model Serving, Feature Store und Asset Bundles bereits im produktiven Betrieb verwenden, die Übergänge zwischen Training, Registry, Serving und Monitoring noch manuell organisieren. Typische Kandidaten:
- mehrere Modelle mit ähnlichem Lifecycle, aber unterschiedlich aufgebauten Repositories
- Endpoints und Monitore, die im Workspace vorhanden sind, aber nicht versioniert im Asset Bundle liegen
- Modellfreigaben, die je nach Projekt anders ablaufen
- Kostenberichte mit Endpoints, die keiner klaren Verantwortung zugeordnet sind
- ML-Teams, die 30–40 % ihrer Zeit mit Lifecycle-Boilerplate verbringen
Wer Asset Bundles noch nicht verbindlich nutzt, keine klaren Registry-Stufen und keinen Review-Prozess hat, sollte zuerst diese Grundlagen schaffen. Dann ist nicht der Agent der nächste Engpass, sondern das fehlende Betriebsmodell.
Mein Vorschlag: Den Agenten zunächst in einem einzigen klar abgegrenzten Lifecycle-Prozess einsetzen, der schon Bundle-Disziplin hat. Ein guter Startpunkt ist die Generierung von Trainingsjobs auf Basis eines bestehenden Asset-Bundle-Templates. Daran wird schneller sichtbar, ob Review, Bundle-Disziplin und Ownership funktionieren, als bei einer plattformweiten Einführung.
Der eigentliche Nutzen entsteht nicht durch einzelne Codevorschläge im Notebook. Er entsteht durch die saubere Integration in Registry, Asset Bundles und Review-Prozess.
<!-- CTA rendert automatisch zwischen Fazit und FAQ aus Frontmatter cta: (articleCta-Block), kein eigener Body-Content mehr nötig. -->
Den Agenten zunächst in einem einzigen klar abgegrenzten Lifecycle-Prozess einsetzen, der schon Bundle-Disziplin hat. Ein guter Startpunkt ist die Generierung von Trainingsjobs auf Basis eines bestehenden Asset-Bundle-Templates.
FAQ
Lifecycle-eingebettete Agenten, die Code, Konfiguration und Bundle-Einträge entlang des Databricks-ML-Stacks erzeugen: Trainings-Skripte, MLflow-Tracking, Registry-Promotion, Serving-Endpoints, Monitor-Definitionen. Im Unterschied zu allgemeinen Coding-Helfern haben sie direkte Bindung an MLflow, Mosaic AI, Asset Bundles und Lakehouse Monitoring. Ihr Wert hängt am Output-Format: Was nicht als Bundle-Eintrag landet, ist Schatten-Infrastruktur.
