[EPISODE] 1917

[INTRODUCTION]

[0:00:00] ANNOUNCER: 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 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 joined 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. 

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

[INTERVIEW]

[0:01:20] SF: Eric, welcome to the show. 

[0:01:21] EB: Well, Sean, it's great to be here. Thanks for having me. 

[0:01:23] SF: Yeah, thanks so much for being here. So, I want to start off. You wrote a great book, Agentic Mesh: The GenAI-Powered Autonomous Agent Ecosystem. 

[0:01:33] EB: 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. 

[0:01:49] SF: Oh, that's amazing. Yeah. Sorry for missing that. I knew you co-authored it with another Broda, but I wasn't sure. I didn't realize it was your son. That's great. 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. Lots of things coming up. Father sons working together, agents and all. It's all coming together now. 

[0:02:19] EB: Well, it's kind of funny you mentioned 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. 

[0:02:41] SF: Yeah. Well, I'm kind of curious about why a book, given that things are changing so fast. Literally, the entire developer experience has shifted in the last two to four months alone. So, is it old news by the time something like a book comes out? 

[0:02:55] EB: Yeah. Well, that's a great question. It's kind of funny because I was talking, I was on a podcast with Joe Reis. I can't remember. 

[0:03:01] SF: Joe Reis, yeah. 

[0:03:03] EB: Yeah, Joe Reis. About a year. 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, yeah, 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 date before you publish. But the date you publish, you have old stuff. What we try to do in this book is focus on the concepts, the architecture, the higher level design principles. This would hopefully - we're hoping it's going to be a timeless effort, if you will.

[0:03:35] SF: Right. We talked a little bit about how things are changing so fast in this world. And I think we've really gotten to a place where, especially with agentic engineering, essentially anybody can 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 maybe not deeply technical could probably pull something off with some prompting. 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? 

[0:04:10] EB: 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. 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, 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. 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? 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 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 build. This is really a question around how do I design the ecosystem rather than how do I design the agents, Sean. 

[0:06:42] SF: Mm-hmm. When it comes to this, you mentioned these enterprise features that every sort of enterprise piece of software has, and then you also have the sort of 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 like a net new challenge? 

[0:07:12] EB: 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 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 and 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. 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 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 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, and leverage those into the agent ecosystem and come up with agent resource practices instead of human resource practices. That's some of the things that we're thinking about and talking with some of our clients right now. 

[0:09:22] SF: And there's no shortage of various agent frameworks that are out there that people are building some of these experiences on, organizations that maybe are investing in those technologies. 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? 

[0:09:44] EB: 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 common place, but what you're building is something that is specific to - it works on your workstation, or your laptop, your Mac mini, or whatever the case may be. But it works. It is 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? And I think that's the fundamental difference between where we are today. 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? 

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. 

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. 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. 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, innovations going on. We see OpenClaw, for example. But 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. 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. 

[0:12:50] SF: Mm-hmm. 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? I guess where does protocols like A2A 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? 

[0:13:14] EB: Yeah. We strongly believe that things like MCP, Model Context Protocol, from Anthropic. Now, I think with the Linux Foundation, A2A, Agen2Agent, protocol out of Google. I think if I'm not mistaken, it's also in the Linux Foundation. I believe they're fundamental improvements in terms of how agents are going to collaborate. They're not the end destination necessarily. 

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 A2A or MCP. Yes, MCP is embedded in their stuff. I think the thing is the state of the nation is evolving rather rapidly. But, fundamentally, the principles behind A2A, the principles behind MCP are foundational. We're going to start to see these evolve. 

I mean MCP has 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. A2A is going to go the same way. What we see is some very early stage capabilities. But A2A 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. One is if you read through the A2A 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 obviously the A2A 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. 

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. 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 Agent2Agent 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. There's low-level communication protocols that I think things like A2A 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. 

[0:16:17] SF: Mm-hmm. And do you see that as the main contribution that you're making to this kind of dialogue around Agent2Agent communication besides sort of pointing out where are some of the limitations are today given the vision of what's happening? Or are there other things that you're sort of adding to this conversation? 

