MUNICH, Arun Joseph, co-founder and CEO of Masaic and former Head of AI Engineering at Deutsche Telekom, took the stage at InfoQ Dev Summit Munich to argue that enterprises are failing at AI not because of model quality, but because they lack a fundamental architectural layer. In a 48:52-minute presentation titled "Architecting AI Systems for the Messy Reality of Enterprises: Why Agentic Compute is the Missing Layer," Joseph drew on his experience building Deutsche Telekom's LMOS platform to make the case that agentic compute must be treated as a first-class infrastructure component, not an afterthought.
Joseph's talk came at a conference featuring 20+ senior software developers, and it carried a personal weight: his previous talk at the same event was so successful that he quit his job to start Masaic. Now, his stealth startup is building AGC (Agentic Compute), which he describes as a new computing substrate for knowledge work. The company's core product is called Atlas, and its goal is nothing less than "a better Palantir" with an open core.
The stakes are high. Joseph cited a famous MIT study showing a 95% failure rate for AI projects. The question he posed to the audience was direct: why do 95% of these initiatives fail? His answer, built from years inside one of Europe's largest telecommunications companies, is that enterprises are trying to bolt agentic behavior onto architectures that were never designed for it.
The LMOS Story: Five Engineers, One Platform, Zero Vendor Shortcuts
The foundation of Joseph's argument is LMOS, the Language Models Operating System built at Deutsche Telekom. The program was envisioned and went live in 2023, making it potentially one of the first agentic platforms to go live in Europe or elsewhere in a large enterprise. LMOS is now open source and under the stewardship of the Eclipse Foundation, and it is still running in Deutsche Telekom across multiple countries.
What makes the LMOS story remarkable is the size of the team that built it. Joseph said the initial program was built by a team of five distributed systems engineers. That small group managed to create a platform that was tested against some of the best vendor products on the market and still outshone them.
The path to that success was not smooth. Joseph was candid about the early missteps. The initial use of LangChain, the popular agent framework, was a disaster. The team abandoned it and built a custom framework in Kotlin, which allowed existing engineers to attach enterprise libraries as dependencies. That framework became LMOS ARC, the Agent ReaCtor, and it sits alongside the LMOS agent platform, a custom Kubernetes container.
One of the key insights from the LMOS build was the importance of working with existing enterprise stacks. At Deutsche Telekom, the Java/JVM ecosystem had hundreds of client libraries for APIs. By building ARC in Kotlin, Joseph's team could plug directly into that ecosystem without forcing engineers to learn new tools. This became what Joseph called a "magic bullet": build agents with existing teams and stacks.
The second magic bullet, he said, is to platformize the hard parts and get out of the way. That means taking the messy, repetitive work of agent infrastructure and turning it into a service, so that engineers can focus on the actual agent logic.
Joseph's background is in building platforms across Europe, the U.S., and Canada, with a focus on distributed systems in large enterprises. This experience is evident in his talk. He is not a researcher or a vendor evangelist; he is an engineer who has built and deployed agentic systems in production. His advice is grounded in that experience.
The talk was also notable for its length. At 48:52, it was a deep dive, not a keynote soundbite. Joseph had time to walk through the technical details, the failures, and the lessons learned. This is the kind of content that senior developers need, and it is a sign of the maturity of the agentic computing field that such a detailed presentation was possible.
The Messy Reality: Fault Lines, Tool Sprawl, and the Four Work Packages
Joseph's central observation about enterprises is that they are not clean systems. They are collections of teams, APIs, and processes that have grown organically over decades. He summarized all enterprise work into four work packages: storage, transformation, presentation, and transmission. Every business process, he argued, can be decomposed into these four functions.
The problem is that these functions are scattered across organizational and technical boundaries. Joseph referred to a famous presentation by Josh Evans, who presented on microservices at Netflix, to illustrate the point. In large enterprises, there are many teams and many APIs, and the fault lines between them are where complexity lives. Understanding these fault lines requires one or two people within each one, people who know the undocumented quirks and the real-world behavior of the systems.
To drive the point home, Joseph showed an example from the TM Forum, the telco specification body. He asked the audience to consider a product ordering API. "I want to do the product ordering. Can you show me the API?" he said, and then displayed the API specification. The point was that enterprise APIs are messy. They are not the clean, well-documented interfaces that developers dream about. They are full of edge cases, legacy fields, and business rules that have accreted over time.
This messiness is exactly why building agentic systems detached from the actual problem leads to failure. Joseph argued that you cannot build a useful agent for an enterprise process without deeply understanding the fault lines in that process. And that understanding cannot be automated away; it requires human expertise embedded in the system.
The four work packages are not just an abstract framework. They map directly to the kinds of tasks that agents are asked to perform. Storage is about persisting data, transformation is about changing it, presentation is about displaying it, and transmission is about moving it. Every business process, from order management to supply chain optimization, can be broken down into these components. The challenge is that in a large enterprise, each component may live in a different system, owned by a different team, with its own API and its own quirks.
Joseph's point is that an agent cannot simply call an API and expect it to work. It must understand the context, the edge cases, and the business rules that govern that API. This is why the fault lines between teams and systems are so important. They are where the complexity lives, and they are where agents are most likely to fail.
The TM Forum example was particularly telling. The product ordering API specification was not a clean, RESTful interface. It was a sprawling document with dozens of fields, many of them optional, many of them with complex validation rules. An agent that tried to use this API naively would fail. It would need to know which fields were required, which were optional, and which combinations were valid. This knowledge is not in the API specification; it is in the heads of the people who have worked with the system for years.
This is why Joseph argued that building agentic systems requires a deep understanding of the fault lines. It is not enough to have a good model and a good framework. You need to know how the enterprise actually works, and that knowledge is hard-won and often undocumented.
One of the most striking examples in Joseph's talk concerned tool sprawl. The AI startup ecosystem has produced a flood of specialized tools: eval startups, telemetry startups, memory startups. Each of these brings its own SDK, and each SDK adds complexity. Joseph said that a simple agent can end up requiring 25 containers just to run, and that this creates an operational burden that DevOps teams are unable to support.
The cost is not just operational. Joseph noted that license costs for eval tools can reach 100k in large enterprises, and he added that in that context, 100k is nothing. The real cost is the fragmentation of the stack, the new fault lines that these tools introduce, and the cognitive load on the teams that have to maintain them.
Joseph's prescription is to resist the urge to adopt every new tool. Instead, he said, enterprises should leverage the observability stacks they already have. At Deutsche Telekom, the LMOS platform plugged into the existing SigNoz, Grafana, and Prometheus infrastructure rather than introducing new monitoring tools. This approach kept the operational footprint manageable and allowed the team to focus on the agent logic itself.
The time breakdown is stark. Joseph said that building a simple agent, the plumbing takes 95% of the time, and only 5% goes to the actual agent logic. The plumbing includes observability, guardrails, evals, and model integration. This is the hidden cost of AI adoption, and it is why so many projects fail. The 95% failure rate from the MIT study, Joseph suggested, is not because the models are bad, but because the surrounding infrastructure is so brittle.
The tool sprawl problem is not just about the number of tools. It is about the interactions between them. Each tool has its own SDK, its own configuration, its own failure modes. When you combine them, you get a system that is exponentially more complex than the sum of its parts. This is why the 25-container example is so powerful. A simple agent, something that should be a few hundred lines of code, ends up requiring a small data center to run.
Joseph's advice is to be ruthless about tool adoption. If a tool does not provide clear value, do not use it. If you can use an existing tool, do that instead. The goal is to minimize the number of moving parts, not to maximize it. This is a counterintuitive message in an industry that is constantly pushing new tools, but it is one that resonates with anyone who has tried to run a complex system in production.
The observability stack at Deutsche Telekom is a good example. Instead of adopting a new AI-specific monitoring tool, the team plugged into SigNoz, Grafana, and Prometheus. These are tools that the DevOps team already knew how to use. They did not need to learn a new system, and they did not need to integrate a new SDK. The result was a system that was easier to operate and easier to debug.
The Agent Definition Language and the Hard Parts of Production
One of the most innovative parts of the LMOS stack is the Agent Definition Language, or ADL. Joseph described ADL as a layer and compiler for defining agent use cases in a structured format. Its purpose is to compress the loop between business, engineers, and DevOps. Instead of requiring business users to understand the technical details of agent construction, ADL allows them to write agent use cases in a prescribed format.
ADL compiles use cases into system prompts, a process Joseph compared to tree shaking. It does not send raw data to the LLM; instead, it extracts the relevant parts of the use case and turns them into a prompt. This is not a DSPy alternative, Joseph was careful to note. It is for business people.
The ADL environment is a Spring Boot container with a UI for quick iterations. Joseph gave an example of how a business user might interact with it. Consider a car owner whose vehicle has broken down. The user might write something like, "My Golf broke down, I want to book it." The system then picks the correct use case from the defined set and handles the booking. This is a far cry from the typical developer-centric approach to building agents.
Joseph also gave a more complex example involving travel. He described a request: "Hey, find me the best hotel in the location with the warmest weather between three cities, and book it for me." This requires the agent to compare weather across cities, evaluate hotels, and make a booking, all while respecting the enterprise's business rules and constraints. ADL provides a mental model for business users to draft these kinds of use cases without needing to understand the underlying agent infrastructure.
The ADL approach also addresses a key enterprise concern: governance. By defining use cases in a structured format, the business can review and approve what the agents are allowed to do. This is a significant advantage over the ad-hoc approach of letting developers write prompts directly.
The tree-shaking comparison is apt. Just as a bundler removes unused code from a JavaScript application, ADL removes irrelevant context from a prompt. This is important for two reasons. First, it reduces the amount of data sent to the LLM, which reduces cost and latency. Second, it reduces the chance of the LLM being confused by irrelevant information. The result is a more reliable and more efficient agent.
The car booking example is a good illustration of how ADL works in practice. The user does not need to know anything about agents, prompts, or LLMs. They just describe what they want in natural language. The system takes that description, matches it to a predefined use case, and executes it. This is a much lower barrier to entry than traditional agent development, which requires a deep understanding of the underlying technology.
The travel example is more complex, but it shows the power of the approach. The agent needs to compare weather across three cities, evaluate hotels, and make a booking. This is a multi-step process that involves multiple data sources and multiple decisions. ADL allows a business user to describe this process in a structured format, and the system handles the rest. This is a significant step forward from the current state of the art, where such a process would require a developer to write custom code.
Joseph was explicit about what he considers the hard parts of building agentic systems at scale. These are the components that most Hello World examples ignore, and they are the reason why most simple agent examples will not work in production.
The first hard part is session management. In a multi-agent system, sessions are not simple request-response cycles. They involve multiple agents, parallel execution, and synthesis of results. Managing the state of these sessions is a significant engineering challenge.
The second is context management. Agents need to maintain context across multiple interactions, and that context can be large and complex. The system must decide what to keep, what to discard, and what to summarize. This is not a solved problem, and it is one of the reasons why context management is a key part of Masaic's platform.
The third hard part is telemetry fan-out. In a system with many agents running in parallel, the telemetry data can be overwhelming. The platform must fan out this data to the appropriate monitoring and logging systems without becoming a bottleneck. At Deutsche Telekom, the team plugged into the existing observability stack rather than building new tooling, and this approach kept the system manageable.
The fourth hard part is model switching. Joseph emphasized that model switching is critical for cost amortization. In a system with a million invocations, the difference between using a large model and a small model can be enormous. The platform must make it easy to switch between models based on the complexity of the task. This is not just a cost optimization; it is a necessity for running agentic systems at scale.
Joseph also mentioned the Model Context Protocol (MCP), which is still evolving. He cautioned against treating it as a solved problem and noted that the ecosystem around MCP is still in flux.
Session management is often overlooked in simple examples. A chatbot that handles a single conversation is easy to build. But a system that coordinates multiple agents, each with its own session, is much harder. The platform must track the state of each session, coordinate the execution of multiple agents, and synthesize the results. This is a distributed systems problem, and it is not trivial.
Context management is similarly complex. In a long-running conversation, the context can grow unboundedly. The system must decide what to keep, what to discard, and what to summarize. This is a trade-off between completeness and efficiency. Keep too much, and the system becomes slow and expensive. Keep too little, and the system loses important information. This is an active area of research, and it is one of the reasons why context management is a key part of Masaic's platform.
Telemetry fan-out is a practical problem that is often ignored until it is too late. In a system with many agents running in parallel, the telemetry data can be overwhelming. The platform must fan out this data to the appropriate monitoring and logging systems without becoming a bottleneck. At Deutsche Telekom, the team plugged into the existing observability stack rather than building new tooling, and this approach kept the system manageable.
Model switching is a cost optimization that is often overlooked. In a system with a million invocations, the difference between using a large model and a small model can be enormous. The platform must make it easy to switch between models based on the complexity of the task. This is not just a cost optimization; it is a necessity for running agentic systems at scale. A system that uses a large model for every task will be prohibitively expensive. A system that can switch to a small model for simple tasks will be much more cost-effective.
MCP is a promising protocol, but it is not mature. Joseph cautioned against treating it as a solved problem. The ecosystem around MCP is still in flux, and it is not clear how it will evolve. This is a reminder that the agentic computing field is still young, and many of the standards are still being defined.
From Chatbots to Operational Intelligence: The Heavy Machinery Example
Stay ahead of the AI curve
The most important updates, news, and content — delivered weekly.
No spam. Unsubscribe anytime.
Joseph's current work at Masaic is focused on operational intelligence systems for critical infrastructure and large enterprises. This is a different category from the chatbots and automations that dominate most AI discussions. Operational intelligence involves decisioning and actioning, not just conversation.
The example Joseph used was heavy machinery operations. Companies like Hitachi, John Deere, and SENNEBOGEN operate fleets of machines where downtime is extremely costly. Masaic's system ingests IoT data, telemetry, standard operating procedures (SOPs), incident reports, and frontline intelligence. It then dynamically constructs SOPs with agentic actions, documents, processes, and human-in-the-loop approvals.
The results are revealing. Joseph showed an analysis of the use cases in the system. "Look at it. It looks like 73% of the use cases are around air filter management issues, and here are the classification of those issues," he said. This kind of insight, derived from the operational data, is exactly what a traditional dashboard cannot provide. The system does not just report on problems; it identifies patterns and suggests actions.
Another example involved a specific part, the JP-100 seal kit, which was failing consistently. The system flagged this pattern and recommended that the company stock up on the part. This is the kind of proactive, actionable intelligence that Joseph argues is the real value of agentic systems in the enterprise.
Masaic's early experience with this system was instructive. The company started with 50-60 agents for heavy machinery operations, and Joseph said that approach was not scalable. The solution was to move to ephemeral agents, which are spun up for specific research tasks, execute in parallel, and then are torn down. This is a fundamentally different architecture from the pre-defined agents that most frameworks encourage.
The shift to ephemeral agents was driven by a pattern spotted by Joseph's co-founder, Amant, who is referred to as the "Agent Whisperer" or "Ontology Oracle." After building 50-100 agents, Amant noticed recurring patterns in the agent programming paradigm. These patterns became the foundation for Masaic's AGC platform.
The heavy machinery example is a powerful demonstration of the value of operational intelligence. A traditional dashboard would show that air filter issues are common, but it would not tell you why. The Masaic system goes further. It classifies the issues, identifies the root causes, and suggests actions. This is the difference between reporting and intelligence.
The JP-100 seal kit example is even more compelling. The system did not just flag a problem; it recommended a specific action. It told the company to stock up on a part that was failing consistently. This is the kind of insight that can save a company millions of dollars in downtime and replacement costs. It is also the kind of insight that is impossible to get from a static dashboard.
The shift to ephemeral agents is a key architectural insight. Pre-defined agents are like employees with fixed job descriptions. They are good at what they do, but they are not flexible. Ephemeral agents are like consultants. They are spun up for a specific task, execute it, and then disappear. This is a much more scalable approach, especially for research-heavy tasks.
Amant's role in this shift is interesting. He is not a traditional engineer; he is more of a pattern-spotter. After building dozens of agents, he noticed that certain patterns kept recurring. These patterns became the foundation for AGC. This is a reminder that the best architectures are often discovered, not designed.
One of the recurring themes in Joseph's talk was the importance of human-in-the-loop processes. In the heavy machinery example, the system can construct SOPs dynamically, but it does not execute them without human approval. This is a critical design choice, and it reflects a realistic understanding of how enterprises operate.
Human-in-the-loop is not just about safety; it is also about trust. If the system makes a mistake, the human can catch it. If the system proposes an action that violates a business rule, the human can reject it. This is especially important in regulated industries and in situations where the cost of a mistake is high.
Joseph's point is that agentic systems should not be designed to replace humans. They should be designed to augment them. The system handles the routine, the repetitive, and the data-intensive work, and it surfaces the decisions that require human judgment. This is a more realistic and more valuable vision than the fully autonomous agent that many vendors promise.
The human-in-the-loop design is not a limitation; it is a feature. It allows the system to be deployed in environments where mistakes are costly. It also builds trust, because the humans know that they have the final say. This is especially important in regulated industries, where there are legal and compliance requirements for human oversight.
The heavy machinery example is a good illustration. The system can construct SOPs dynamically, but it does not execute them without human approval. This means that a human operator reviews the proposed action before it is taken. This is a safety net, and it is also a way to ensure that the system is behaving correctly.
Joseph's vision is that agentic systems should augment humans, not replace them. This is a more realistic and more valuable vision than the fully autonomous agent that many vendors promise. The system handles the routine, the repetitive, and the data-intensive work, and it surfaces the decisions that require human judgment. This is a division of labor that plays to the strengths of both humans and machines.
The 95% Failure Rate and the Path Forward
Joseph returned repeatedly to the 95% failure rate for AI projects, a figure from an MIT study. He argued that this failure rate is not an accident. It is the predictable result of building agentic systems on top of brittle infrastructure, without the right architectural foundation.
The problem, he said, is that most organizations treat AI as a model problem. They assume that if they have a good model, the rest will follow. But in reality, the model is a small part of the system. The plumbing, the integration, the observability, the guardrails, the evals, the model switching, the session management, the context management, all of these take 95% of the time. The actual agent logic is only 5%.
This is why Joseph argues that agentic compute is the missing layer. It is the infrastructure that handles all of the hard parts, so that engineers can focus on the 5% that matters. Without this layer, every AI project is a bespoke integration nightmare, and most of them fail.
Joseph also warned against a recent trend: treating every workflow as agentic. He mentioned the recent release of OpenAI AgentKit, an agentic workflow builder, and cautioned against the temptation to use it for everything. He gave a specific example: the Raft consensus algorithm should not be built with agentic workflows. Some things are better done with deterministic, well-understood algorithms. The goal is not to make everything agentic; it is to use agents where they add value.
The 95% failure rate is a sobering statistic, but Joseph's message is hopeful. The failures are not inevitable. They are the result of a missing architectural layer. By building that layer, enterprises can turn their AI projects from experiments into production systems that deliver real value.
The MIT study is often cited as evidence that AI is overhyped. But Joseph's interpretation is different. He argues that the failure rate is not a reflection of the models, which are getting better all the time. It is a reflection of the infrastructure, which is not keeping up. The models are ready for prime time, but the plumbing is not.
The 95% figure is a powerful motivator. It tells enterprises that they cannot just buy a model and expect success. They need to invest in the infrastructure that surrounds the model. This is a hard sell, because it is not as glamorous as buying a new model. But it is the difference between success and failure.
The warning about OpenAI AgentKit is timely. AgentKit is a powerful tool, but it is not a silver bullet. Joseph's point is that agentic workflows are not appropriate for everything. The Raft consensus algorithm is a good example. It is a well-understood, deterministic algorithm that has been proven to work. There is no reason to make it agentic. This is a reminder that the goal is not to use agents everywhere, but to use them where they add value.
Joseph's conclusion was practical. He offered two "magic bullets" for enterprises that want to succeed with agentic AI. The first is to build agents with existing teams and stacks. Do not hire a new team of AI specialists; instead, train the engineers you have and let them build on the infrastructure they already know. At Deutsche Telekom, this meant using the Java/JVM ecosystem and the hundreds of client libraries that already existed.
The second magic bullet is to platformize the hard parts and get out of the way. This means building or buying the infrastructure that handles session management, context management, telemetry fan-out, and model switching, so that engineers can focus on the agent logic. This is exactly what Masaic's AGC is designed to do.
Joseph also had a warning for the audience: OpenAI has not killed software engineering yet. The recent release of OpenAI AgentKit is not a reason to abandon traditional engineering practices. The Raft consensus algorithm is still better implemented with deterministic code, not with agents. The goal is to use agents where they add value, not to force everything into an agentic mold.
The first magic bullet is a counterintuitive one. Most organizations assume that they need to hire AI specialists to build agentic systems. But Joseph argues that this is a mistake. The engineers you already have are the best people to build these systems, because they already understand the enterprise's systems and processes. They just need the right tools and training.
The second magic bullet is about infrastructure. The hard parts of agentic systems, like session management and context management, are not the parts that engineers want to work on. They are the parts that are repetitive and messy. By platformizing these parts, you free up engineers to focus on the actual agent logic. This is exactly what Masaic's AGC is designed to do.
The warning about OpenAI AgentKit is a reminder that the hype cycle is not over. Every new tool is greeted with claims that it will change everything. But the reality is that most tools are incremental improvements, not revolutions. The Raft consensus algorithm is a good example. It is a well-understood, deterministic algorithm that has been proven to work. There is no reason to make it agentic.
The Future: A Better Palantir with an Open Core
Masaic is in stealth mode, and many details of its technology are not public. But Joseph was clear about the company's ambition. The goal is to build a "system of outcomes," a new class of software that sits above the systems of record like Salesforce and the data OS layers like Palantir. Where systems of record store data and dashboards display it, a system of outcomes takes action.
Joseph's reference point is Palantir, which he described as a data OS and dashboard company. Masaic aims to be a better Palantir, with an open core. The AGC platform is open by design and built for scale. It provides an architectural foundation for decisioning and actioning systems that integrate with existing enterprise stacks.
The heavy machinery example is the proof of concept. The system ingests IoT data, telemetry, SOPs, incidents, and frontline intelligence, and it produces actionable outcomes. It does not just show a dashboard; it tells the operator what to do, and it can execute the action with human approval.
Joseph also mentioned that Masaic's AGC is designed to work with existing enterprise stacks, not to replace them. This is a deliberate choice. Enterprises have invested billions in their existing systems, and they are not going to rip them out. The goal is to add an agentic layer on top, one that can make those systems smarter and more responsive.
The "system of outcomes" concept is a new category of software. Systems of record, like Salesforce, store data. Data OS layers, like Palantir, organize and display data. But neither of these takes action. A system of outcomes goes one step further. It not only understands the data, but it also decides what to do and executes the action. This is a significant shift in the software paradigm.
The comparison to Palantir is instructive. Palantir is a powerful platform, but it is also expensive and closed. Masaic aims to be a better Palantir, with an open core. This means that the core platform is open source, and enterprises can build on top of it. This is a more accessible approach, and it is likely to appeal to enterprises that are wary of vendor lock-in.
The heavy machinery example is a good illustration of the "system of outcomes" concept. The system does not just show a dashboard with air filter issues. It tells the operator what to do about them. It recommends stocking up on the JP-100 seal kit. This is a system that takes action, not just one that reports.
The decision to work with existing enterprise stacks is a pragmatic one. Enterprises have invested billions in their existing systems, and they are not going to rip them out. The goal is to add an agentic layer on top, one that can make those systems smarter and more responsive. This is a much easier sell than asking enterprises to replace their entire infrastructure.
Joseph's core thesis is that agentic compute is the missing layer for enterprise AI. It is the infrastructure that sits between the models and the business processes, handling the messy reality of enterprise systems. Without it, every AI project is a bespoke integration nightmare, and most of them fail.
The LMOS experience at Deutsche Telekom is the proof. A team of five engineers built a platform that went live in 2023, is still running across multiple countries, and is now under the Eclipse Foundation. They did it by working with existing teams and stacks, by platformizing the hard parts, and by resisting the lure of tool sprawl.
Masaic is now building the next generation of this infrastructure. The company's AGC platform is designed to be open, scalable, and integrated with existing enterprise stacks. The goal is to make agentic compute as ubiquitous as storage, compute, and networking.
The heavy machinery example shows what this looks like in practice. The system ingests IoT data, telemetry, SOPs, incidents, and frontline intelligence, and it produces actionable outcomes. It identifies that 73% of use cases are around air filter management, it flags the JP-100 seal kit failure, and it recommends stocking up. This is not a chatbot; it is an operational intelligence system that makes decisions and takes actions.
Joseph's talk at InfoQ Dev Summit Munich was a call to action for senior developers. The 95% failure rate is not acceptable. The tool sprawl is not sustainable. The answer is not more tools or more models; it is a new architectural layer. Agentic compute is that layer, and it is time for enterprises to build it.
The LMOS experience is a proof point. A team of five engineers built a platform that went live in 2023, is still running across multiple countries, and is now under the Eclipse Foundation. They did it by working with existing teams and stacks, by platformizing the hard parts, and by resisting the lure of tool sprawl. This is a repeatable formula, and it is the formula that Masaic is now productizing.
The heavy machinery example is the future. The system ingests IoT data, telemetry, SOPs, incidents, and frontline intelligence, and it produces actionable outcomes. It identifies that 73% of use cases are around air filter management, it flags the JP-100 seal kit failure, and it recommends stocking up. This is not a chatbot; it is an operational intelligence system that makes decisions and takes actions. This is the kind of system that will define the next decade of enterprise software.