Pod Insights Software Engineering Daily Agentic Mesh with Eric Broda About this episode AI agents are evolving from individual productivity tools into distributed systems components inside enterprises. The next frontier is coming into focus, and it involves large-scale ecosystems of collaborating agents embedded directly into business processes. However, multi-agent architectures introduce serious challenges around orchestration, state management, trust, governance, and observability.
Eric Broda https://x.com/ericmbroda is a veteran of the software industry, and he’s the co-author of the new O’Reilly book, Agentic Mesh: The GenAI-Powered Autonomous Agent Ecosystem.
In this episode, Eric joins Sean Falconer to discuss the architectural challenges of deploying agents as core infrastructure, how distributed computing principles apply to multi-agent systems, why trust and explainability are foundational, and what enterprises may look like as agents become full participants in business processes.
https://i0.wp.com/softwareengineeringdaily.com/wp-content/uploads/2023/10/Rectangle-3-2.pngSean’s been an academic, startup founder, and Googler. He has published works covering a wide range of topics from AI to quantum computing. Currently, Sean is an AI Entrepreneur in Residence at Confluent where he works on AI strategy and thought leadership. You can connect with Sean on LinkedIn.
Please click here to see the transcript of this episode. http://softwareengineeringdaily.com/wp-content/uploads/2026/03/SED1917-Agentic-Mesh-2.txt
Sponsorship inquiries: [email protected] https://cms.megaphone.fm/organizations/619b680e-d813-11ea-9750-e7ecac406436/podcasts/e60108fe-e328-11ea-b2b6-1348249f900a/episodes/3913370a-bc44-11ed-ace6-8b1f96d82bba/[email protected]
The post Agentic Mesh with Eric Broda https://softwareengineeringdaily.com/podcasts/agentic-mesh-with-eric-broda/ appeared first on Software Engineering Daily https://softwareengineeringdaily.com.
Transcript 0:00 Speaker 00 AI agents are evolving from individual productivity tools into distributed systems components inside enterprises. The next frontier is coming into focus, and it involves large-scale ecosystems of collaborating agents embedded directly into business processes. However, multi-agent architectures introduce serious challenges around orchestration, state management, trust, governance, and observability. Eric Broda is a veteran of the software industry, and he's the co-author of the new O'Reilly book, "Agentic Mesh: The Gen AI-Powered Autonomous Agent Ecosystem." In this episode, Eric joins Sean Falconer to discuss the architectural challenges of
0:43 Speaker 00 deploying agents as core infrastructure, how distributed computing principles apply to multi-agent systems, why trust and explainability are foundational, and what enterprises may look like as agents become full participants in business processes. This episode is hosted by Sean Falconer. Check the show notes for more information on Sean's work and where to find him.
1:19 Speaker 01 Eric, welcome to the show.
1:20 Speaker 02 Well, Sean's great to be here. Thanks for having me.
1:23 Speaker 01 Yeah, thanks so much for being here. So I want to start off, you wrote a great book, "Agentic Mesh: The Gen AI-Powered Autonomous Agent Ecosystem."
1:32 Speaker 02 Now, you mentioned me as the author. I'm just going to point out a very quick thing here. I had the pleasure of actually writing this book with my son. So this is a father-son team. Davis Broda and Eric Broda were the authors, and we're absolutely pleased that it's coming out in the first week in March.
1:49 Speaker 01 Oh, that's amazing. Yeah, sorry for missing that. I knew that you co-authored it with another Broda, but I wasn't sure, I didn't realize it was your son. That's great. I've actually been lately, one of my fun things I've been doing with my son, who's only five, so it would be incredible if we wrote a book together, but I've been taking his ideas and using Claude code to implement games based on his ideas that he then gets to play. So lots of things coming, father-sons working together, agents, it's all coming together now.
2:17 Speaker 02 Well, it's kind of funny you mention that because I think the times, as they say, as Bob Dylan said, the times they are a change and the speed of change is incredible. Whether it's Codex, Claude Code with your son, we're using them obviously on a daily basis. The things are changing so rapidly that this is truly exciting times and I think the book is perhaps at the right place at the right time right now.
2:41 Speaker 01 Yeah, well, I'm kind of curious about why, why a book, you know, given that things are changing so fast, like literally the entire like developer experience has shifted in the last like two to four months alone. So is it old news by the time something like a book comes out?
2:54 Speaker 02 Yeah, well, that's a great question. It's kind of funny because I was talking, I was on a podcast with Joe Rice, Reese, I can't remember.
3:01 Speaker 01 Joe Reese.
3:02 Speaker 02 About a year, yeah, George, about a year ago. And the interesting thing about it, we were talking about how I was writing the book. And this will be the second book, actually. And we commiserated a bit and ultimately, I said, I'm not putting any code in this book because the moment you put code in the book, you are dated literally the day before you publish, but the date you publish, you have old stuff. So what we try to do in this book is focus on the concepts, the architecture, the higher level design principles. So this would hopefully, we're hoping it's, it's, it's going to be a timeless effort, if you will.
3:34 Speaker 01 Right. So we talked a little bit about how, you know, things are changing so fast in this world. And I think we really got into a place where, especially with agentic engineering, it's really like anybody could kind of build an agent these days to do something with a little bit of prompting. I don't even know, I haven't tried this, but even somebody who's maybe not in like deeply technical could probably pull something off with some prompting. So what is sort of the gap separation though between that and getting something into production, getting something in an enterprise? Like, why is it that enterprises keep failing to do this and the failure rate is so high?
4:10 Speaker 02 Yeah, sure. The thing that we hear from our clients is they are having great difficulty getting out of the lab and into production. And the challenge they find time and time again, there's probably a confluence of events here that cause them difficulty, but fundamentally, what they have is the lack of enterprise-grade capability. So they're missing things like security, they're missing discovery, observability, traceability, operability, explainability. All of these things are capabilities that, to be honest with you, are in every single enterprise application today. And the expectation is that if you want to build an agent and you want to have it do real work, productive work, it has to meet the same criteria.
4:55 Speaker 02 The problem is, is despite the best efforts of the folks who are writing the agent, more often than not, they're folks that are new perhaps to the game, they're doing some proof of concepts, or we have some very senior data scientists who may have outstanding capabilities, most of the data scientists I've met are geniuses, but they don't have the understanding of the enterprise-grade requirements to get something into production. So there's this fundamental mismatch that we see. I think that's probably the first thing that we see. The second thing, and this is a broader narrative that we have in the book, it's not about building an agent per se, although that's very useful, and that obviously is a precondition to building, you know, an agent ecosystem, but the fundamental question is, how do I
5:40 Speaker 02 manage these agents? If you recognize Jensen Huang or Andy Jassy, Satya Nadella, all of them have sent some version of the following phrase, they've said that we're going to have hundreds of thousands, if not millions, of agents in every single enterprise. Well, what that says is we have a problem of scale. We have a problem that ultimately turns into a distributed computing challenge. We have the challenges that are quite commonplace to ecosystems. I know you, you obviously are very familiar with Kafka. Kafka lives in that ecosystem. It is built to support vast ecosystems.
6:21 Speaker 02 Like I said, if we're going to have thousands or millions of these agents running around in an enterprise, we need to have enterprise-grade capability that recognizes challenges of distributed computing, the challenges of scale, and be able to design and architect those into the agents that we build. This is really a question about how do I design the ecosystem rather than how I design the agents, Sean?
6:42 Speaker 01 When it comes to this, you mentioned these enterprise features that every sort of enterprise piece of software has. And then you also have sort of distributed system challenge of like managing and orchestrating agents at scale. We're probably a little ways away from enterprises having hundreds of thousands of agents, but with the speed of things going, it might not be that far. How much of this do you feel is like traditional software engineering challenges versus something that's like a net new challenge?
7:11 Speaker 02 Well, I would say I come from an enterprise computing background for the most part. Back in the day, we built APIs and we had a service mesh. We had data products in the data mesh. Now we have agents and an agentic mesh, as we call it. The problems are roughly the same. So if you've been in the enterprise space for a while, if you want to get past the chief security officer and into production, you have to talk about security, you have to talk about trust in all the capabilities around that. If you want to get past the head of operations, you have to talk about how this capability will be observable and traceable and how it fits into my operations infrastructure. If you haven't got that figured out, you're not going to get past the operations check.
7:56 Speaker 02 And of course, there's an enterprise architecture check that says fundamentally, am I building this in a sound fashion? Am I using appropriate distributed computing principles? Have I designed for scale? But the last and probably I would argue maybe the hardest one is this notion around trust. How do I actually engender trust to these agents? These agents will be doing effectively, although you know, the analogy here may break down, but I'm going to compare an agent to a person. A person does work in a business process. We actually see agentic process automation, if you will, where agents are participating.
8:30 Speaker 02 In the business process, if that in fact is the case, just like a person, we trust that person in the bank branch or in the back office that's going to open up a bank account or do an identity verification properly. And if they don't do it properly, there's obviously some significant implications, whether it's brand implications or just customers dissatisfaction implications. If an agent is going to do some of that work, we have to think really, really hard about how we're going to set up a trust framework. So that we can actually trust the agents as well as we can trust the employees. And we think there's actually a pretty significant opportunity to leverage some of the practices, HR practices, to be honest with you.
9:10 Speaker 02 Leverage those into the agent ecosystem and come up with agent resource practices instead of human resource practice. So that's some of the things we're thinking about and talking with some of our clients right now.
9:22 Speaker 01 And there's no shortage of various like agent frameworks that are out there that people are, you know, building some of these experiences on like. Organizations that maybe are investing in those technologies, like, how do you close the gap on being able to use those things to getting something that's more in the vision of what you're talking about? Or do you need to not leverage those tools and go somewhere else to get this kind of work done?
9:43 Speaker 02 Sure, it depends where you're starting it. So first off, anything I'm saying here, I'm trying very hard not to disparage the great work that's been done with some of the agent frameworks. But fundamentally, if you're using some of the frameworks that are available today, and I don't have to name them, they're, they're pretty commonplace. But what you're building is something that is specific to, you know, it works on your workstation or your, your laptop, your Mac mini or whatever the case may be. But it works, it is a, an agent that functions for you as an individual. And I think if you want to get to the point where this actually moves into the enterprise, you have to think about how this will function in a broader sense. How will these agents actually talk to each other?
10:26 Speaker 02 And I think that's the fundamental difference between where we are today. So, so I, you know, without going too deep into a digression. Ultimately, what we have is toolkits that will let me build individual components of the ecosystem.
10:40 Speaker 02 What you need to think about is not only that, but how do I build the components that surround each individual agent? So that they can actually participate in the ecosystem. So a simple example is if I'm building an agent using one of the toolkits and I have my Python program. And I have my agents inside the Python program and I spin it up, I'm effectively running something in a process on my workstation or whatever. That's not going to get you into production, but ultimately if I want to actually decompose that and have that scalable across the enterprise. I actually have to start to think about distributed computing capabilities. So here's the difference is if I'm building agents without the end in mind, if I'm not thinking about where I want to go in the destination.
11:24 Speaker 02 Then I'm going to build agents that are not able to communicate with each other. They are not able to manage long running conversations. They do not have state management. But if I design those into the architecture, which is fundamental to our book, the proposition we have in the book. If we design those into the architecture, then what ends up happening is the agents out of the box can not only do what they do. But they can actually collaborate and they can safely interact and they can safely even transact potentially with other agents. That's the step that I think today is missing. Now, there's a bunch of really cool activities, you know, innovations going on. We see OpenClaw, for example, but again, the design pattern is I'm focusing on what an individual can do.
12:08 Speaker 02 As opposed to thinking about how it fits into a broader ecosystem. Now, by the time some folks are listening to this a few months from now, maybe that has changed. But today, what we have is agents that are designed perfectly well for individual productivity improvements, whether you're a software developer or otherwise. But the future that we see, again, if you're talking about thousands or hundreds of thousands or millions of agents. We're talking about distributed computing, which fundamentally is not about what the individual agent does. But how does it interact and collaborate across an ecosystem? That's the fundamental gap that we found when we wrote the book and in all the discussions that we've had with our clients. That is still the fundamental gap that exists out there today, Sean.
12:50 Speaker 01 So you talked a lot about this problem around communication between these agents that are presumably probably living in different nodes and different environments. How do these things communicate? Well, I guess like, where does protocols like A to A fit into this? Is that a potential solution? Or is it fundamentally, you know, missing pieces in order to do this at the scale that you're talking about?
13:14 Speaker 02 Yeah, so we strongly believe that things like MCP, Model Context Protocol from Anthropic now, I think with the Linux Foundation, A to A, Agent Agent Protocol out of Google, I think if I'm not mistaken, it's also in the Linux Foundation. These are, I believe they're fundamental improvements in terms of how agents are going to collaborate. They're not the end destination necessarily. So as a simple example, you look at what OpenClaw did recently and they have extensions to it. And it communicates using different technology, different capabilities than A to A or MCP. Yes, MCP is embedded in there, so. So I think the thing is the state of the nation is evolving rather rapidly.
13:56 Speaker 02 But fundamentally, the principles behind A to A, the principles behind MCP are foundational. We're going to start to see these evolve. I mean, MCP is gone where they had some security challenges and now they're starting to address those. They recognize those and they've improved it. And what we have now is an MCP capability that's actually quite powerful. A to A is going to go the same way. What we see is some very early stage capabilities, but A to A is maturing and we start to see some frameworks that are coming out that do justice to it. Again, notwithstanding the fact that there's innovations that are going, these are fundamental ideas that we believe strongly that they have some legs and they're actually going to go be implemented.
14:37 Speaker 02 Now, here's the one thing I would say, and there's a fundamental substrate behind each of these. One is, if you read through the A to A SPAC or MCP, it's based off of this notion of distributed computing, microservices, if you will, and microservices that in our implementation, we suggest these microservices have the, obviously the A to A or the MCP capability, but they're Packaged as Docker containers, which means they can run in Kubernetes or in any cloud infrastructure out there today. So, once you go to microservices, you you need to now think about what is a common communication mechanism? There's a bunch out there. You could use HTTP, you could use GRPC. What we find is they have shortcomings.
15:22 Speaker 02 And if you use things like Kafka or an event streaming backbone, what you get is a whole bunch of capability for free that make agent-to-agent communication a lot easier. So with Kafka, I get a consistent naming space. All my subjects are topics. I can introduce a topic without having to do all sorts of network configuration that I may have to do if I use HTTP and and legal low-level APIs. I can have event-based communication. So if I use HTTP, there's a request-response model. If I use event streaming, what I have is is a publish-subscribe model, which we think is is actually the way that the agent ecosystem is going to evolve.
16:03 Speaker 02 So there's low-level communication protocols that I think things like A to A and MCP will need to actually consider as they evolve. But if I look at the fundamental substrate around how agents are communicating, it's all about event streaming. It's about event-driven.
16:18 Speaker 01 And do you see that as the main contribution that you're making to this kind of dialogue around agent-agent communication? Besides sort of pointing out like where some of the limitations are today, given like the vision of what's happening? Or are there other things that you're sort of adding to this conversation?
16:34 Speaker 02 When we wrote the book, we had a few ideas. Things are changing quite rapidly. What we think we've done is introduce the notion that if you're building agents, that's cool, but you need to think about the agent ecosystem. That's fundamental principle number one. The second thing is if you expect these agents to move out of the lab and into production, you need to have a set of enterprise capabilities. We've identified those. So the contribution that I'd like to think that we've made is we've highlighted the fact that this is not about individual agents, it's about the ecosystem. And we've talked about the architecture principles and capabilities you need to actually build a Very large, very capable ecosystem. So that's a contribution we think we've made.
17:16 Speaker 02 The second piece of the puzzle is we think we actually have the building blocks for some, and we call a few of these things out in the book. But there's building blocks, for example, around trust. And how you may actually go about trusting the agents. If you're going to have a hundred thousand of these things in your enterprise doing work like people, then you need to actually set up a trust framework, just like you have for people. So HR practices are all about know your employee. We believe that you have to have a similar framework around know your agent. Just like there's KYC, there should be a KYA. And what that says is fundamentally, how do I actually go about trusting my agents? Sure, of course, an agent has to have an identity.
17:59 Speaker 02 An agent, once it has an identity, you can confer permissions, roles, and capabilities to that agent. Now, once you have those, you can actually, if you layer on things like task planning and explainability, logging the task plan, what you can actually do is now understand what that agent is actually doing. Just like when we log or understand the process flow and what an employee actually does. Now, the interesting thing about that is we think agents lend themselves very well to a new notion of trust. And I call it new because it's only because it's new as it's applied to agents. But this trust framework that we have in the book, which I would strongly advocate is the way forward.
18:41 Speaker 02 And that would be one of the things I think is one of our fundamental contributions. Is the trust framework we have is based off of the trust framework that has been around for a hundred, about a hundred years, give or take. And the analogy we use is underwriters laboratory, for example, in the United States. And we have the Canadian Standards Organization. There's European ones that do similar things. But what they do is they have a federated mechanism, accreditation, way of identifying the experts, setting up the processes so you can actually certify and verify, even third-party certification of real-world products. So today, if If I pick up my toaster, at least in Canada, if I pick it up, I can actually see a CSA logo.
19:25 Speaker 02 I'm sure it's that you have a UL in the, in the United States. And ultimately, what that says is that toaster is not going to burn my house down. Well, what I'd like to do is have metaphorically, of course, pick up that agent and look at and see if there is a logo under there that says this agent is not metaphorically, again, going to burn my data center down. So we think there's a whole trust framework that you need to think about. And that's one of the big things that we actually have and emphasize a lot in the book.
19:54 Speaker 01 Yeah, I mean, I, it's kind of like the evolution of HTTP where we moved to having certificates associated with like trusted websites. And then that became the standard, essentially. In terms of like the know your agent idea and being able to certify agents, like, do we need to create standards around that, the same way that we've created standards around some of these tool communications and agent, agent communication? Now we have standards that are being proposed around even e-commerce through agents.
20:22 Speaker 02 Yeah, absolutely. I strongly agree. So if you think about, I'll just use again, extend the analogy with Underwriters Lab. It started way back in the day, I think over a hundred years ago, when electricity was introduced into the United States. And what they wanted to do is make sure that people wouldn't, when they interconnect the devices, that they wouldn't burn the barn down or the factory down. It's obviously evolved to millions of different products and billions of instances of those products out there. So what we think is exactly to your point, there should be a mechanism, whether the agent only applies and works inside the enterprise, the governance team in that enterprise needs to be equipped with this type of capability.
21:04 Speaker 02 And it needs to be a capability at scale because if we have, you know, if you're governing tens of databases, that's one thing, data governance. But if you're governing thousands or tens of thousands or hundreds of thousands of agents, you need to think about this differently. So, so the whole idea around distributed or federated certification is fundamental. Third-party accreditation, third-party certification. Now, what I'm talking about is something that may be a little bit further than. Future, but as you highlighted in your example, on the web, we we introduce certificates to verify and trust the fact that this website is actually representing who who they're supposed to be. That same mechanism is exactly what we actually foresee in the longer term.
21:49 Speaker 02 Inside the enterprise, though, you need to have a similar federated governance mechanism. Again, it starts with identity. Every agent needs to have a persistent, long-running identity. That's the fundamental thing. But once you have that, you can assign, again, permissions. And once you actually do fundamentally basic logging, you can actually see what it's doing, which is the basis of governance. Even in the enterprise, if you set this up well, I think you have to be good. You have to automate this because there's going to be so many of these agents running around. If you do this, you can actually get some tremendous visibility and observability into what your enterprise is doing. But that's the foundation for trust, and I think we think that's table stakes.
22:30 Speaker 01 Why do you think having sort of standards around some of this stuff is lagging behind some of the standards that we have around? Things like tool use or even now like agent commerce. Is that just because until you have a certain amount of scale, you don't face these problems as much? And it's when we reach that scale that it's going to be something where we we see more of an industry push for standards around it?
22:53 Speaker 02 Yeah, well, I think so. Here's what I would say is I've been around for a long time and I've seen the standards around the web and the internet evolve. They seem to happen very quickly. But if you think about it, these things have been around for decades. So in hindsight, it looks like things are happening very quickly. In reality, these things happen relatively slowly. These standards like A to A and MCP evolve. And they evolve and they they ultimately get better, but the process is slow. Fundamentally, because if I design it for three or four people, it's easy to change. If I design it for three to 400 people or organizations, it's a little bit more difficult. If I design it for a global standard, there's a lot of folks that have an opinion, a lot of participants in the decision-making process.
23:35 Speaker 02 So things will change, they'll change relatively slowly. But here's what I would say. Is things like A to A, things like MCP, those make sense. And what we're starting to see, perhaps MCP is further ahead than A to A right now. What we see with MCP is we're starting to see some real traction. What we see is, you know, now it's within Linux Foundation, you have an open transparent mechanism of evolving it. But what you have is, is real user feedback that is improving, for example, the security posture with an MCP. That's a really big deal. So what we're seeing is, is the evolution in practice.
24:16 Speaker 02 In hindsight, it'll look like it's happening quickly. When we're in the middle of it, maybe a little slower than we'd all like. But, but they're fundamental to making it all work.
24:23 Speaker 01 Yeah, I mean, I think no one, and I'm willing to bet that Anthropic is in this bucket as well, expected MCP to take off the way that it did. I mean, it was first proposed in November of 2024, and then a year later, it was like 190 million downloads of the SDK a month or something. And then it was donated to the Linux Foundation. So, you know, clearly it caught fire at the right moment where the models were sophisticated enough to be able to use something like that. And it's continued to grow. And of course, there's debates about longevity of it versus other approaches. But right now, it certainly has really taken off. And that probably helps, like you said, propel the standard forward because you have this feedback loop in terms of like, if everybody's using it, then everybody's going to have an opinion about how we make it better.
25:07 Speaker 02 Hmm, absolutely. And I think the standards progression that we're seeing is, I mean, this is only a good thing and we'd love to see it go quicker, but we'll take what we get.
25:17 Speaker 01 Yeah. So you talked a lot about the importance of things like observability and traceability for enterprise agents. Like, is that like a fundamentally different problem than observability and traceability for traditional enterprise applications? Because, you know, we've had that for forever. Like, what is it that's net new here?
25:34 Speaker 02 So yes and no, let me kind of bring it together a little bit. So whether you can, independent of your architecture, if you have agents collaborating and you're tracing the messages. And then you have fundamental things like an ID, a conversation ID, a session ID, a traceability, a correlation ID, the different names, the same thing. But fundamentally, if I have a conversation going from one agent to another, and I can actually correlate those. What you've got is, is something that is, in my opinion, this is already done today. It's table stakes if you want to do agents. Here's the gap that we have today. Those are wonderful things after the fact.
26:14 Speaker 02 What we need to do is be able to understand what the agent is thinking before it actually executes all that. Make sure it logs what it's thinking. And then we actually can trace the execution path back to the plan that it actually came up with. That's the gap. That is one of the fundamental gaps that we see today, and we address that specifically in the book. So let me, let me make this really clear. If I go to ChatGPT, or I go to Codex, or I go to Claude or Claude Code, I can issue a request and I can actually see it thinking. Okay. But it's largely natural language, A, that's interesting, that's useful. B, it's not captured necessarily anywhere.
26:56 Speaker 02 And if I have thousands of these agents, even if I do capture it, how do I actually correlate and make sense of that to the actual traceability? Which is very, very structured and observability information, very structured. How do I actually join the two? How do I answer the simple question of now I know what the agent did, did it do the right thing? So what we're saying is that one of the fundamental gaps that must be addressed is what we call agent explainability. When a request came in, how did that request get decomposed into a task plan? How did sub-agents get assigned to that task plan? Or other distributed agents get assigned to that task plan for that individual step? Or a tool have that logged?
27:41 Speaker 02 Have it explain how the parameters from that initial Request got plugged into those and got passed to the individual subagents or other agents. So that we can actually have an explainability log. That we can then compare to the observability log. And you bring the two together. And we can actually see the difference around what the agent thought it's supposed to do and what the end result was. That's fundamental. Now, the second piece of that puzzle, if I have explainability. All of a sudden, what I can do is begin to have a new, rich way of testing my agents. Which is another gap that we actually see out there. The whole idea around how do I know if an agent fundamentally based off of an LLM? The LLM's the brain for the agent.
28:24 Speaker 02 How do I test or verify that it was doing the right thing? Well, I can check the observability logs. But what if I could actually check the agent task plan? And how it decomposed the request and what it was thinking when it came up with the task plan? And how did I identify the individual agents or tools to call? That's powerful. And that's one of the things we call out in the book that we think is table stakes in the agent future. We don't have that quite yet, but we start to see there's a glimmer of hope. If you will, we actually do see some progress in that area, but it's still a gap.
28:58 Speaker 01 In this setup where you have essentially a log of what the agent thinks it's supposed to do or what it actually, and then also you have what it actually did. And then you get to a point where you see that there's a deviation. Can the agent use that information to self-correct? Similar to how, like, I think one of the powerful things about some of the things we see with like the Ralph Wiggam loop, for example, in engineering is you can have multiple agents, it can also sort of self-correct when errors happen because we can catch those fairly early in engineering because this leads to like a compilation problem or if there was an exception or a unit test fails or whatever it is. And they can use the output from that to essentially self-correct. But that's hard to do in non-engineering domains where we don't have the same kind of guardrails in place.
29:44 Speaker 01 So is this a way to potentially solve some of that problem?
29:47 Speaker 02 Potentially. So I'm going to expand a little bit. I'll give you a scenario. So if I look at the individual coding agents, they are personal productivity tools. They're made for an individual and there's a variety of different ways that they can actually course correct. But if I have Agent A talking to Agent B, talking to Agency, and you can see maybe there's a string of agents and their distributed computing capability. All of a sudden, what happens if Agent A does a task plan and it calls B? Then Task B or Agent B does a task plan, calls C. What happens if Agent C is missing some data? So I wanted to open up a bank account and I gave my name and I gave my driver's license,
30:28 Speaker 02 but I forgot to ask what type of bank account I wanted, checking account or savings account? What type of banking account I wanted to open? So all of a sudden, the third agent, I'm giving you a contrived example, but hopefully it's easy enough to understand. The third agent in that chain needs to understand that it's missing some data. That is a distributed computing challenge. That is a conversation management challenge. That is not the same as using some of the coding agents that we have today, where everything's in memory. It's very simple to checkpoint on a disk or in a file and then restart and recover. That is a very different animal than what we're talking about in the enterprise. So I'll give you an example of what we do.
31:11 Speaker 02 One of the demos we have, because we were hoping that we can put a reference set of code out there in about a month or month and a half around some of the concepts around agentic mesh. And one of the examples we have is if some data is missing. When I'm a third string down the road, Agent A talking to B, talking to C, and C recognizes a missing some data. How do I actually communicate the new data to that agent? Okay, it's a checking account and not a savings account. How do I communicate that? And how do I have that agent actually restart from where it was and continue? That is a distributed computing challenge. It has been solved. Perhaps not as elegantly necessarily in enterprises as you'd like, but if you have things like event streaming, event-driven replay.
31:57 Speaker 02 Of those events, you can actually start to make that happen. But really, this is about conversational state management. And how do I restart situations where things may not be broken? I'm missing data. Or what do I do when an agent third way down the path has actually broken? Do I terminate the process? Do I restart it? Do I fix it and then have it restart? There's a bunch of things you need to think about that are enterprise issues that may not necessarily be the same issues or solved the same way. If you're using like Claude code or some of the variants thereof.
32:30 Speaker 01 Yeah, you talk a lot about these microagents, essentially like agents as microservices. And then you need to like communicate across the network. You need to orchestrate them. I guess like, what are your thoughts on sort of the monolithic architecture versus the microagent? Like, you know, one agent, the rule of the mall versus splitting it up? Like, I mean, the advantage of the monolith, obviously, is that it kind of makes the context management problem easier. Because it's all sourced from the same area. But then with the microagents, you're distributing that context and you run into those problems that you're talking about. Like, you could even have something where you have Agent A kicking off Agent B, kicking off Agent C. New information comes in that A needs to get to C.
33:13 Speaker 01 You know, how do you deal with sort of that cascading thing and interrupt what's doing? So you have to end up creating some sort of shared context across all these different systems. But then, of course, with the monolith, it's going to be a beast to run at some point for, you know, amount of activity and stuff. So how do you kind of think about you navigating that structure?
33:31 Speaker 02 Yeah, sure. I'm going to come back to my analogy that I mentioned earlier, where if you think of an agent as a person in an organization. And I have teams of people, we call them fleets of agents. And I have organizations or departments of people. I have ecosystems or shared workspaces of agents. The reason in an organizational context, I break down from.
33:57 Speaker 02 The monolith. Walmart could conceivably, for example, be one monolithic organization of, you know, several million people, all managed from the top down. And we've found that that doesn't necessarily work. What we try and do is put the decision making in the most appropriate place, which is typically closest to the action. So, so we have models that explain how we actually organize people. And we do that fundamentally because there's overhead in communicating. There's overhead in making decisions. And what that really says is that we structure a big hundred thousand person organization into a small tie, you know, a CEO, a bunch of SVPs, and then a bunch of groups, perhaps geographically organized or otherwise.
34:42 Speaker 02 So what we find is that construct is exactly the same. Now, in an IT organization, when we build monoliths, especially monoliths that cross organizational or geographic boundaries, we all know what happens. The situation we have is we don't know who actually owns it. And ultimately, we ended up designing that thing as a monolith to save costs. But what the business actually wants is agility. What the business says, I don't care if organization A wants to do this. I'm organization B and I want to do this. There's a fundamental mismatch in terms of motivations, incentives, and decision making. And hence, things slow down. So if you want to go with the monolithic approach, first off, you're compromising agility versus cost.
35:27 Speaker 02 That may be a perfectly appropriate one. What we found, though, is the same reason that organizations decompose from the top down into geographic units, business units, or product units, whatever the case may be, is to permit faster decision making by the folks in the place most equipped to make those decisions. We think the same construct applies to agents. So, do I want a monolith? Maybe. Okay? But you need to accept the fact that you're designing for cost containment as opposed to agility. We all know if we bundle enough stuff into the thing, we may get reduced.
36:06 Speaker 02 Costs, but trying to unbundle that or add new capability, there's a tech debt that increases exponentially as you do that. So this is a cost versus agility discussion. If you go to the business and say, how do I want to organize? They will say, I guarantee you 10 times out of 10, structure it for agility. I want to make my own decision. I want to be controlling my own destiny. Exactly the same for agent architecture. The model is exactly the same. The incentives are exactly the same. Our proposition is let's learn from decades of practice around HR. And let's figure out how we can apply these in an intelligent way. That's where we see it. I mean, fundamentally, what you don't want to do is be on the wrong side of Conway's law.
36:47 Speaker 02 Conway's law says ultimately your, your systems are going to follow the structure of your organization. And the reason they do that, you can read into what Conway actually says, but fundamentally, they structured that way to enable faster decision-making and agility. So if you want to go against Conway's law, then you just need to understand what you're getting into. And that's, that, that's why we believe strongly that if you're a small company, a modelist is probably the right way to go. But if you're a large company with multiple groups, multiple divisions, agents will follow the same practices that your employees and how you organize your employees. That's what we fundamentally see and we, in discussions with clients that seem to be resonating.
37:28 Speaker 01 Yeah, it kind of in some ways reminds me of like Steve Yeg's Gastown, where he's like modeling that after like a small town, you have like a mayor and you have basically agents that take on different roles. And it's for these like coding agents and in some sense, you're sort of taking, he takes a real world concept and is applying it to a multi-agent system. And you're sort of taking a real world concept of these constructs that we built up in the enterprise and then using those as a way to be successful with these multi-agent systems.
37:56 Speaker 02 Absolutely, absolutely. I mean, fundamentally, what's the saying? We stand on the shoulders of giants and that's why we can see so much further ahead. We strongly believe that there's lessons to be learned. And that analogy, people to agents, yes, it breaks down and I don't mean to disparage any or, or, or short. Change any of the issues as agents potentially have impacted people's jobs. But there's an analogy that does extend relatively far. And it should provide lessons learned that we can actually apply.
38:29 Speaker 01 With the clients that you work with in this space, when it comes to the types of things that they want to build, like the problems that they want to solve with agents. It's kind of the shape of those problems for like B two B in enterprise. Is it drastically different than the shape of the problems that we might be solving with B two C? Or even with like coding agents?
38:51 Speaker 02 Yeah, well, coding agents are a different animal. I mentioned earlier, coding agents are like personal productivity tools, if you will. That's not to disparage it at all. I mean, they can do fantastic things for software development and they're being extended into other areas. But that's different than the enterprise space, B two C or B two B. Here's the things that we do see, there's some common patterns. So first off, I do work in the payment space a fair amount. Payments is not where you want to start your agent journey. Payment systems probably out of necessity need to be a hundred percent deterministic. And you don't want to have agents injected into that. However, let's take a look at compliance. Compliance, we work with some folks who in the the private debt market.
39:35 Speaker 02 And they have armies of people that would take a compliance document that comes in from. They typically have four or 500 different organizations that send documents in that have that come in variety of different formats. Excel, email, you name it, every format known to man is in there. They have armies of people that try and actually understand what those documents are, decompose them, normalize them. This is something that agents can actually do. This is the sweet spot for agents that we see today. Agents can deal with, just like people can deal with ambiguity, agents can deal with ambiguity. Just like people can reformat, if you will, a PDF into a spreadsheet. Agents can do exactly the same.
40:16 Speaker 02 Here's the thing, this is the words from our client, is they're better, they're faster, they're cheaper, they're 724. And the knowledge that they learn, these agents learn. As opposed to the people that learn them and leave the organization, you have to constantly retrain them. This is knowledge and IP that stays within the organization. So what we see is there's a sweet spot right now, today, around compliance document. And that's where we're doing a lot of work. Compliance document management, being able to process those in a much more effective and much more efficient way. That is the sweet spot today. It's evolving. There's places, like I said, where you don't want to do this, at least not today, maybe in the future. But there's some places where the low hanging fruit's literally on the ground
41:01 Speaker 02 waiting to be picked up.
41:03 Speaker 01 Yeah. If more and more organizations are able to essentially automate a lot of these types of work that you're talking about, like, you know, compliance work, I'm sure in like, FinServ loan processing, or some parts of loan processing, and all kinds of this, this kind of work. Like, how do you see that changing the organizational structures of these companies? Like, we, we for a long time had to build org structures based around, in some capacity, like, humans doing some of this kind of rote tasks that was just hard for anybody that wasn't a human to be able to do it because of the, the reasoning involved or dealing with the ambiguity.
41:39 Speaker 02 Yeah. So this is a little bit of the future of work type discussion. So I'd be the first one to say that I'm not an expert in the future of work. But let me give you kind of what my crystal ball says. We believe strongly that if you try and optimize what you're doing with agents for cost, you are missing a huge opportunity. If you use agents to get rid of people, you are losing the intellectual property that has built your company. That's a really, really big loss. And I, and I can't emphasize that more. The organizations that we see being successful are the ones that say, I want to actually
42:22 Speaker 02 make my existing employees 10x more efficient. It's like, you know, we're both in the software industry. Everybody talks about the 10x engineer. If you could only find the 10x engineer because there's so far. Far and few between, but if you find one that the impact is incredible. Well, what if I could say that the one X employer, two X employee augmented by an agent can be turned into a 10 X employee? They could process compliance documents 10 times faster than my competitor. The organizations that look at this as a opportunity to go into new markets. An opportunity to extend the capability of their existing employees.
43:07 Speaker 02 The companies that want to retain the intellectual property that make that company special. And enhance it and go to market with that with agents and become 10 X more effective. That's the company that wins the day. This is not a cost play. Yes, some companies will do that. If that's where you're focused, your attention, you will be a laggard, in my humble opinion, you will be a laggard. The folks that take advantage of this to introduce new opportunities, new marketplaces, extend the capability of their existing employees. Retain the IP and enhance it. That's the winners. That's the winners that we see.
43:44 Speaker 01 So if this agent ecosystem pans out the way that you think this things will. And you know, there's a lot of luminaries in the space that certainly I think see a similar vision of the future. What does the enterprise look like in, you know, five years from now?
44:01 Speaker 02 Sure, that's a very good question. Again, I'm going to come back to my crystal ball being foggy at the best of times. But here's the thing that we see. A lot of the stuff that we're building today is infrastructure for tomorrow. So whether it's agentic mesh that that's our term and whether you build on microservices. Fundamentally, you're going to have ecosystems of agents. The question really in my mind is, how do you want to organize that capability? How do you want to organize those thousands of agents or millions of agents? In a way that achieves your business objectives. So what we believe the next evolution is what we call agentic process automation. That's where instead of RPA or robotic process automation, which you know, does a little bit of screen.
44:46 Speaker 02 We think that's wonderful, but ultimately there we all know the gaps in that world. Edge cases cause immense difficulty, user interfaces change, data formats change and everything goes awry. Fundamental thing is the processes today are not able to deal with the ambiguity that is normal within the enterprise. And we hand off far too much to individual people, drives inefficiencies. Well, what if we use that agentic mesh infrastructure and we layered on the ability to manage processes, apply the agents. So agents are full participants in the actual business process, sitting on top of this agentic mesh. That's discoverable, observable, traceable, explainable, all that.
45:28 Speaker 02 What we did is we applied these agents, their ability to deal with ambiguity, their ability to make decisions, their ability work 724. And we applied those to business process. We think that's actually the next stage in evolution where we're going to see agentic process automation. Agents embedded in the business process, using their intelligence as opposed to people to make the decisions on how to reroute a compliance document. Those are the things that we actually see happening, literally in the next, you know, 16 to 18 months. What we also see is, and we're having discussions around this already, is this notion around today, we have HR management. So human resource management, how do we actually onboard people?
46:13 Speaker 02 How do we train them? How do we measure them? How do we make them more effective? Same idea for agents. So I don't know what the term is going to be, you know, agentic resource management. I don't know, but what we're going to have is the same ideas around how do we actually ensure that the agent is doing what it's supposed to? How do we measure its effectiveness and how do we actually train it to actually do things better, smarter? That's something that we think is give or take 24 to 36 months out in terms of becoming commonplace. But we're starting to see a little bit of that already starting to happen. So that's about as far as I can go out. I don't know if I can go five years, but I'll give you three years there.
46:52 Speaker 01 Well, great, Eric. Is there anything else you'd like to share?
46:56 Speaker 02 No, I think we've covered just about everything. I want to just obviously say thank you very much for giving this opportunity to talk and very much look forward to having further discussions.
47:05 Speaker 01 Awesome. Well, thanks so much for being here. Cheers.
47:08 Speaker 02 Thanks. You're welcome.
Previous New Relic and Agentic DevOps with Nic Benders Next Unlocking the Data Layer for Agentic AI with Simba Khadder Page updated November 6, 2026 · transcript and summary are machine-generated