[0:16:34] EB: 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. 

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. That's the 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 100,000 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 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 explanability 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 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 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 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. 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. 

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's a logo under there that says this agent is not metaphorically, again, going to burn my data center down. 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. 

[0:19:54] SF: Mm-hmm. Yeah. I mean, it's kind of like the evolution of HTTP, where we moved to having certificates associated with trusted websites. And then that became the standard, essentially. 

In terms of like 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-agent communications? And now we have standards that are being proposed around even e-commerce through agents. 

[0:20:22] EB: Yeah, absolutely. I strongly agree. 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, 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 you're governing tens of databases, that's one thing, data governance. But if you're governing thousands, or tens of thousands, or hundred thousands of agents, you need to think about this differently. 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. That 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 - and I think you have to. And 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 we think that's table stakes. 

[0:22:29] SF: Mm-hmm. 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, 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? 

[0:22:53] EB: Yeah. 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. In hindsight, it looks like things are happening very quickly. 

In reality, these things happen relatively slowly. These standards like A2A and MCP evolve. And they evolve. And 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. Things will change. They'll change relatively slowly. 

But here's what I would say, is things like AA, things like MCP, those make sense. And what we're starting to see, perhaps MCP is further ahead than A2A right now. What we see with MCP is we're starting to see some real traction. What we see is, now 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. That's a really big deal. What we're seeing is the evolution in practice. 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 they're fundamental to making it all work. 

[0:24:24] SF: 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, 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. 

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, if everybody's using it, then everybody's going to have an opinion about how we make it better. 

[0:25:07] EB: Mm-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. 

[0:25:18] SF: Yeah. You talked a lot about the importance of things like observability and traceability for enterprise agents. Is that a fundamentally different problem than observability and traceability for traditional enterprise applications? Because we've had that forever. What is it that's net new here? 

[0:25:35] EB: Yes and no. Let me kind of bring it together a little bit. Whether you can independent 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 something that is - in my opinion this, 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. 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. 

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. 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 is 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? 

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. Have it explain how the parameters from that initial request got plugged into those and got passed to the individual sub-agents 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 is the brain for the agent. 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. 

[0:28:58] SF: 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 I think one of the powerful things about some of the things we see with the Ralph Wiggum 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 a frozen exception, or 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. Is this a way to potentially solve some of that problem? 

[0:29:47] EB: Potentially. I'm going to expand a little bit. I'll give you a scenario. 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 agent C, and you can see maybe there's a string of agents, and they're 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 call C. What happens if agent C is missing some data? 

I wanted to open up a bank account, and I gave my name, and I gave my driver's license, but I forgot to ask what type of bank account I wanted. Checking account or savings account? What type of bank account I wanted to open. 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 restart and recover. That's is a very different animal than what we're talking about in the enterprise. 

I'll give you an example. What we do, one of the demos we have - because we're 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 a third string down the road. Agent A talking to B talking to C, and C recognizes 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 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. 

[0:32:29] SF: Mm-hmm. Yeah, you talk a lot about these microagents, essentially agents as microservices. And then you need to communicate across the network. You need to orchestrate them. I guess what are your thoughts on the sort of the monolithic architecture versus the microagent? One agent to rule of them all, versus splitting it up. 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. You 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. How do you deal with sort of that cascading thing and interrupt what it's doing? 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 a certain amount of activity and stuff. How do you kind of think about navigating that structure? 

[0:33:31] EB: 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 the monolith, Walmart could conceivably, for example, be one monolithic organization of a several million people all managed from the top-down. And we 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. 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 100,000 person organization into a small - a CEO, a bunch of SVPs, and then a bunch of groups, perhaps geographically organized or otherwise. 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 cost. 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. 

If you want to go with the monolithic approach, first off, you're compromising agility versus cost. That may be a perfectly appropriate one. What we found, though, is the same reason that organizations decompose from the top-down into geographic unit, 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. 

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 costs. But trying to unbundle that or add new capability, there's a tech debt that increases exponentially as you do that. This is a cost versus agility discussion. 

