Deutsche Telekom’s answer to scaling AI assistants was to build a shared platform around them: LMOS, a system for developing, routing, deploying, and operating specialized agents across customer-service workflows. The key shift was from proving that a chatbot could answer questions to standardizing the infrastructure, retrieval, governance, and handoffs needed to run many agents across markets.
The problem was bigger than building a chatbot
Deutsche Telekom serves customers across multiple European markets, where support must account for different languages, products, policies, backend systems, and network contexts. An assistant also needs to know when to use an enterprise API, when to hand a conversation to a person, and how to keep information separated by country, business unit, or other tenant.
That makes the challenge organizational as much as technical. A successful demo does not, by itself, provide repeatable deployments, safe tool access, current knowledge, monitoring, or consistent behavior across teams. The company’s goal was to operate many AI-powered assistants under shared controls rather than create each chatbot as a standalone application, according to Arun Joseph’s July 8, 2025 account, written by a former Deutsche Telekom engineering and architecture lead.
Why the early prototypes were not enough
The team experimented with LangChain, retrieval-augmented generation (RAG), and dense passage retrieval models optimized for German-language use cases. Joseph says those experiments exposed memory and stability problems, maintenance overhead, framework complexity, and a mismatch with Deutsche Telekom’s existing JVM-based engineering environment.
Recommended Free Tools
#1 Best Overall
That distinction matters: a prototype stack can show that a model can answer a question, while a production platform must also handle deployment, lifecycle management, monitoring, routing, tenant separation, versioning, and recovery. Repeating application-specific integrations for every assistant would leave those operational concerns scattered across teams.
What LMOS is—and what it is not
LMOS, or Language Model Operating System, is an open-source platform for building and running enterprise multi-agent systems. Eclipse also describes it as a reference implementation for an emerging LMOS Protocol. Despite the name, LMOS is not a general-purpose operating system like Linux or Windows; it is a platform abstraction for agent development and operations. Its documented capabilities include agent and deployment lifecycle management, dynamic routing, runtime orchestration, Kubernetes-based scaling, multitenancy, and integration with frameworks including Arc, LangChain4j, LlamaIndex, and LangChain. See the Eclipse LMOS overview and the project’s component repositories.
A simplified view of the architecture is:
Customer or channel
↓
LMOS Router / classifier
↓
Specialized agent
↓
Arc or another agent framework + model provider
↓
Retrieval (including Qdrant) + tools + enterprise APIs
↓
Response or human handoff
Cross-cutting platform concerns:
Kubernetes · lifecycle · versioning · observability · multitenancy · rollout
Knowledge ingestion:
Wurzel ETL → prepared data → retrieval index
This is a conceptual map, not a claim that every production workflow follows one fixed path. The detailed deployment account and the public project documentation describe different kinds of evidence: Joseph’s article reports Deutsche Telekom’s implementation experience, while Eclipse documents the project’s public components and intended capabilities.
Arc made agent development fit the JVM environment
Arc is LMOS’s Kotlin-based framework for defining LLM-powered agents. Its Kotlin DSL and scripting model were intended to make agent development more familiar to engineers already working in the JVM ecosystem. Arc also provides patterns for integrating tools and model clients, with Spring Boot integration documented in the project materials. The public Arc repository describes the framework, while the Arc setup manual documents configuration and integrations.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Rank #2
For illustration, the repository’s minimal Kotlin example defines an agent with a name, model, and prompt:
fun main() = runBlocking {
agents {
agent {
name = "MyAgent"
model { "gpt-4o" }
prompt {
"""
You are a helpful assistant. Help the user with their questions.
"""
}
}
}.serve()
}
This is a public example, not evidence that Deutsche Telekom uses that model name or prompt in production. Arc also supports function definitions so an agent can call tools; the manual shows a simple weather function as an example. Tool access is consequential in a customer-service setting: actions that change accounts or trigger transactions need authorization, auditability, and safeguards beyond a prompt telling the model to be careful.
The manual documents configuration paths for OpenAI, Azure/OpenAI, Gemini through LangChain4j, Ollama, and Amazon Bedrock. It uses a variable such as $arcVersion in dependency examples rather than pinning a stable version on the page, so teams reproducing a setup should verify the current repository and Maven metadata. The documented configuration lookup order is system properties, environment variables, then home/.arc/arc.properties.
Specialized agents need a routing layer
Rather than make one general-purpose assistant carry every policy, tool, and product domain, the architecture can assign work to specialized agents—for example, sales, billing, technical support, or complaints. A router first interprets the request and selects an agent whose declared capabilities fit. This can make responsibilities easier to test and govern, and it can avoid sending every decision through a large model.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →The LMOS Router documents vector-similarity, LLM-based, and hybrid classification strategies. Its ranking controls include minimum score and comparisons between leading candidates, such as the gap between the top two scores. The documentation notes that good thresholds depend on the number and type of agents, the embedding model, language, and the quality of capability descriptions.
Semantic routing is not inherently reliable. Short or mixed-language queries, overlapping domains, new products, and unfamiliar terminology can all lead to a wrong destination. A production design therefore needs tested confidence thresholds, an explicit fallback when no route is clear, and a human escalation path. Routing quality should be evaluated on representative queries rather than inferred from a technically successful classifier.
RAG was treated as shared infrastructure
Agents need more than model inference: they need access to documentation, FAQs, product information, policies, country-specific procedures, and structured backend data. Deutsche Telekom’s account describes standardizing retrieval workflows rather than leaving every team to build its own ingestion and indexing path.
Qdrant for vector search
Joseph’s account says Deutsche Telekom selected Qdrant after evaluating alternatives, citing its open-source availability, Rust implementation, performance, multitenancy, and metadata filtering. Those are reported reasons for the company’s choice, not proof that Qdrant is the best fit for every workload. Qdrant’s own documentation overview describes its vector-search capabilities.
Free tools Windows power users keep installed
One-click scans. No signup required.
Metadata filters can help constrain retrieval by attributes such as country, domain, or agent type. They should be enforced as part of the retrieval system’s access controls, not treated as optional hints in a prompt. A response that retrieves a policy for the wrong country can be fluent and still be wrong.
Wurzel for ingestion and preparation
The project account describes Wurzel as an open-source Python ETL framework for RAG. Its role is to standardize extraction, chunking and preparation, loading, scheduling, backend integration, and multitenant data handling. The broader lesson is to manage knowledge ingestion as a reusable platform capability: document ownership, effective dates, updates, and removal from indexes matter as much as the choice of embedding or vector database.
Kubernetes moves deployment concerns out of each agent
LMOS uses Kubernetes-related components to manage deployments and runtime operations. The LMOS Runtime handles conversation and agent orchestration concerns, while the LMOS Operator is designed to manage agent deployments in Kubernetes and resolve channel requirements against agent capabilities. The project describes platform support for lifecycle management, scaling, multitenancy, and rollout strategies.
This is the basis for the “Heroku for agents” analogy used in Joseph’s account: developers define an application, while a platform handles much of deployment and operations. The analogy describes an experience goal, not a promise that agent complexity disappears. Teams still need to diagnose whether a failure came from the model, router, retrieval corpus, tool API, infrastructure, or country-specific configuration. Tracing should follow requests across those boundaries, not stop at the gateway.
Best Value
Business-defined workflows still need engineering controls
Agent Definition Language (ADL) is intended to let business teams define or update agent behavior and operating procedures with less engineering involvement. The existence and stated purpose of ADL are documented in the LMOS project organization; Joseph’s account describes business participation in updates. That does not establish that business teams everywhere can independently operate production agents without technical oversight.
Faster changes can also create policy drift or expose a tool or data source to the wrong workflow. A safer operating model versions ADL changes, assigns owners, requires appropriate review, tests changes against country- and domain-specific cases, stages rollouts, and preserves rollback. Business ownership can shorten the iteration loop, but it does not replace access control or accountability.
What Deutsche Telekom reported—and what the figures do not show
According to Arun Joseph’s July 2025 account, LMOS supported millions of interactions across Deutsche Telekom markets, new agents could be developed in a day or less, and roughly 30% of API-triggering Arc-agent interactions were handed to a human. These are reported project outcomes, not independently audited benchmarks. The account does not specify a precise interaction count or period, a before-and-after baseline, cost per interaction, accuracy, service-level results, or country-by-country performance.
The handover figure applies to the described API-triggering Arc agents; it should not be read as the human escalation rate for every LMOS conversation. Nor does the reported scale, by itself, establish customer satisfaction, containment quality, or financial return.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →What another enterprise can learn from the design
- Build a platform around repeated needs. Shared deployment, routing, retrieval, and observability become valuable when multiple teams face the same operational problems. They can be needless overhead for a small proof of concept.
- Keep the layers replaceable. Model providers, agent frameworks, retrieval stores, and business tools change at different speeds. Abstraction can limit lock-in, but it should not hide the details needed to debug a failure.
- Treat tenant separation as infrastructure. Enforce country and business boundaries in retrieval and tool access, not only in instructions to a model.
- Make routing and handoff explicit. Use thresholds, fallback behavior, escalation context, and tested policies for ambiguous requests. Human agents should receive useful conversation history, retrieved evidence, attempted actions, and a reason for the handoff.
- Version knowledge as well as agent behavior. Track document ownership, version, effective date, and expiry so retrieval does not quietly surface obsolete policy.
- Limit agent autonomy. Set tool permissions, approval gates for consequential actions, idempotency protections, turn and tool-call limits, budgets, and circuit breakers.
- Measure outcomes, not just answer similarity. Evaluate task success, factuality, policy compliance, latency, cost, escalation quality, and customer outcomes using representative cases.
Portability and sovereignty have limits
LMOS’s open-source, Kubernetes-oriented design aims to support portability across cloud, private-cloud, and on-premises environments. The Eclipse project proposal documents Deutsche Telekom’s initial contribution to the Eclipse Foundation, and public repositories identify Apache 2.0 licensing; see the Eclipse proposal and the Arc repository. These choices can increase control over deployment, but they do not automatically deliver legal or geographic data sovereignty, regulatory compliance, local inference, or independence from model vendors. Those depend on where models run, what data is sent or logged, provider terms, and operational configuration.
There is also a distinction between the running platform and the protocol ambition. Eclipse states that the LMOS Protocol is a work in progress and is not a W3C standard or on the W3C Standards Track. Organizations relying on protocol interoperability should account for change and possible adapter work rather than assume a settled industry standard.
The detailed Deutsche Telekom account was published in July 2025, while the public repositories continue to evolve. Internal production details may have changed since that description. The architecture is most useful as a pattern—shared operations around specialized agents—not as a turnkey product or a guarantee of a particular outcome.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
