Agentic Mesh with Eric Broda

0:00Eric Broda: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 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.

0:59Eric Broda:This episode is hosted by Sean Falconer. Check the show notes for more information on Sean's work and where to find him.

1:19Eric, welcome to the show. Well, Sean, it's great to be here. Thanks for having me. 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. Awesome. 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 of March. Oh, that's amazing. Yeah. Sorry for missing that. I knew that you co-authored it with another Broda, but I wasn't sure.

1:55I 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'd 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, son's working together, agents, it's all coming together now. Well, it's kind of funny you mentioned that because I think that 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.

2:31The 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. Yeah, well, I'm kind of curious about 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? 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. Joe Rice. Yeah, Joe Rice, about a year ago.

3:04And 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 going to be a timeless effort, if you will. Right. So we talked a little bit about how things are changing so fast in this world.

3:40And I think we've really gotten to a place where, especially with agentic engineering, 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 something that was maybe not 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? Why is it that enterprises keep failing to do this and the failure rate is so high? Yeah, sure. The thing that we hear from our clients is they are having great difficulty getting out of the lab and into production.

4:19And 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. The problem is, is despite the best efforts of the folks who are writing the agent, more often than not, There are folks that are new, perhaps, to the game.

5:04They'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 there's 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 an agent ecosystem. But the fundamental question is, how do I manage these agents?

5:43If you recognize Jensen Wang or Andy Jassy, Sachin Adela, all of them have said 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 obviously are very familiar with Kafka. Kafka lives in that ecosystem. It is built to support vast ecosystems. 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 built.

6:36This is really a question on how do I design the ecosystem rather than how do I design the agents, Sean? When it comes to this, you mentioned these enterprise features that every sort of enterprise piece of software has. And then you also have this sort distributed system challenge of 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 traditional software engineering challenges versus something that's a net new challenge?

7:11Well, 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 and 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.

7:51If you haven't got that figured out, you're not going to get past the operations check. 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 be the hardest one is this notion around trust. How do I actually engender trust to these agents? These agents will be doing effectively, although 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.

8:26We actually see agentic process automation, if you will, where agents are participating 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 customer 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.

9:03And we think there's actually a pretty significant opportunity to leverage some of the practices, HR practices, to be honest with you, and 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 that we're thinking about and talking with some of our clients right now. 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?

9:38Or do you need to not leverage those tools and go somewhere else to get this kind of work done? 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 pretty commonplace. But what you're building is something that is specific to, you know, it works on your workstation or your laptop, your Mac mini or whatever the case may be. But it works as an agent that functions for you as an individual.

10:15And 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? And I think that's the fundamental difference between where we are today. 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. 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?

10:50So 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, then I'm going to build agents that are not able to communicate with each other.

11:28They 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.

12:03But again, the design pattern is I'm focusing on what an individual can do, 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?

12:40That'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. So you talk 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? I guess like where does protocols like A to A fit into this? Is that a potential solution or is it fundamentally missing pieces in order to do this at the scale that you're talking about? 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.

13:29These 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 their stuff. So I think the thing is the state of the nation is evolving rather rapidly. 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.

14:07And 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. Now, here's the one thing I would say, and there's a fundamental substrate behind each of these.

14:42One is, if you read through the ATA spec 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 ATA 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 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:22And 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 or 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 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 a publish-subscribe model, which we think is actually the way that the agent ecosystem is going to evolve.

16:03So 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. 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? When we wrote the book, we had a few ideas.

16:36Things are changing quite rapidly. What we think we've done is introduced 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.

17:13So that's a contribution we think we've made. 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 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.

17:52And what that says is fundamentally, how do I actually go about trusting my agent? Of course, an agent has to have an identity. 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.

18:31And 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. 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 about 100 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.

19:20So today, if I pick up my toaster, at least in Canada, if I pick it up, I can actually see a CSA logo. I'm sure you have a UL 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:54Yeah. I mean, 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.

20:05Eric Broda:In mobile application security, good enough is a risk. GuardSquare uses advanced, multi-layered code hardening techniques and automated runtime application self-protection and mobile application security testing, combined with real-time threat monitoring to deliver the highest level of mobile app security. Discover how GuardSquare brings all these together to provide mobile app security for your Android and iOS apps without compromise at www.guardsquare.com. Today's episode of Software Engineering Daily is brought to you by Unblocked. Your coding agents have access to your code base. Maybe you've even connected other tools via MCPs.

20:47Eric Broda:But access doesn't mean context. Agents can't reason across MCPs. They don't know your architectural decisions, your team's patterns, or why the API was shaped the way it is. So agents look in the wrong place and deliver bad outputs. Then you spend time correcting, turn after turn. Unblocked is the context layer your agents are missing. It synthesizes your PRs, docs, Slack, and tickets into organizational context that agents actually understand, so they make better plans, write higher quality code, use fewer tokens, and require fewer correction loops. If you are running Cloud Code, Cursor, or any agentic workflow, Unblocked is worth a look.

21:26Eric Broda:Get a free three-week trial at getunblocked.com slash sedaily. In terms of the know your agent idea and being able to certify agents, do we need to create standards around that the same way that we've created standards around some of these tool communications and agent-to-agent communication. Now we have standards that are being proposed around even e-commerce through agents. Yeah, absolutely. I strongly agree. So if you think about, I'll just again extend the analogy with Underwriters Lab. It started way back in the day, I think over 100 years ago when electricity was introduced into the United States.

22:02And 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. 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 agencies 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 in the future but as you highlighted in your example, on the web, we introduced certificates to verify and trust the fact that this website is actually representing who they're supposed to be.

23:10That same mechanism is exactly what we actually foresee in the longer term. 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. 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 automate this because there's going to be so many of these agents running around.

23:47If 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. Why do you think having sort of standards around some of this stuff is wagging 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 see more of an industry push for standards around it?

24:20Yeah, 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. They evolve and they ultimately get better. But the process is slow. So fundamentally, because if I design it for three or four people, it's easy to change. If I design it for three to four hundred people or organizations, it's a little bit more difficult.

24:55If 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. 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 real user feedback that is improving, for example, the security posture with an MCP.