Geschäftskontext: Der Plattformkampf hat sich verlagert

Jeder bedeutende Plattformkrieg – Cloud-Compute, Data Warehousing, BI-Tooling – drehte sich am Ende um Kontrollpunkte. Nicht um Funktionen. Wer kontrollierte, wo Entwickler bauen, wo Daten landen oder wo Dashboards betrieben wurden, hat das Ökosystem vereinnahmt.

Dieselbe Logik gilt jetzt für KI-Agenten. Agenten müssen sich authentifizieren, Tools aufrufen, Daten interpretieren und beobachtbar sein. Wer diese Runtime-Schicht kontrolliert – die Verbindungsschicht zwischen Modell und Unternehmen – prägt die Plattformökonomie des nächsten Jahrzehnts. Databricks weiß das. Microsoft weiß das. Das Rennen läuft.

Das Problem: Agenten ohne verlässliche Runtime

So sieht es aus, wenn Sie heute Agenten bauen. Sie wählen ein Modell. Sie wählen ein Framework – LangChain, CrewAI, Autogen oder etwas Eigenes. Sie konfigurieren den Tool-Zugriff über API-Keys in Umgebungsvariablen. Sie hartcodieren Berechtigungen. Sie stellen das Ganze irgendwo bereit – vielleicht in einem Container, vielleicht in einem Notebook, vielleicht in einer Lambda-Funktion.

In der Demo läuft es. Dann kommt die Produktion.

Der Agent soll eine Salesforce-API aufrufen, aber das OAuth-Token ist abgelaufen. Er soll eine Snowflake-Tabelle abfragen, aber der Service-Account hat weitergehende Berechtigungen, als er sollte. Er schreibt in ein CRM-Feld, doch es gibt keinen Audit-Trail, der zeigt, warum. Wenn der Agent einen Tool-Aufruf halluziniert, kann niemand die Entscheidungskette nachvollziehen.

Das ist kein Edge Case. Das ist heute der Normalzustand des Agenten-Deployments in den meisten Unternehmen. Das Modell läuft sauber. Die Runtime drumherum ist zusammengeflickt.

Das Model Context Protocol (MCP) ist entstanden, um zu standardisieren, wie Agenten Tools entdecken und nutzen – als gemeinsame Schnittstelle zwischen Modellen und den Systemen, mit denen sie interagieren. Aber MCP allein löst weder Authentifizierung noch Governance noch Observability. Es standardisiert die Form der Verbindung. Im Plattformkrieg geht es darum, wer diese Verbindung mit Authentifizierung, Governance und Observability füllt.

Die Lösung: Vier Kontrollpunkte, die die Agenten-Runtime definieren

Der Krieg um die Agenten-Runtime entscheidet sich an vier Kontrollpunkten. Wer alle vier beherrscht, gewinnt.

