エンタープライズ AI システム構築：アジェンティック・コンピューティングの欠落層

InfoQ Homepage

Presentations

Architecting AI Systems for the Messy Reality of Enterprises: Why Agentic Compute is the Missing Layer

View Presentation

Speed:

Download

48:52

/presentations/agentic-compute/en/slides/Aru-1785744199740.jpg)

まとめ

Arun Joseph shares real-world insights on scaling enterprise agentic platforms like Deutsche Telekom’s LMOS. He discusses bridging organizational fault lines, replacing tool sprawl with core platform abstractions, and moving beyond basic chatbots to operational intelligence systems through ephemeral agents and an Agent Definition Language (ADL).

Bio

Arun Joseph is co-founder & CEO of Masaic, a stealth startup building AGC, the Agentic Compute: a new computing substrate for knowledge work. AGC is open by design and built for scale, providing the architectural foundation for decisioning and actioning systems that integrate with existing enterprise stacks.

About the conference

InfoQ Dev Summit Munich software development conference focuses on the critical software challenges senior dev teams face today. Gain valuable real-world technical insights from 20+ senior software developers, connect with speakers and peers, and enjoy social events.

INFOQ EVENTS

• August 6th, 2026, 1 PM EDT

Building AI Agent Evals for High-Stakes Incident Response

Presented by: Brianne Bujnowski - Senior Product Marketing Manager, AI at Datadog, and Benjamin Barton - Senior Software Engineer at Datadog

• August 27th, 2026, 1 PM EDT

Below the Framework: Why Agent Context Is an Infrastructure Problem

Presented by: Boyd Stowe - Founding Solutions Architect at Tacnode

Transcript

Arun Joseph: My talk today is going to focus entirely on enterprises. There will be different definitions of agents. You might have heard about Cursors, Lovables, and autonomous agents that run for hours, but I'm going to ground it in the context of enterprises. That's why I call it agents for the rest of us in enterprises. Building anything greenfield is easy. If you want to, in enterprises, you already have the cars, you already have the trucks, you need to lift it up and then fly. This is the aura that AI actually brings in.

My name is Arun Joseph. I was here talking about our journey in my previous role as head of AI engineering for Deutsche Telekom. There was a program that we did, which we envisioned in 2023. We were one of the first agentic platforms to go live, potentially, as I know, in Europe or elsewhere, and that too in a large enterprise like Deutsche Telekom. I was leading that program. It was entirely built open source. It's called LMOS. It stands for Language Models Operating System. It's now moved under Eclipse Foundation and still running in Deutsche Telekom across multiple countries. Ever since, I have moved on. Last year's talk was so successful that I decided to quit my job and then start my own entrepreneurial journey, leaving a cushy job. This is what InfoQ talks can do to you. Right now, we are entirely focused on building multi-agent systems. One of the companies, a lot of things are under stealth. It's called Masaic. M-A-S stands for multi-agent systems by its nature. My previous background has always been building platforms across the world, including Europe, U.S., Canada. Distributed systems has been my mainstay in large enterprises.

Context

I'm going to talk a little bit about what we do as a company. We focus on operational intelligence systems. We build large-scale operational intelligence systems for critical infrastructure and large enterprises. We could say, a better Palantir is what we are actually looking at, with an open core. Essentially, all of this comes from the learning that we had building agentic systems. There is a need for a new class of systems, which we refer to as system of outcomes. We already know about systems of record, which is Salesforces and databases of the world. Then we have the data OS layers, which is the Palantirs and the dashboards of the world. You need a new class of systems, which sits on top of these systems, which focuses on outcomes, whether it's heavy machinery downtime, or running a city better, or for thriving of the industry in operations matters. Part of several foundations. I will focus entirely on enterprises.

Let's start with the myth bust on what actually works in enterprises, at least from the journey that I had. Then we will try to define an agent, because there are so many definitions. I wouldn't be theoretical, I would try to frame my mental model of an agent that we use even today, and the enterprise challenges. There are two magic bullets, which are going to solve everything in enterprises, which I'm going to give to you. Then we are going to level up the agent's journey. I'll show you some demos.

Myth Bust - Agents that Work

