Deutsche Telekom's LMOS: what enterprise AI teams actually want from a platform

Arun Joseph at InfoQ describes a real, in-production agentic compute layer: ephemeral agents, an ADL, and a central capabilities catalogue.

In plain terms. Arun Joseph, presenting at InfoQ, described Deutsche Telekom's enterprise AI platform (LMOS): a layer that replaces "tool sprawl" with a set of core abstractions, and introduces an Agent Definition Language (ADL) with ephemeral agents. The framing: agentic compute is the missing layer that no cloud provider ships out of the box.

Le fait

InfoQ publie le 3 août 2026 la présentation d'Arun Joseph sur LMOS chez Deutsche Telekom. Trois thèses : (1) les entreprises subissent une prolifération d'outils LLM/agents mal cadrés ("tool sprawl") ; (2) ce dont elles ont besoin est une couche "agentic compute" avec des abstractions communes ; (3) LMOS propose une Agent Definition Language (ADL) et des agents éphémères plutôt que des services persistants.

Notre lecture

La thèse Joseph n'est pas neuve - QCon AI Boston (publi #1211) et Cloudflare Agents Week (publi #1766) racontent des variantes de la même histoire - mais son intérêt est d'y arriver depuis un opérateur télécom qui doit maintenir des décennies de code métier. LMOS est un retour d'expérience de production, pas une keynote de vendor.

Ce que le pattern implique pour votre archi

• Éphémère plutôt que persistant. Un agent n'a pas d'état inter-session ; l'état vit dans le data plane (base vectorielle, DB métier, event log). Ça évite l'écueil "long-running conversation qui fuit du contexte" et facilite le scaling horizontal. Le coût cognitif : penser chaque appel d'agent comme un pure function call, pas comme un objet vivant.
• ADL comme contrat. Décrire un agent par ce qu'il consomme et produit, pas par le prompt qu'on lui passe. Deux équipes différentes peuvent alors écrire des agents interopérables. C'est la vraie promesse MCP appliquée en interne, avec un typage plus fort.
• Core platform vs tool sprawl. Plutôt que chaque équipe branche ses outils via LangChain d'un côté, LlamaIndex de l'autre, un catalogue central de capabilities partagé, avec observabilité et policy shared. C'est un travail de plateforme, pas d'application.

Under the hood

LMOS n'est pas encore public. Le parallèle open source le plus proche est ce qui émerge autour de MCP + registries (Anthropic MCP hub, Cloudflare AI Gateway, Portkey). La différence structurante : Deutsche Telekom a le contrôle du data plane (téléphonie, facturation, CRM interne) - un cas d'usage qu'un cloud américain ne peut pas outsourcer, et donc où l'internalisation de la plateforme est structurelle.

So what

Pour les architectes qui font le tri entre "framework agentique du mois" et vraie plateforme : le test est le suivant. Si votre couche agents ne vous permet pas de définir un agent sans écrire de code Python et de le déployer sans redéployer un service, ce n'est pas une plateforme, c'est un SDK. LMOS suggère que les vraies plateformes en prod ressemblent plus à Airflow qu'à LangChain.

À surveiller

Ouverture éventuelle de LMOS ou d'un composant (ADL) en open source ; publication de métriques opérationnelles (nombre d'agents en prod, latence, coût par tâche) ; adoption chez d'autres opérateurs européens sous DMA/data-sovereignty.