%%{init: {'theme': 'dark', 'themeVariables': {'primaryColor': '#1a2540', 'primaryTextColor': '#ffffff', 'primaryBorderColor': '#00d4ff', 'lineColor': '#ffffff', 'secondaryColor': '#1a2540', 'tertiaryColor': '#1a2540', 'edgeLabelBackground': '#0a0f1e', 'clusterBkg': '#0a0f1e', 'clusterBorder': '#ffffff', 'fontFamily': 'arial', 'fontSize': '14px'}}}%%
graph TD
    A["Agenten-Anfrage"] --> B["1. Identität & Berechtigungen
Wer ist dieser Agent? Worauf darf er zugreifen?"]
    B --> C["2. Semantische Bedeutung
Versteht der Agent die Daten, die er anfasst?"]
    C --> D["3. Evaluation & Tracing
Können wir jede Entscheidung und jeden Tool-Aufruf beobachten?"]
    D --> E["4. Verlässliche Ausführung
Läuft er in großem Maßstab zuverlässig?"]
    E --> F["Enterprise-tauglicher Agent"]

    style A fill:#1a2540,stroke:#ffb347,color:#ffffff
    style B fill:#1a2540,stroke:#00d4ff,color:#ffffff
    style C fill:#1a2540,stroke:#00d4ff,color:#ffffff
    style D fill:#1a2540,stroke:#00d4ff,color:#ffffff
    style E fill:#1a2540,stroke:#00d4ff,color:#ffffff
    style F fill:#1a2540,stroke:#00ff88,color:#ffffff

1. Identität und Berechtigungen. Der Agent muss sich als verwaltete, governance-konforme Identität authentifizieren – nicht als gemeinsam genutzter Service-Account und nicht über einen fest codierten API-Key. Databricks hat im März-2026-Release Managed OAuth für MCP-Server umgesetzt. Damit übernehmen Agenten, die auf durch Unity Catalog verwaltete Tools zugreifen, dieselben Zugriffskontrollen wie menschliche Nutzer. Das ist ein bedeutender Schritt. Die Berechtigungen des Agenten sind auditierbar, widerrufbar und an Governance-Richtlinien gebunden, die ohnehin existieren. Kein separates Berechtigungs-Silo für Agenten.

2. Semantische Bedeutung. Ein Agent, der ein Tool aufrufen kann, ist nicht dasselbe wie ein Agent, der versteht, was die Daten bedeuten. Genau hier wird der Semantic Layer zur kritischen Infrastruktur. Wenn ein Agent nach „Umsatz“ fragt, muss er wissen, ob ARR, MRR oder realisierter Umsatz gemeint ist – und er muss die richtige Definition bekommen, ohne dass jedes Mal ein Mensch nachjustiert. Plattformen, denen der Semantic Layer gehört (Metadaten in Unity Catalog, das semantische Modell von Snowflake Cortex), haben hier einen strukturellen Vorteil.

3. Evaluation und Tracing. Wenn ein Agent eine schlechte Entscheidung trifft – und das wird er – brauchen Sie einen vollständigen Trace. Welches Tool hat er aufgerufen? Welche Daten hat er erhalten? Welche Reasoning-Kette hat den Output erzeugt? Das ist Observability für Agenten, und sie ist schwerer als Observability für Anwendungen, weil die Entscheidungslogik probabilistisch ist. Databricks MLflow Tracing und das Agenten-Monitoring von Microsoft Fabric investieren beide hier, aber keine der beiden Plattformen hat es vollständig gelöst. Ich glaube nicht, dass das überhaupt jemand hat.

4. Verlässliche Ausführung. Der Agent muss konsistent im Enterprise-Maßstab laufen. Retries, Timeouts, Rate Limits, Graceful Degradation. Klingt langweilig. Genau hier sterben die meisten Agenten-Projekte. Ein Demo-Agent darf abstürzen und neu starten. Ein Agent in Produktion, der pro Stunde Tausende Kundeninteraktionen verarbeitet, darf das nicht.

Umsetzung: Wie sich die Plattformen positionieren

Die Manöver laufen bereits. So lese ich die Wettbewerbslage.

%%{init: {'theme': 'dark', 'themeVariables': {'primaryColor': '#1a2540', 'primaryTextColor': '#ffffff', 'primaryBorderColor': '#00d4ff', 'lineColor': '#ffffff', 'secondaryColor': '#1a2540', 'tertiaryColor': '#1a2540', 'edgeLabelBackground': '#0a0f1e', 'clusterBkg': '#0a0f1e', 'clusterBorder': '#ffffff', 'fontFamily': 'arial', 'fontSize': '14px'}}}%%
graph LR
    subgraph DB["Databricks"]
        D1["Unity Catalog
Identität + Semantik"]
        D2["MCP OAuth
Tool-Auth"]
        D3["MLflow Tracing
Observability"]
        D4["Mosaic AI
Ausführung"]
    end

    subgraph MS["Microsoft Fabric"]
        M1["OneLake
Vereinheitlichte Daten"]
        M2["Data Agents
Tool-Integration"]
        M3["Copilot Studio
Orchestrierung"]
        M4["Purview
Governance"]
    end

    D1 --- D2 --- D3 --- D4
    M1 --- M2 --- M3 --- M4

    style D1 fill:#1a2540,stroke:#00d4ff,color:#ffffff
    style D2 fill:#1a2540,stroke:#00d4ff,color:#ffffff
    style D3 fill:#1a2540,stroke:#00d4ff,color:#ffffff
    style D4 fill:#1a2540,stroke:#00d4ff,color:#ffffff
    style M1 fill:#1a2540,stroke:#ffb347,color:#ffffff
    style M2 fill:#1a2540,stroke:#ffb347,color:#ffffff
    style M3 fill:#1a2540,stroke:#ffb347,color:#ffffff
    style M4 fill:#1a2540,stroke:#ffb347,color:#ffffff
    style DB fill:#0a0f1e,stroke:#00d4ff,color:#ffffff
    style MS fill:#0a0f1e,stroke:#ffb347,color:#ffffff

Databricks setzt auf offene Standards. MCP für die Tool-Integration. OAuth für Identität. Unity Catalog als Governance-Rückgrat. Das Kalkül: Wenn die Agenten-Runtime auf offenen Protokollen aufsetzt, wählen Kunden Databricks, weil die Governance- und Semantik-Schichten dort schon stehen. Das März-2026-Release mit Managed OAuth für MCP-Server ist ein leiser, aber strategischer Zug – es macht Databricks zur ersten Plattform, auf der die Agenten-zu-Tool-Authentifizierung ein verwalteter Service ist statt einer DIY-Integration.

Microsoft Fabric spielt die Integrationskarte. Data Agents in Fabric verbinden sich direkt mit OneLake-Daten, nutzen Copilot Studio für die Orchestrierung und docken an das Microsoft-365-Ökosystem an, in dem die meisten Unternehmen ohnehin arbeiten. Das Kalkül: Agenten müssen dort laufen, wo Nutzer und Daten bereits sind, und niemand hat eine größere installierte Basis als Microsoft. Der Trade-off ist die engere Kopplung – Ihre Agenten werden tief Fabric-nativ, was mächtig ist, bis Sie sie außerhalb dieses Ökosystems betreiben müssen.

OpenClaw setzt auf MCP-konforme Grenzen, damit Agenten zwischen Plattformen portabel bleiben, in denen Identität und Governance verankert sind. Diese Frage der Portabilität – kann Ihr Agent zwischen Runtimes wechseln, ohne neu gebaut zu werden? – wird tragfähige Architekturen vom Vendor-Lock-in trennen.

Beispiel: Die Spurweiten-Kriege der Eisenbahn

Es ist nicht das erste Mal, dass eine Branche um Runtime-Standards streitet. Im 19. Jahrhundert fuhren amerikanische Eisenbahnen auf unterschiedlichen Spurweiten. Die Erie Railroad nutzte 6-Fuß-Spur. Im Süden waren 5 Fuß Standard. Die „Normalspur“ mit 4 Fuß 8,5 Zoll dominierte im Nordosten.

Die Folgen waren brutal. Fracht musste an jeder Spurweitengrenze physisch entladen und neu verladen werden. Ganze Städte – Chattanooga, Cairo in Illinois – existierten zum Teil deshalb, weil sie Umschlagpunkte waren, an denen die Spurweite wechselte. Die Ineffizienz war gewaltig, doch jede Bahngesellschaft wehrte sich gegen Standardisierung, weil ihre Spurweite einen strategischen Lock-in schuf.

Die Parallele zu Agenten-Plattformen ist präzise, nicht dekorativ. Heute lässt sich ein Agent, der auf der Databricks-Runtime gebaut ist, nicht ohne Weiteres nach Fabric migrieren – und umgekehrt. Tool-Integrationen, Authentifizierungs-Flows, Observability-Hooks – sie unterscheiden sich alle. MCP versucht, zur Normalspur für die KI-Tool-Integration zu werden. Aber eine Standardschnittstelle allein hat auch bei der Eisenbahn nicht gereicht. Der eigentliche Sieger war das Ökosystem, das Normalspur mit der besten Frachtlogistik, Disposition und Terminal-Infrastruktur kombinierte.

Genau dieses Rennen tragen Databricks und Microsoft aus. Die Normalspur zählt. Was Sie darauf bauen, zählt mehr.

Strategischer Takeaway

Die Modell-Schicht wird zur Commodity. GPT-4o, Claude, Gemini – sie konvergieren in der Leistungsfähigkeit. Die Differenzierung wandert im Stack nach unten – zur Agenten-Runtime: Wer authentifiziert den Agenten, wer steuert seinen Tool-Zugriff, wer verfolgt seine Entscheidungen, wer sichert die verlässliche Ausführung.

Wenn Sie heute strategische Plattformentscheidungen treffen, hören Sie auf, Modell-Benchmarks zu vergleichen. Bewerten Sie stattdessen Runtime-Kontrollpunkte. Die Plattform, die die Agenten-Runtime kontrolliert, wird die Spielregeln für AI-native Unternehmen bestimmen – so wie AWS die Cloud-native Entwicklung beherrschte, indem es Compute, Storage und Identität kontrollierte und nicht, indem es die beste Anwendung baute.

Quellen

Daniel Piatkowski — Data & Analytics-Veteran, der AI-native Unternehmen prägt.