Deutsche Telekom's LMOS: Was Enterprise-AI-Teams wirklich von einer Plattform wollen

Arun Joseph bei InfoQ beschreibt eine echte, in Produktion befindliche agentische Compute-Schicht: flüchtige Agenten, eine ADL und einen zentralen Fähigkeitenkatalog.

In einfachen Worten. Arun Joseph, der auf InfoQ präsentierte, beschrieb die unternehmensweite KI-Plattform (LMOS) von Deutsche Telekom: eine Schicht, die „Tool-Sprawl“ durch einen Satz an Kernabstraktionen ersetzt und eine Agent Definition Language (ADL) mit flüchtigen Agenten einführt. Die These: Agentic Compute ist die fehlende Schicht, die kein Cloud-Anbieter standardmäßig anbietet.

Die Fakten

InfoQ veröffentlicht am 3. August 2026 die Präsentation von Arun Joseph zu LMOS bei Deutsche Telekom. Drei Thesen: (1) Unternehmen leiden unter einer unkontrollierten Verbreitung von LLM-/Agenten-Tools („Tool Sprawl“); (2) Was sie brauchen, ist eine „Agentic Compute“-Schicht mit gemeinsamen Abstraktionen; (3) LMOS bietet eine Agent Definition Language (ADL) und flüchtige Agenten statt persistenter Dienste.

Unsere Einschätzung

Josephs These ist nicht neu – QCon AI Boston (Post #1211) und Cloudflare Agents Week (Post #1766) erzählen Varianten derselben Geschichte – doch ihr Wert liegt darin, dass sie aus der Perspektive eines Telekommunikationsanbieters kommt, der jahrzehntelangen Legacy-Code warten muss. LMOS ist ein Produktionserfahrungsbericht, keine Marketing-Keynote.

Was dieses Muster für Ihre Architektur bedeutet

• Flüchtig statt persistent. Ein Agent hat keinen Zustand zwischen Sitzungen; der Zustand lebt in der Datenebene (Vektordatenbank, Business-DB, Event-Log). Das vermeidet das Problem „langlaufender Gespräche, die Kontext verlieren“, und erleichtert horizontales Skalieren. Die kognitive Hürde: Jeden Agenten-Aufruf als reine Funktionsausführung zu denken, nicht als lebendiges Objekt.
• ADL als Vertrag. Einen Agenten durch Input und Output beschreiben, nicht durch den Prompt, den man ihm übergibt. Zwei Teams können dann interoperable Agenten schreiben. Das ist die echte MCP-Promesse, intern umgesetzt – mit stärkerem Typing.
• Core Platform vs. Tool Sprawl. Statt dass jedes Team seine Tools über LangChain hier und LlamaIndex dort anbindet, gibt es einen zentralen Katalog geteilter Capabilities mit gemeinsamer Observability und Policies. Das ist Plattformarbeit, keine Anwendungsentwicklung.

Hinter den Kulissen

LMOS ist noch nicht öffentlich. Die nächstliegende Open-Source-Entsprechung ist das, was sich um MCP + Registries (Anthropic MCP Hub, Cloudflare AI Gateway, Portkey) entwickelt. Der strukturelle Unterschied: Deutsche Telekom kontrolliert die Datenebene (Telefonie, Abrechnung, internes CRM) – ein Anwendungsfall, den ein US-Cloud-Anbieter nicht outsourcen kann und der daher die Internalisierung der Plattform strukturell erzwingt.

Fazit

Für Architekt:innen, die zwischen „Agentik-Framework des Monats“ und echter Plattform unterscheiden müssen: Der Test lautet: Wenn Ihre Agenten-Schicht es Ihnen nicht ermöglicht, einen Agenten ohne Python-Code zu definieren und ohne einen Dienst neu zu deployen, ist es keine Plattform, sondern ein SDK. LMOS deutet darauf hin, dass echte Produktionsplattformen eher wie Airflow aussehen als wie LangChain.

Zu beobachten

Mögliche Open-Source-Freigabe von LMOS oder einer Komponente (ADL); Veröffentlichung von Betriebsmetriken (Anzahl der Agenten in Produktion, Latenz, Kosten pro Aufgabe); Adoption durch andere europäische Telekommunikationsanbieter unter DMA/Datensouveränität.