Agents that work in enterprises. Let's start with two categories of agents that work. A little bit of background on LMOS. It went live in 2023. This has since moved out of Deutsche Telekom. Some of these numbers are public numbers. I won't cite the numbers around agent handover, but it has been incredibly massive in terms of what we could do. There are three outcomes that was done. One was the business outcomes, which is obvious, without which there is no technical platform. It was an industry first, and it was tested against some of the best in the industry, vendor products, and it still outshone them. The best part was it showed how you can leverage existing investments and teams within an enterprise to build agentic systems right from scratch when agents wasn't a thing at all. The kind of systems that we do, so one category of systems that work is the chat modes and automation systems, which is where most of the enterprises are, but we are actually going into operational intelligence systems.

I'll show you a glimpse of a couple of agents, what we refer to as agents. The core of our operational intelligence platforms is also multi-agent systems. I'll use the heavy machinery operations as an example to talk about the agents that we refer to as agents in the level 2 of agents. One of our core products is called Atlas, but I won't go into the details. Let's take a heavy machinery operations company, it could be Hitachi, John Deere, SENNEBOGEN, whatever it is. Essentially you want to reduce the downtime of machines, because the downtime of machines is costly. How do you ingest all the data that you have about the machine? For example, you have IoT data, telemetry data, SOPs, all the incidents, the frontline intelligence, which is where most of the intelligence lies. How do you ingest all of that into a system, let's call it the magical system, so that a service operations manager can ask, we have seen a spike in error codes of this one in Midwest, what can we do about it?

Do you know anything about it? This is the system experience of what it would be. It needs to drill down, crunching numbers. It needs to be accurate, and come up with suggestions like this. "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." Maybe there are better ways that we can deal with it. Decisions, it's actually a decisioning system. At this point, the large operational intelligence scheme can decide what to happen, what can be done with it. Then, it should actually go into the next step, which is, let's do the automation of this, potentially. What can we do about this? Maybe when this error happens, this is the SOP that needs to be followed, which has human in the loop, then raise these tickets, but also send this telemetry data to some other systems.

Which results in a dynamic construction of an SOP, which is not just textual, it is a mix of agentic actions, plus documents, plus a process that needs to be followed with human in the loop, which is sent to humans for approval and for testing. This is a second class of agentic systems, which is not really the chatbots and the typical enterprise agentic systems.

My talk is going to focus on this class of systems, and in the end, it's going to show, here are the ways in which you can reduce your machine downtime. Look at this. These two parts have been failing consistently in this region for the last one month. Here are the next actions that you can take. JP-100, or seal kit across these warehouses, stock it up. Maybe there is a need in the next couple of months. How do you build such a system? This is what we are going to talk about. Here, while building that system, as you would see, essentially, when you ask such a question, what actually happens underneath this? It's going to spin out multiple research tasks, and each of these tasks are ephemeral agents. This is not like agents somebody has created with X and Y framework. This will not work, because how many agents will you create?

You need an ability to create ephemeral agents. Then it actually runs and says, find the most frequent mode, so the multi-agent execution in parallel. Then in the top, you will have a multi-agent synthesis, which arrives at the outcomes. This is a true agentic system, as we envision it to be, which is what we are building. We're going to talk about these two classes of agentic systems.

What is an Agent?

What is an agent? Let's start with the level 1 agent, which is mostly used in enterprises for chatbots, automations. This is the definition that I use for an agent as a programming paradigm. You have programming paradigms like functional programming, object-oriented programming. My definition of agent here is not from the perspective of what an agent is from a theoretical sense, but from a programming paradigm sense. What is a program? A program has input. It does some transformation or computation, then it produces the output. I would define agent as a program, the level 1 agent as a program, which at least has one characteristic. It expands the breadth of inputs that it can take, and it expands the adaptiveness of the computation. It is still abstract. Let me show you two examples. This is, for example, from one of the agent frameworks that we built from LMOS.

This is a screenshot. "Hey, find me the best hotel in the location with the warmest weather between three cities, and book it for me." Imagine if you are a traditional enterprise with a booking system, for example, that you built. For any request that comes in, a product manager would come in and say, "I need this new button there," which when you click, it should book the best hotel for the warmest city. This is a requirement somebody would write. Then people would go and write this logic for orchestration in BFF or wherever it is. As you can see, what is going on is, in this case, the orchestration of the functions, get weather, list hotels, and then combining it to produce a result allowed a fluidic computation. Nobody went into BFF and started to write and clubbing these things. Neither did the product project team start to write a button and start to implement it.

