Python is just the appetizer, while JVM is the main course. Eclipse's new open-source solution enables handling agents on K8s without changing the stack.
Recently, the Eclipse Foundation announced the launch of the "Agent Definition Language" (ADL) on its open - source platform, Eclipse LMOS. This is a structured, model - independent description method that allows users to define AI behaviors without writing code.
According to Eclipse, ADL will become a core component of the intelligent agent computing platform, LMOS. From the very beginning, the LMOS project aimed to run natively on Kubernetes / Istio and serve the JVM ecosystem. It aims to reconstruct the development and operation and maintenance links of enterprise - level AI agents in a unified and open way. At the same time, it also benchmarks against proprietary platforms and the enterprise AI technology stack mainly based on Python; this also means a direct challenge to the closed - source alternatives that have long dominated enterprise AI.
It's worth noting that the LMOS project follows the path of "implement first, then open - source": its predecessor was a production - level practice of Deutsche Telekom in the traditional cloud - native architecture, and it was later incubated in the Eclipse Foundation.
Full open - source address of the project: https://github.com/eclipse - lmos
1 Technology Convergence: Doing AI with Familiar Skill Stacks
In the past decade, enterprises have developed an effective engineering paradigm for cloud - based applications: instead of writing monolithic applications, they split them into microservices as much as possible, allowing different teams to be responsible for different parts and facilitating assembly and combination. At the same time, they package everything into containers for easy migration and deployment across environments; when traffic increases, they can also horizontally scale by replicating instances to let multiple replicas jointly handle requests and computations. This is roughly the common practice of building applications on the cloud today, and it works quite well.
Then, generative AI came along. In the past two years, people always seemed to be forced to "learn a bunch of new skills" to use new technologies. Looking back to 2023, new frameworks emerged continuously on GitHub, and many people were hesitating whether to follow up (at that time, Spring AI hadn't appeared yet, and LangChain4j had just emerged). But in fact, the top challenges for everyone have always been: how to improve development speed and how to efficiently utilize existing resources.
Facing the existing technology ecosystem, especially for enterprises deeply involved in the JVM system, there's actually no need to "start from scratch" and assemble an expensive new team. Therefore, the original intention of the LMOS project is to explore how to bring AI capabilities as close as possible to the skill stacks we are already familiar with, rather than forcing enterprises to abandon existing achievements, write Python scripts, and start all over again.
We can't discard the experience of the past decade and then "assemble a new team and switch to a whole new stack"
The LMOS project is related to these backgrounds. The project was led and designed by the person - in - charge, Arun Joseph, in 2023. At that time, he was in charge of an AI project of Deutsche Telekom, which needed to launch AI capabilities for sales and customer service in 10 European countries.
"When we were just starting out, although some frameworks emerged, such as LangChain, they were all written in Python," Joseph explained. "But like most telecommunications companies and enterprises, the entire enterprise - level technology stack of Deutsche Telekom is built on the JVM."
In addition, regardless of the language difference, the complexity of Deutsche Telekom's front - line business itself is very high: the same system needs to be deployed across multiple countries and pluggably connected to different channels (Web, App, hotlines, etc.); at the same time, the API system is complex, and the client library contains hundreds of attributes and years of accumulated domain knowledge. If starting over with Python, it would mean giving up existing assets and forcing the team to rebuild the system.
Moreover, to operate in 10 countries, the technical architecture must support "platform - based, centralized" unified deployment and management. Based on these considerations, the team decided to evolve within the familiar ecosystem: using Kotlin, reusing existing infrastructure, APIs, and DevOps capabilities to build a multi - agent platform.
The platform is based on Kubernetes and, with the capabilities provided by components such as Istio, deploys "agents / tools" in the form of microservices to the K8s environment and promotes them to first - class citizens through custom resources (CRD), supporting declarative management and observability.
In this way, developers can follow the existing workflow: just push an agent image, and then they can run it in a new environment for independent testing; the operation and maintenance team can directly use kubectl get agents and kubectl apply to monitor and release.
Therefore, in concept, Eclipse LMOS diverges from the current mainstream AI tool ecosystem. Joseph pointed out that many "enterprise - level AI technology stacks" are often a Python code library pieced together with SDKs of startups supported by venture capital - each only solves a small problem such as telemetry, memory, and evaluation - and then uses a decorator to stuff the entire container fleet into the infrastructure. "I've seen some evaluation tools that require 25 containers for a single function," he said. "That is, for one line of code, 25 containers run a custom Kubernetes Operator. Enterprises can't afford such disorderly expansion."
The approach of Eclipse LMOS avoids these problems: it natively integrates with Kubernetes, Istio, and JVM - based applications, smoothly connects with the DevOps processes, observability tools, and API libraries built by the organization over the years, and enables AI agents to enter the production system with the lowest migration cost.
These platforms have supported multiple AI applications of Deutsche Telekom, including the multiple - award - winning customer service robot, Frag Magenta. By the end of 2023, the first agent was put into production at Deutsche Telekom and expanded rapidly in Europe: the coverage increased from 3 - 4 countries to 10 countries, and after going live, it handled an average of about 4.5 million sessions per month; in 2024, the number of transfers to human agents decreased by 38%. Thus, it became one of the largest - scale, truly production - deployed Agentic systems in Europe.
By reusing the familiar technology stack, the development cycle was also compressed: "It took a month to build the first agent (while also building the platform); then, with the participation of a small number of engineers, the cycle was reduced to 15 days; later, it basically took only one or two days to create an agent along with a set of use cases."
"After a period of measurement, we found that with just one data scientist paired with one engineer, they could quickly go from a business idea or problem statement to deploying an agent in production. After entering the maintenance phase, they could still iterate quickly, and the small team also brought obvious cost advantages. We didn't get entangled in whether to recruit more AI/ML engineers or data scientists in advance at the beginning - many teams wasted time on such trade - offs in 2023 and 2024."
Subsequently, in 2024, the team migrated the proprietary code within Deutsche Telekom to the Eclipse Foundation for open - sourcing, and the project was released under the Apache - 2.0 license.
2 How to Integrate the Essence of Classic Domains into One Platform
In the process of truly pushing AI agents into the enterprise production environment, Eclipse adopted a "dual - track strategy". One track is the LMOS platform (which has been fully open - sourced). The other track is more groundbreaking: ADL (Agent Definition Language), "enabling more people to truly write agents".
"We were collectively 'unsatisfied' with the existing frameworks at that time, so we took the 'radically simplified' route: we chose Kotlin as the main language because it's convenient for us to create a domain - specific language (DSL) - that is, ADL."
"It's crucial to integrate business context into AI workflows and applications so that they can make high - quality decisions on a large scale. Natural language prompts cannot be version - controlled or audited - this is the pain point faced by enterprises and the reason for the existence of programming languages - so this method can meet the needs between the two."
This route also stems from the pain points in practice. In the real - world AI infrastructure, agents, prompts, and tools are layered on top of each other, and the complexity increases rapidly. The same pattern is reinvented repeatedly in different scenarios. More importantly, the system is still essentially driven by natural language - a large number of conditions, rules, and SOPs need to be imposed on the model for execution. Interestingly, the market is already flooded with these products. Individually, they are all great; but when assembled into a complete system, it's difficult for them to "communicate" and "stick" to each other.
Moreover, once the system expands, AI model integration becomes extremely delicate. A slight upgrade or a minor deviation in the model can cause the entire upper - layer behavior to change, making the whole system fragile (as shown in the figure below).
Therefore, this platform is ultimately condensed into three independent yet collaborative modules:
ADL: Structured and model - independent, it supports visual creation and multi - role collaboration, allowing business and engineering teams to jointly write agents. It enables business departments to define agent behaviors like writing SOPs, test and iterate immediately without waiting for engineering work order scheduling. At the same time, ADL still maintains engineering rigor: behaviors can be versioned, traced, and maintained, which is the key to its replacement of traditional prompt engineering.
ARC Agent Framework: Based on JVM/Kotlin, it provides an IDE - level development experience and visual debugging, allowing engineers to focus on business APIs and integration logic rather than building the underlying layer.
LMOS platform layer: An open cloud - native orchestration layer for agent lifecycle management, discovery, semantic routing, and observability. It's built on the Cloud Native Computing Foundation (CNCF) technology stack and is currently in the alpha version.
Surrounding the above modules, LMOS also provides a control plane tightly integrated with the operating environment: when an agent or tool is deployed as a microservice to Kubernetes, the LMOS Operator is responsible for lifecycle management. Whenever a new application is installed, the Operator receives event notifications, grabs its Description (documentation), and writes it into the Kubernetes Registry (currently used as a storage mechanism); at the same time, the Operator also provides a Directory API from the Web of Things to facilitate the discovery of which agents are installed in the Kubernetes environment.
Among them, it's also worth mentioning the LMOS protocol.
Considering that each agent has an independent lifecycle, the system needs a mechanism for agents to discover each other and negotiate communication protocols. The design of LMOS draws on the mature standards of the W3C and gets inspiration from decentralized technologies such as Matter/Thread and Bluesky's AT Protocol. Its goal is to connect AI agents across organizational boundaries on the platform, similar to how the Internet connects computers and the Internet of Things connects devices, to achieve a discoverable and interoperable agent network.
The Eclipse team recalled that in the early days, they managed to build things without MCP: since they were familiar with internal APIs, they first compressed a set of "converged" interfaces for function calls instead of building a new server and introducing a bunch of new concepts. They also implemented a "tool registry" before MCP: just fill in the tool name, and it will be automatically registered, so that the model knows "which tool to use". Later, MCP became popular, and Google launched A2A.
However, this doesn't mean that there's no room for a path like LMOS - after all, in the reality where most agents run on the cloud and cloud standards have been established, to truly align agents with the existing cloud - native stack, a protocol and platform like LMOS that are close to the engineering field are actually needed. Of course, facing the fast - paced updates and implementations of the MCP and A2A standards, it will be a tough battle for the Eclipse Foundation.
3 In Conclusion
In the current era when generative AI is sweeping across enterprise software, an invisible fault line is forming in the technology world: on one side is the Python camp, which is agile, open - source, and focuses on rapid prototype iteration, leading innovative startups; on the other side is the large and mature JVM world, which, on the premise of stability and controllability, hosts the key systems of most enterprises.
Eclipse LMOS stands in this gap, trying to do something that seems simple but is actually quite ambitious: bringing AI agents back to the infrastructure that enterprises can understand, operate, and host in the long term. You don't need to "start from scratch" and reassemble a team that only writes Python, nor do you have to run around between prompts and external tools; you can start from entrances like Eclipse LMOS and ADL and then gradually increase the system complexity to mature stacks such as Kubernetes as needed.
"Agentic AI is redefining enterprise software, but there's still a lack of open - source software that can truly replace proprietary products," Mike Milinkovich, the executive director of the Eclipse Foundation, once said in a statement. "With Eclipse LMOS and ADL, we're providing a powerful open platform on which any organization can build scalable, intelligent, and transparent agent systems."
What LMOS and ADL do is to let agents naturally grow on the technology you already trust - perhaps this is the most anticipated turning point in the "agent era".
Reference Links:
https://thenewstack.io/eclipse - opens - up - enterprise - ai - agent - development - with - ad