If you go to the business and say, "How do I want to organize?" They will say to you, I guarantee you, 10 times out of 10, structure it for agility. I want to make my own decisions. 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. Conway's Law says, ultimately, 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 structure it that way to enable faster decision-making and agility. If you want to go against Conway's Law, then you just need to understand what you're getting into. And that's why we believe strongly that if you're a small company, a monolith 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 in discussions with clients, that seem to be resonating. 

[0:37:29] SF: Yeah. It kind of in some ways reminds me of like Steve Yegge's Gas Town, where he's modeling that after like a small town. You have a mayor, and you have basically agents that take on different roles. And it's for these coding agents. And in some sense, you're sort of taking - he takes a real-world concept and is applying it to multi-agent system. And you're sort of taking a real world concept of these constructs that we've built up in the enterprise, and then using those as a way to be successful with these multi-agent systems. 

[0:37:57] EB: 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 in that analogy people to agents. Yes, it breaks down. And I don't mean to disparage or short-change any 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. 

[0:38:28] SF: Mm-hmm. With the clients that you work with in the space, when it comes to the types of things that they want to build, the problems that they want to solve with agents, is kind of the shape of those problems for like B2B in enterprise, is it drastically different than the shape of the problems that we might be solving with B2C or even with like coding agents? 

[0:38:51] EB: 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 disparrage it at all. I mean, they can do fantastic things for software development. They're being extended into other areas. But that's different than the enterprise space, B2C or B2B. 

Here's the things that we do see. There's some common patterns. 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 100% 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 in the private debt market, and they have armies of people that would take a compliance document that comes in from - they typically have 400 or 500 different organizations that send documents that come in variety 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. 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. 

Here's the thing. This is the words from our client, is they're better, they're faster, they're cheaper, they're 7/24. 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. 

And 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 waiting to be picked up. 

[0:41:03] SF: Yeah. If more and more organizations are able to essentially automate a lot of the types of work that you're talking about, like compliance work, I'm sure in finserv, loan processing, or some parts of loan processing, and all kinds of this kind of work, how do you see that changing the organizational structures of the these companies? We, for a long time, had to build org structures based around, in some capacity, humans doing some of this kind of rogue task that was just hard for anybody that wasn't a human to be able to do it because of the reasoning involved, or dealing with the ambiguity. 

[0:41:39] EB: Yeah. This is a little bit of the future of work type discussion. So, I'll 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 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 can't emphasize that more. The organizations that we see being successful are the ones that say, "I want to actually make my existing employees 10x more efficient." It's like 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 and few between. But if you find one that the impact is incredible, well, what if I could say that the 1x employee or 2x employee augmented by an agent can be turned into a 10x employee? They could process compliance documents 10 times faster than my competitor. 

The organizations that look at this as an opportunity to go into new markets, an opportunity to extend the capability of their existing employees. 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 10x 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 focus 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. 

[0:43:44] SF: Mm-hmm. So if this agent ecosystem plans out the way that you think things will, and 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 5 years from now? 

[0:44:02] EB: 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. Whether it's agentic mesh, that's our term, and whether you build it 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? 

What we believe the next evolution is what we call agentic process automation. And that's where, instead of RPA, or Robotic Process Automation, which does a little bit of screen scraping, we think that's wonderful. But, ultimately, we all know the gaps in that world. Edge cases cause immense difficulty. User interfaces change. Data formats change, and everything goes ary. The 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 used 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. Well, what we did is we applied these agents, their ability to deal with ambiguity, their ability to make decisions, their ability to 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 16 to 18 months. 

What we also see, and we're having discussions around this already, is this notion around today we have HR management. Human resource management. How do we actually onboard people? How do we train them? How do we measure them? How do we make them more effective? Same idea for agents. I don't know what the term is going to be. 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. That's about as far as I can go out. I don't know if I can go 5 years. But I'll give you three years there, Sean. 

[0:46:53] SF: Well, great, Eric. Is there anything else you you'd like to share? 

[0:46:56] EB: 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. 

[0:47:06] SF: Awesome. Well, thanks so much for being here. Cheers. 

[0:47:07] EB: Thanks.

[END]