What does it actually help in enterprises? I see in enterprises, the primary place to go after is not really large-scale Godmode agents. This is a good place to start, because essentially it allows a breadth of inputs to come in. You would have worked in enterprises. Any change in a schema of an API is a change request, goes to Jira and the huddle, the scrum and whatnot and all the ceremonies. Now you have an ability to have it really in a fluidic manner. It allows you to build better bots, chatbots for customers is obvious. It also opens up a huge potential for automations. I have seen in large enterprises, bot farms. Bot farms were previously built with Camunda's of the world, for example. You would have a large workflow orchestration engine. There would be a team who would write, every day run this bot to look into these tickets, extract the reason or something like that, and then trigger this workflow to cancel it or something. Every time you need a workflow, you need to rely on the Camunda engineer or somebody else. There's a huge pileup of such automations which can immediately be automated like this. This is the actual value it brings in enterprises. Definition one, which we will revisit at some point.

The Enterprise Challenges

There's this number, 95%, a famous number, MIT study or whatever. Why is the 95% failing if it's as simple as this? This is a level 1 agent. It's just orchestration of existing functions. You don't need to do a Cursor magic. I would start to give two major reasons which I personally understood. Then I will go into the magic bullets. The first point is crossing many fault lines in an enterprise. The definition of fault lines, I need to talk about it. What is a fault line in an enterprise? It's not greenfield. All of enterprise work can be summarized into just four work packages. Take the booking system in a company, if somebody had built something like that. It only has four functions, ideally. You need to store data, storage layer. Then you have the transformation layer, presentation layer, and the transmission which crosses a boundary, which is either event sourcing or API call.

Then it goes into somebody else. Microservices, whatever. It doesn't matter. This is an enterprise. Of course, security and the rest of the things in there. You can summarize all of enterprise work units as this. What is an actual enterprise? You would have seen the famous Josh Evans microservices presentation where a request comes in in Netflix, it spins into multiple nodes. In an enterprise, you have many teams and you need to coordinate. Each API might be a different team. There are these fault lines between each of these APIs. This is a whole thing to first understand. Within a team, you have multiple people, which are systems and roles, product managers, DevOps engineers. There are all the fault lines in there. My hypothesis is if you start with an agentic system, let's talk about the product ordering API in a real enterprise. This is taken from TM Forum, which is a telco specification of APIs.

An enterprise API is not as simple as, this is the booking API, which is API first and the first-class OpenAPI spec or something. It's messy. No one even understands what these attributes are. There will be one or two people within that fault line who would understand this API. If you say I want to build an agent which helps in product ordering, there are two approaches to do it. You build a fancy new team who has no idea what these things are. They talk about latest research papers. They talk about the latest research tools. Starts to pick the latest framework and start to build a prototype, just like the booking thing. "I want to do the product ordering. Can you show me the API?" Nobody understands anything, for example. The fault line thing, most of the enterprise AI programs, which at least I'm consulting or reaching out to, and I've seen this personally, if it starts to detach from the actual problem you're solving, you're dead.

Essentially, you will wait for APIs. You will wait for people. There is no way you will be able to even iterate on even business people. The frontline people who are handling the calls from the customer, they know better than any of these engineers what the requirements of product ordering would be from the usual customer. If you start to build only a technical team with whatever technical skills, it's not going to work. That's the reason why I use this picture from Cole to build this airplane. Essentially, it's not like a fancy new aircraft that you're building. You're not bringing aeronautical engineers. You need to think about the existing cars and the trucks and everything, and try to build a team around it.

Enough with the generic stuff, but this is super critical to understand the first part, without which I cannot go into the technical second part. Then there is a lot of noise. Current AI programming model poses a challenge to software engineering. What do I mean by that? I'm going to show you some advanced agentic patterns. Take it in a light sense. It's a pun. Have you ever thought of a line of code in a program, translates into multiple containers? I'm going to show you the magic there. This is a pun. This is a typical program, how it might look like these days, with most of the agentic framework approaches that you take. You want to build an agent that just simply thinks, what should I do? There is a think function. I have seen in enterprises, you bring in multiple tools from multiple burgeoning startups. For example, an eval startup will come up with an SDK.

A telemetry startup will come with their SDK. A memory startup will come with their SDK. You buy all of this. In a new company, this is fine. You are using their cloud service. In an enterprise, no one would use the cloud service. I think Guido van Rossum is going to jump out of the window if he realized that the decorators were used as line of code execution, which is remote code execution. What is exactly happening, for example, in enterprises, with all the noise around their programming models? I've seen this personally in some places. Each of these costs license costs. This is only referring to the license costs for eval tools, for example, potentially. In a large enterprise, 100k is nothing. You can get around with it. This line of code is now five containers. You need to have your operations team to come up with the UI, the database, and the memory structure, and the API, and custom Kubernetes operators.

This is how it actually works. I've seen something with 25 containers. I've personally seen this. I still remember the face of one of the DevOps engineers after the procurement or something was done in one of the consulting engagements. They said, we are going to bring in a brand-new great evaluation tool, which is going to fix everything. They bring this in. This was the face. Some of you must have seen the movie, 300. It's like, this is vendor containers for line of code. Now the DevOps team is not able to support this, or they don't even know how to set these things up. Then suddenly you have new fault lines. I talked about fault lines, which I will get to as well. This is one of the major reasons, the noise around tooling. The tooling sprawl and the existing teams are not able to either support or understand what are the actual paradigms required.

There has been this new release of the agentic workflow builder from OpenAI. This is beautiful, AgentKit. Then suddenly says OpenAI just killed everything. The fun fact is, look at this. This is the Raft consensus algorithm, which is based on which even Kubernetes runs. Somebody might look at it, and this is how people start to think. If it's a workflow, it can be done agentically. You start to say, Raft consensus, which is around leader election if one of the distributed systems goes down. You look at it and say, this looks like something I can build with agentic workflows. I don't even have to explain. If you have to explain why this is wrong, then you realize that there's a problem with whatever that you're trying to build. Like I mentioned, the biggest problem is the fault lines, as I described. Now you have a simple agent about product ordering API.

I want to build an agent, which does one thing. It helps the customer in purchasing something. You speak to the product API team, and then they say you need to talk to the profile API team, then you need to talk to the ordering team. Now you also have to talk to the 50 container managing DevOps people, and also to the vendor and the vendor documents to even come up with the first Hello World product agent. This is sadly the status in most places.

Two Magic Bullets

Magic bullet. Why LMOS worked in Deutsche Telekom, in my previous program. In 2023, no one was talking about agents, at least as far as we didn't know. We had a small, brilliant group of five people, all distributed systems engineers. At that point in time, there was only LangChain, as I believe. What we did was we chose their stack, which was the greatest in the world. This is the reveal moment. That stack is this. We chose the stack which works with existing engineers. All the product, all the APIs which were in Deutsche Telekom at that point in time was in Java, JVM. They had hundreds of client libraries built on how to invoke these APIs. The entire observability stack had a lot of libraries also supporting the JVM ecosystem. Then they also had the know-how on how to actually get a single product from a product API.

There are only very few people who would know this. Nothing against Python or Rust or whatever, we did this. We started our first program with LangChain. It was a disaster. I personally have my thing with LangChain. The abstractions, it's great. We came up with our own framework, which is also open source, which is based on Kotlin. What we did was, existing engineer, we were attaching all the libraries which were already there in the enterprise as dependencies to this one, which allowed a product API team member and engineer to immediately test it. We took away all the hard parts into the library that we built, it's called ARC. I'll give you references and even last year's talk, but this is for the existing engineers. Then the DevOps team. This is the observability, telemetry, the amount of observability noise plus some really value-added things which has gone in the AI industry is crazy.

A single API call to an LLM will generate a lot of tokens, tool calls. Now you need a specialized system to understand the stack. This doesn't make any sense, because you already had the SigNoz's, the Grafana's, and Prometheus, and the tracing. We started not with any fancy tracing tool. We plugged our own telemetry directly into existing systems. The operations team said, this is something we can manage. Please don't come to us with more containers. This allowed them to be onboarded into the journey. This is our stack. This is the LMOS stack. We had the LMOS ARC, which is the Agent ReaCtor. Then we had the LMOS agent platform, which is also a custom Kubernetes container, but packed with all the things that work really well for us. The business part, this is where things will start to get really interesting as I go along with it.

This is a Kotlin framework, which we'll skip right now. The business, what AI brings in, the true power in enterprises, and also for agentic systems. Let me show you. Let's go back to the previous example. If you want to build the booking agent. Previously, if you had a button, some of the business or whatever you call as a business would go and write a requirement. Put a button in there in a Jira ticket. I'm going to assign it to you. How do you define the requirements for an agentic program? Which in this case is a chatbot. This was real. The idea is, let's write stories. No one knew, or at least back in time, how to write these requirements. Essentially, the loop that I showed, you need to compress that loop. That's the only way you can get anything out. The loop between engineers, DevOps, and business. Then when we started to build this, the engineers were able to connect the APIs. The DevOps was able to handle the load. Then the requirements started to get a problem, because every time there is an anomaly in the chatbot, there is a new ticket getting assigned. This cannot work. This will not work.

We came up with a layer which we call ADL, which is the Agent Definition Language. There are also some screenshots. This was logic for the rest of us. First of all, you cannot expect people to simply write a prompt and make it work in production when you are facing a customer service bot or something critical. Most of the Hello World examples that you see will not work. Let's say you are the Volkswagen team, and then you wanted to build a bot for your service team. You would need to define your SOPs. This is a screenshot, again, from the open-source ADL programming environment we built. It's a simple Spring Boot container. You spin it up. It comes with the UI. It allows for quick iterations. The key here is it shows a way the business can start to write the requirements in a specific format which we started to control, so that the translation between Jira and business and all was compressed.

The engineers would actually wire the APIs. The business would use this environment to start writing what we refer to as agent use cases in a format that we prescribed. They are able to iterate really fast in there. There's also a simple example. This is our ADL environment. It's a simple Spring Boot container. It shows the events and the tools, just enough for the business people. This is not for, let's just say, a DSPy alternative or something, prompt compression and things like that. This is for the business. For example, here it says, my Golf broke down, I want to book it. Then the business user is able to immediately see, it actually is able to pick the right use case in this case. Then I asked for the agent handover, it picked the right use case. It provides a mental model for business to actually draft, just like programmers, all the things that we learned about from programming was compressed to this.

ADL, we are not sending the data or the use cases as it is to the LLM. This is the magic. We have a compiler which compiles into system prompts, which compresses it. It's like tree shaking and things like that in programming that we're actually using. There's a lot to talk about it, but here at the top, I'll give you the broad picture. Magic bullet number one, build agents with existing teams and stacks. OpenAI has not killed software engineering yet.

Magic bullet number two. I talked about the first class of AI systems that we built and all the learnings. The second class was the operational intelligence system, which we started to build, which I showed as heavy machinery operations. Platformize the hard parts and get out of the way. What is a platform in the agentic system today? This is what we will talk about from a real experience. AI infrastructure today is a brittle set of things. There are hundreds of things. If you want to build a simple agent in the heavy machinery operations, for example, I want to analyze the tickets which were coming for machine X, Y, Z. I will build an agent. Most of the time I will be doing the plumbing, observability, guardrails, evals, model integration, and only 5% of the time in actually writing the agent logic. Revisiting the example that I said, if we started to do that, for the large-scale agentic system that we are building.

When we started, I think we were around 50 or 60 agents for the heavy machinery operations in our new company. This wasn't going to scale anyway. I'll give you an example of how we actually went about with the platform path, and probably show you some examples. The previous example, this is how we started. We started with multiple agents being built, and then we moved down the hard parts into a layer. What are those hard parts? Session management, context management. How do you do telemetry fan-out? Like I said, you do not want to transport the telemetry only to the evaluation tool, you need to transport it also to your observability stack and elsewhere. You cannot have that plumbing done in here, this is one of the hardest parts that you can do. Plus, in the operational intelligence platform, if the ability to switch a model is going to be hard, this is not going to scale, because the cost won't add up.

For example, if you start to run a million invocations, the cost amortization will not work, so you need to shift from the larger models to smaller models with ease. We started building how you do that into the hard part of the thing. MCP thing, I would rather say, because MCP is still evolving, but I'll show you a few things, and the vector DBs and things. We started to move down into this platform layer, which shrunk the agent sizes, let's just put it this way. This was the first optimization that we did. Then, we started revisiting. After building more than 50 or 100 agents, Amant, who's my co-founder, we call him the Agent Whisperer, or the Ontology Oracle, he started spotting something supremely interesting with the programming paradigm required to build agents. The first agent that I showed you, the fluid input versus comma output, we're going to revisit that definition into something more generic, from a programming paradigm perspective.

We came down to, an agent is simply a loop, which takes in a goal, which has context, and then it accepts constraints, and it executes tools. These tools could construct additional tools. Then, this is exactly how you build Cursors or Lovables. There is nothing magical in there. If you're able to construct this loop, you can build anything. As I mentioned, the simple construct, this is a programming paradigm, this is not a Python code or whatever. You need to see it as a programming paradigm, as I would rather call it. While the goal is not achieved, you start to iterate, and then you start to refine the goal. At some point, you loop back to the human in the loop.

You remember, we started to shrink it. Then we brought the agent loop primitive into the platform and exposed this as a single API. Much like S3 exposed an API, or Stripe exposed an API, or EC2 exposed as an API. Then, what happened? All those agents actually shrunk into ephemeral agents. Nobody is sitting there, I need a fault analysis agent. I need this testing agent or a root cause analysis agent. It's based on the goal. The service manager says, I would like to know what are the major reasons why these machines are cracking. If you have arranged the domain well, if you have figured out this programming paradigm well, it is able to plan, and the planning goes into multiple loops, and the loops by itself constructs the tools or queries and starts to synthesize it. This is what we actually perfected. The best part is, the framework, juggernaut.

Is it a framework? It's exposed as a single API which works with any OpenAI client, which brings in the point that it is frameworkless. Now because it's an OpenAI client, you can get one line of code which works with OpenAI, you can use in any framework. You don't have to write all that agent logic in most cases. All the hard parts are taken care of underneath, including plumbing, model switching, tool call, remote tool execution, you name it. Which brings us to the paradigm, compute as the agent. What if we expose the compute itself as the agent-making machine? Then you can build your own Cursors. You can build your own enterprise Cursors for whatever that you need on your business systems. This is the reason why we say AgC. We call it AgC, that platform. It's called Agentic Compute. AgC, it's exposed compute as an agent.

When I say this to what is compute as an agent, most people don't get it. I took the liberty to use this talk to explain why we say compute as the agent. It's exposed as one Docker Compose, developers can test it. One Helm chart, anybody can deploy it as fully Apache 2.0 license. Your business teams or engineers can build agents with your existing stacks or the favorite frameworks, for example.

Demos

Let me actually show you some of the demos. First, I talked about ADL. I wanted to just give you a preview of the ADL approach. It's nothing but a Spring Boot container, as you can see here. We'll go step-by-step around the demos. Demo number one was around the first magic bullet, how did we enable our existing teams? We built a framework, which is Kotlin-based, and engineers would go and just build Kotlin files, which is Kotlin scripts. Then they would also go in to write functions. The idea is if you attach your libraries, you can directly plug in your product booking API or whatever client you attach, and you can invoke. There is no MCP, there is no nothing at this point, because we didn't need it at that point in time. This is the framework that we built. It's called ARC. It's open source. Around ADL, I wanted to show, once that Spring Boot application is up, this is how you would see it.

It would run on your localhost. This provides a quick testing environment for your agents. What kind of agents? Again, of course, it can be used for the second class of agents as well. The same use case that I showed, every agent that you build will appear here, and a business would go, and business ADLs transfer money. I was just about to show how somebody might think about two-phase commit, written as a prompt. This won't work. For example, the Volkswagen example, somebody would go and write the business use case as a business person. It has three constructs to remember. The constructs don't matter, but what matters is the thinking. You write the solution, you write the alternate solution, fallback. The business person would also say, if the date, for example, is not available, go to this use case. There is something called, for example, date not available.

How do you construct graph trees, actually, in an SOP? There is a construct that we came up with. Go to use case, offer alternative, and the business would start to write that particular use case, and immediately go and test it in the chat. Maybe I will say, my Volkswagen broke down, need an appointment. It should actually pick one of the use cases and respond, and then the business person knows, it actually picked the right use case, even though I had many other use cases. You work only on that small use case. You can attach tools in ADL.

Now I want to shift into the platform which was built, and what is this construct of compute as an agent? Let me shift to AgC. Let's talk about a proper business use case. In a typical enterprise, you would have several information systems. Let's talk about a telco, for example. A telco would have pricing engines for the offerings that they have, especially for B2B. Especially for B2B, they would have templates for how the business formats, the proposal formats need to be. You've even simulated a communications MCP, for example, the communications server, the transcripts between calls, and several other business systems. My goal is, I want to build an agent which allows a salesperson in a B2B organization, in a telco or home server, help make better sales. What would that experience be like? For example, if I take the time to write, let's just say I come into this system.

This is AgC, after the docker compose up, this is what it brings up. It has a basic UI. It's Docker Compose, you can use it anywhere. If I just say, I just finished a call with Nordstern Mobility, help me draft a proposal. So far, I haven't done anything in LangChain, or LangGraph, or CrewAI, or anything. I just attached the tools, which is necessary, and returned the instructions actually for this one. Here it starts to look into the brand templates, and actually prepares the template. Then, let's pull in the pricing as well. In this case, we have also attached the B2B pricing as well. What is important to notice here is it has not actually done anything other than pulling the information. There is no other wiring which was done, and it actually does it. Let's say I have a weird requirement that I come up with.

There is a website called Allbirds. It's a Shopify. It sells shoes or something, Allbirds. Allbirds.com, and Shopify has an MCP. It has shoes and things like that. Let's say if I have a weird requirement, which says, I want to add a shoe to my business proposal? I can write a Jira ticket. I can tell my smart LangChain, LangGraph, CrewAI, hundreds of other things to do it, or I attach it to AgC, because like I said, the programming construct is a goal and the loop. Let's say, I've added it here, Allbirds MCP, for example. Just added the MCP. I have done no coding here. Let's add a shoe, a black sole, and size 9 to the proposal. Let's see. It started to pull in the MCP tools directly into your agent. You did not write any code. The compute was the agent. It started to pull in the shoe, and when you click on it, it actually goes into your Allbirds. It's not staged, is what I wanted to mention.

What is the possibility? There's also another thing. All of this, the hard part is model switching, for example. You can add any model. I'm not referring to the UI. First of all, this is not meant for UI people. This is what you use to build your platform. It's primarily written in Kotlin. You can go and attach your models. You can simply switch the models from the backend with one line of code, and then run it again. You would be able to even get a first-hand experience whether it actually works. Now you have constructed an agent with only instructions, like I said, that programming construct. There is one line of code, which is OpenAI's client SDK format, or it's a simple call, and then you attach it to any program, and you have an agent. There is no magic that you need to do. What about observability, the hard parts?

For example, here, it supports OTel, plus also prompts fan-out. In the backend, you can simply configure at your collector, I want to fan out this telemetry to Langfuse, to RIs, to signals, wherever you want it to be. This is what you want. It's not your application developer's responsibility, neither it should run in your micro-agent service or whatever it is that you would want. As you can see, immediately, all the telemetry is available in any platform that you choose. The platform takes care of the hardwired parts.

One of the other things that I wanted to show you was also these ephemeral agents. I wanted to show one last demo. Essentially, remote call execution. This is RPC. You are able to attach your tools. Essentially, if you are working with agents, there are two ways to attach tools to it. The tools execution is something you have to manage. Here, this is an example. I built an agent which runs a local tool, which actually goes into a browser and updates Salesforce. Salesforce often asks for OTP and two-factor and blocks me. Maybe it might not work, but I want to show you, "I just finished my call with Volkswagen. Update Salesforce opportunities." It actually gets a call transcript from my call transcript server, and there is something called Atom. This happens locally. What did I do? What would have happened? This is localhost. Where was the platform running?

I attached a tool running on my local machine. There is no MCP magic or something. We just did the wiring. This is a long-running execution. I just finished my call, and I said, this is how you update sales. I just finished the call. Go and update Salesforce. I hate the guts of the user interface. This actually should have run.

Takeaways

I would just summarize the key parts, which is the key takeaways. There's a lot more. In enterprises, start with level 1. It also offers a large amount of ground to cover if you are able to think only in this term, input fluidity of programs and orchestration fluidity. How to make it work? Bet on current stacks and teams. Engineering is not going away, otherwise, it won't work. Use the example of the fault lines. ADL, this is a new paradigm. This was not there before. I don't think business needs more user interfaces. Business needs a way to write the requirements, which directly translates into the program, and not more UI. Platformize the hard parts, because it's a snake oil industry. There's something going on. Computing a new paradigm for agents, which is a function loop, which we discussed.

See more presentations with transcripts

Recorded at:

Aug 03, 2026

by

• Arun Joseph

AI Engineering Lead @Deutsche Telekom