EPISODE 1945

[INTRODUCTION]

[0:00:00] ANNOUNCER: AI agents have transformed how software gets written, but the operational side of running software in production has not yet experienced a similar revolution. The same teams responsible for keeping systems healthy, investigating incidents, and managing reliability are still doing much of that work manually. Mezmo is a production AI company that makes autonomous operations fast, efficient, and safe. Their open-source project, AURA, is a declarative agent framework specifically designed for SRE and platform engineering workflows. It takes a Kubernetes-inspired approach where teams define what they want agents to do, rather than scripting every step of how to do it. Andre Elizondo is the Head of Product at Mezmo, and he has a background in systems engineering, SRE, and observability.

In this episode, Andre joins Kevin Ball to discuss what makes SRE agent workflows fundamentally different from coding agents, how AURA handles context engineering, or as declarative configuration model, the spectrum of agent autonomy, and where the role of the SRE is headed as agents take on more of the operational work.

Kevin Ball, or KBall, is the Vice President of Engineering at Mento and an independent coach for engineers and engineering leaders. He co-founded and served as CTO for two companies, founded the San Diego JavaScript Meetup, and organizes the AI in Action discussion group through Latent Space. Check out the show notes to follow KBall on Twitter or LinkedIn, or visit his website, kball.llc.

[INTERVIEW]

[0:01:47] KB: Andre, welcome to the show.

[0:01:49] AE: Thanks for having me.

[0:01:50] KB: Yeah, I'm excited to dig in. Let's start with you. Can you give us a little bit of your background and how you came to be at Mezmo?

[0:01:57] AE: Yeah, absolutely. My background at my core is I started my career running systems in a lot of different forms, both at enterprises, small companies, both as a practitioner, as well as in the ecosystem at various different companies across cloud, infrastructure, observability, security. My view on the space is primarily from an operator, or an SRE. Back in the day, we call them sysadmins, right? Over the last few years, I've been heavily involved in the AI ecosystem, especially around agents. Here at Mezmo, what I'm focused on, I head up our product team and we're small but mighty team that's very focused on building, really the ecosystem around how we enable SREs, platform engineers, really everybody in operations to gain the same benefits that we've seen with coding agents over the past few years, for how we better use them to reinvent how we build, maintain, troubleshoot everything around production.

[0:02:57] KB: Nice. Can you give us, actually, just that quick, high-level, what is Mezmo? We're talking a lot about agents, and we'll talk a lot about agents. But Mezmo is a company. What do you do?

[0:03:08] AE: Yeah. When you think about what the software factory is that a lot of folks are talking about right now, usually that's around, "Hey, how do I use something like a coding agent to build software faster, test it faster, and get it to production faster?" What Mezmo is focused on as a company, and we have a long past around observability, making observability really useful, really honed in on making it a next iteration of how we use observability, where we've really focused our time within the last six to eight months or so, is really around how we take it a next level further, right? 

When we think about how things like observability as a good anchoring point change in the land of agents, well, not only do you need agents that know how to handle that observability, but the observability systems look a lot different, right? Instead of an agent looking at a dashboard, it's going to prefer the raw data. It's going to prefer insights. It's going to prefer specific tools around how it uses that data. When you think about the mission of Mezmo, we're really looking at the latter half of the software factory, right? Creating that software factory and ultimately, the dark factory for operations, not just how we get software into production, but how do we really change the entire lifecycle around what does it mean as an operator to make sure that that software is healthy, to make sure that that software I can optimize performance, I can optimize cost.

There's a big topic that I bring up a lot, which is like, what if you had an SRE with an empty DR key, what would they do? There's a lot of things that fill that particular topic. At Mezmo, we're really focused on not only building the agents, but building the operating environment, building the ecosystem for how we enable teams to do that today.

[0:04:51] KB: Totally. I feel like, yeah, as we automate more and more of software delivery, that makes things like observability that much more important, because you need to be able to understand, "Hey, my agent said this was fine, but is it actually behaving? How is it going?"

[0:05:04] AE: Totally. Yeah.

[0:05:05] KB: I could see a whole company focused around agent-legible observability. You went more than that. How did AURA come into, and maybe just a very high level, what is AURA and how did it come out of what you're working on?

[0:05:17] AE: Yeah, great question. When we first started to go down this path of the next iteration of observability, when you think about how do you distill patterns and logs and traces and metrics, we focused on initially, like most folks, exposing our MCP server in a way that people could consume it through agents. That meant that instead of your agent consuming an entire, say, hour of traces, or week of traces, which would immediately bloat the context window, we wanted to make sure that that was tailor-made for agents being the primary consumers more than humans in the long term.

Now, where we saw some problems internally, as well as how folks were consuming that MCP server, is that SRE workflows look a little bit different, right? When you think about the types of workflows, the types of context engineering, the types of human in the loop and what that looks like for things like coding agents and things that are just building and testing software locally, or in a controlled environment, that looks a little bit different than some of those problems. Like I mentioned, that you have an SRE handling a large swath of data in front of them, or hurt to figure out, "Hey, what's going on?" There's a lot of looking at graphs, looking at dashboards, looking at all these different pieces of information.

What we saw, again, from our own experience, as well as various different partners in the space, is that what folks typically were doing is they were taking a very general-purpose, very unopinionated agent framework, and trying to put together that framework in a way that, "Hey, I can do some pattern recognition on logs. I could do some pattern recognition, or RCA on traces or metrics, or something like that." Really, what's interesting about why we went down that path initially is we really just wanted the outcome of getting better RCAs, faster RCAs, be able to troubleshoot our own systems better, use that internally better. What we found was our experience of going through that journey and some of the folks that we initially partnered with were very similar to a lot of the things that we've heard from various different SRE teams and platform teams in the space.

It's like the building of agents, especially for managing production is very much the iceberg analogy that we've seen for a lot of different things, like Kubernetes, like cloud, etc., where everybody's thinking about the tip of the iceberg and like, "Hey, how do I just take a model, wrap it in a simple agent framework and give it a prompt?" In reality, there's a lot of things that are needed to actually make that reliable. How do you make sure that the model can consistently call tools and that those tools don't just randomly fail? Or how do you orchestrate something fairly complex, like a multi-agent workflow, without making somebody get dragged through glass to get to that point, where they're able to actually realize that outcome of solving that use case?

Again, when we saw that with operations workflows specifically, we just saw more and more of that upfront effort in order to make that reliable workflow. It was really hampering people's ability to be successful with those frameworks. We really just wanted to shorten the circuit, right? That's really going into where AURA came into play is it was our own learnings. We looked at a lot of different frameworks and harnesses at the time in the space, and a lot of them were focused on either being insanely general purpose, one harness for everything, one framework for everything. They typically didn't make those hard things, like I just mentioned, very easy. There were a lot of Lego blocks that you had to figure out what the Death Star looked like at the end of it.

What we wanted to do with AURA was like what the experience that a lot of SRE teams, or platform teams, are familiar with, which is like, hey, if I'm deploying something in Kubernetes and I do a Kubernetes deployment, well, I tell Kubernetes what the outcome should look like. I don't necessarily need to tell it imperatively every single step that it needs to do to manage those workflows, scale out those workflows, ensure that it's reliable at the end of it. We wanted to 

create that same type of experience for how ops teams built and, manage and maintains agents. Again, shortening that process to getting to the outcome and ultimately making it, so that the tools that we expose, like our own MCP server and others, just become much more valuable, because you can get your outcome closer to day one than if you were to go through that process of building all the individual pieces that are frail and have the tendency to fail on their own. We wanted to make sure that that was a not only a shortened workflow, but a very reliable workflow to get to that outcome.

[0:09:44] KB: Yeah. There's a bunch in there, and I'd love to dig in a little bit. Let me pinpoint one of those things, because you mentioned SREs are used to working in something like Kubernetes, which is essentially a declarative environment, right? I declare my relation to my objects. I declare their relationships. The system is responsible for bringing them up, making sure that they get into that state, and getting there. Talking about that with regards to agent definition is fascinating to me, because I think most of us are familiar with coding agents of different sorts. It's probably the most widely spread agent harnesses out there are things like cloud code and that sort of thing. There, I think a lot of us are still being pretty imperative. We say, "I want this. I want that." What does it look like to have a declarative agent definition?

[0:10:27] AE: Yeah. I think the proof is really - the benefit of us open-sourcing AURA is that you can look at the repo. You can look at exactly what the examples are. We operated very much on a lot of the Linux fundamentals, or philosophies of having things like same defaults, where A, if I don't need to tune every single part of the process, I can operate on the default built into the system. At the same time, I have the ability to tune the reasoning budget, tune the quality score, whereas the agent is maybe executing its tools, or going to an end state and trying to solve a problem, like how does it self-evaluate itself and self-correct itself as part of that loop?

Also, enforcing the loop itself, right? Ensuring that we were opinionated on those things underneath, but also gave the folks that were using AURA the ability to customize them if they saw fit. Again, it's the same thing with the Kubernetes manifest, right? I may just want to deploy NGINX or Redis, and that may just be all I need to do, or I may need to scale that out. I mean to do a bunch of different pieces along the way in order for that to be very tailored to what I'm working on internally to my workflow. We wanted to do the same thing for agents.

Again, when we looked at the ecosystem, there were different ways of defining the agent in a framework. There were different runtimes. There were different pieces along the way that were very unopinionated and very much like, hey, you can do this. You do a little bit of anything. Again, with the types of problems that we were seeing with the industry, we wanted to really just operate on the path of like, hey, you can start using AURA. You can pick up our container tomorrow. You can run it in your cluster, or even on your laptop and give it a simple config file. That's also the beauty of AURA is when you look at how you build these agents declaratively, again, going on the manifest ideology here. We use a simple TOML file, and in that TOML file, I define the agents, whether I'm saying, "Hey, here's a simple agent, maybe with one tool, and maybe that tool is my observability tool, maybe that tool is my cloud provider." And a simple system prompt that says, "Hey, what should you do or what should you focus on?"

But I don't need to define, again, the reasoning loop. I don't need to define the self-correction loop. I don't need to define anything along the way. As I'm starting to get into some of these more complex things, where, hey, maybe I'm dealing with a tool behind that agent that I know is going to return a lot of data. Maybe there's different MCP servers. For example, the Prometheus MCP server. I'm sure a lot of people have tried to use that MCP server. You just end up getting this context bloat of every possible things that's returned by that MCP server. Again, where we wanted to make things easy was we introduced different concepts along the way, like, for example, Scratchpad. Scratchpad is something that's built into AURA natively. It's something that you could very easily turn on with a single line in that config file and say, "Hey, start using Scratchpad."

Basically, what it does is it acts as a layer in between the tool and the model to give the model the ability to interact with the outputs of that tool via a simple file on disk, and then ensures that it'll look at whether or not that tool needs to be recalled, whether or not you can respect the previous tool call, like how you can share that tool call across different agents. Again, it was really operated on that idea of same defaults on day one, make it really, really easy to get it started, but also get it running and ultimately, achieve the outcome. But also not alienate folks that really cared about tuning every part of the process along the way.

That's actually something probably worth calling out is like, when we also looked at folks in the space, especially a lot of commercial solutions, or things that are built into the various different ops tools that people are using today, there's an embedded agent inside of anything. A lot of those were black boxes. One of the really important things for us in our day one opinions on how we've built and released and continue to develop on AURA is really that we wanted to make sure that all of those things that we're doing are fully transparent to the user. You can not only see what they're doing, you can interact with it; you can tune it. Transparency on day one was also an incredibly important thing for us along the way.

[0:14:40] KB: Yeah, that's super cool. I mean, even just the tiny example of Scratchpad is really nice, because I feel like I operate a lot in coding agent land. It's like, you learn these patterns of, oh, let's dump this to a file and let's interact with it. Or, oh, let's dump this into a SQLite database and then query it, rather than just raw, putting everything in context. When you find those patterns, if you make it easy, declaratively just say, "Hey, agent. Here you go.  You know how to use it. Run with it." It's really powerful.

The target with AURA is this is an agent framework for SREs, for production use, which is, once again, different than most of us first encounter agents nowadays in coding agents or things like that. Maybe we're building our own somewhere. But let's flesh out a little bit more of those differences. We talked some about the declarative versus imperative. What are the other big differences in building an agent framework for a production environment for SRE, as compared to I'm running this as a coding agent on my laptop?

[0:15:40] AE: Yeah. There's really three big things that I look at across the landscape of what does it take to have a really successful SRE agent for any team. A big pillar across this is, is how we handle context engineering. Again, when teams are just picking up a framework and just putting a model and putting a simple prompt, oftentimes, they're not thinking about context engineering on day one. Folks that maybe aren't super familiar with context engineering, we always have the limitation of any model, big or small, is the context window, right? We're always operating within that context, and I'm sure many of your listeners know about this, but just to be verbose on that topic.

In reality, operating within the context window, it can be very simple for very simple use cases, right? It looks very different for things like coding agents where, hey, the context window is just maybe the code, or the understanding of the code base that's right in front of me. But for SREs, that context engineering looks very different. When you think about the amount of runtime data, everything - understanding the code, understanding of the infrastructure, understanding of a lot of the observability data, like traces, metrics, logs, etc. You can't just say, hey, go give me the last week of traces and logs and metrics, and I'm just going to shove it into the context window and hope that the model not only has the ability to have all that within its context window, but also doesn't hallucinate along the way, right?

The thing about context engineering for these types of workflows is they automatically become at scale, typically because of the nature of us operating this in production; we're dealing with scale, and those don't present themselves on day one. Context engineering is a really big pillar of that. The other piece is really like, how we handle things like multi-agent orchestration. When you think about some of the advanced patterns that are starting to pop up that are becoming really useful in this whole agent ecosystem is like, hey, how do I have - as part of any different type of agent, maybe that's an agent that's doing root cause analysis, or whatever, like I may want different agents focused on different tasks that can collaborate with each other. That's going to look very different in different types of use cases.

Maybe I want a security reviewer. Maybe I want somebody who's just focused on investigating the cluster, just focused in on investigating the code base. That helps me to do this in parallel, so it's actually a lot faster to do that. It also makes sure that each one of those agents isn't dealing with, again, a single context window as its limitation across the way, right? Orchestrating multi-agent workflows is typically a non-trivial thing and pretty much any harness, or any framework. Again, that's usually a day three of if anything, maybe a day four type of problem that not everybody's thinking about on day one. And so, it's really limiting them the ability to gain those benefits until they've actually hit the problems with what they're doing in the simple agent, or maybe the simple agent plus one, or whatever. We just wanted to make that, again, very easy to solve on day one, because we believe that the nature of these types of production SRE workflows benefit a lot from this orchestrated multi-agent workflow.

Then the last one is: how do we handle things like human in the loop, memory, things that are opinionated to the task? Again, that's where we think about what memory looks like in coding agents, what memory looks like for pretty much anything else. It's very general. It's very like, you can have the agent provide memory. Then the memory system is either just a simple graph, or maybe it's just a simple collection of summarizations across the context window. Whereas what you would want in an incident investigation is really a memory system that's looking at the context of, "Hey, what are the previous incidents that I looked at? What were the previous resolutions to those incidents? What happened along the way?"

This is also another problem that is unique to these SRE workflows is really, how we handle those longer-horizon tasks, those longer-horizon things that the agent is dealing with. Then the last piece I'll just highlight as part of that is things human in the loop how we have agents that we can give a little bit of autonomy or a lot of autonomy to, right? We believe that should be not a either or, but really a graduated process, where maybe you want to start with something that looks more like a Copilot, and then be able to very easily grant some more autonomy where it looks a little bit more like an assistant. Then once I truly trust that assistant and I actually want to change the way that I'm running production to really be agentic and really be autonomous, well, then I want to graduate to more of that autonomy that looks like, really, that dark factory when we feel we're comfortable with turning off the lights.

We wanted to make sure that AURA took in all those different concepts that I mentioned and just make them available on day one, and something that we have our opinions baked into the harness. At the end of the day, you can plug that harness into our tools; you could plug it into your own tools, your own observability systems, cloud providers, etc., behind the scenes, and really provide that for the community to build on as a common set of practices that we believe will enable this industry to move forward.

[0:21:01] KB: You have highlighted some of the key things. It's okay. I'd love to dive of another level of detail deeper on probably each of these. The one I want to start with is orchestration, because I feel like this is a problem everybody is trying to figure out right now in different forms, or another. You have people building their own orchestration frameworks. You have it being built into different things. First, from a developer experience standpoint, what does orchestration, or multi-agent, look like in AURA? Then maybe we can peel back the hood a little bit and just look at what are the primitives? How is it built? If I wanted to customize it, what would I plug into?

[0:21:37] AE: Yeah. The way that we handle orchestration is meant to be as simple as possible. There's a lot of different things that folks can customize. Again, if I just picked up a general-purpose framework, like LangChain and said, "Hey, I want to do multi-agent orchestration." Well, I'm thinking about the type of reasoning loop. I'm trying to think of the type of retries, or resiliency across the way. The way that it looks like within AURA is, again, that simple TOML file that's driving the whole process; I define an orchestrator, or a top-level agent. That agent is very simple. It's anywhere from five to 20 lines of how detailed I want to be on my system prompt. Basically, that's the majority of the context there. Then I basically just note that as my orchestrator agent.

Then, what I can do is I can define various different workers. Again, just another subsection of the TOML file where I'm saying, "Hey, this is a worker that is named this, and I'm going to give it this description and this preamble." I can also limit its tools, so I can give it access to everything. Or I can say, "Hey, these are the tools that I just want this worker to have." Thus, again, limiting some of the potential of context bloat, or limiting the ability for that agent to be really good at one task. Again, it can look basically as simple as that, where I define the orchestrator, I define the LLM that I want to use, I define the workers, and everything behind the scenes is actually driven by AURA out of the box.

I'm not having to think about how the orchestrator is going to handle its planning, right? The first thing that the orchestrator will do is create a plan, create a go-forward. Like, what am I going to do? How am I going to fan this out? What workers are available to me? It's going to go ahead and provide that to the workers, where it's basically going to go into an execution mode. Then it's going to go ahead and self-evaluate. As I get the results from those workers, hey, do I have enough of a confidence that will actually sell for itself along the way and say, "Hey, this is a confidence I feel comfortable with moving on to the next step."

Or, you can make it either very high of a quality threshold, or very low, depending on what you want to do with it. Typically, we see 70% confidence is what we see a lot of folks define initially there. I'm not having to think about how the tools are provided to those sub-workers. I'm not having to think about how that planning and self-correction loop is defined for the orchestrator. I'm not having to think about how the orchestrator provides the relevant context to just the workers that it's currently -

[0:24:02] KB: That was what I was going to ask about is like, what is the communication path back, forward and back? Is it just dumping files in place for them? Is it standard in and standard out? Can it hand off more complex things? If I have a sub agent that pulls together a database for me, can I hand that to a different sub? What are the tools available in the tool chest?

[0:24:22] AE: Yeah. We go for a single path in, single path out for right now. That'll change as the harness develops. It's meant to be, hey, the orchestrator does the planning and then hands it off to the workers, and the workers hand it back. Then the orchestrator can hand it to different workers if it determines that, "Hey, I've built some context, but I need to clarify it. I need to get a little bit more context, execute another tool, or maybe execute the same tool again, because it didn't give me the result I was looking for." The orchestrator becomes the important part of that process. But the thing that we're starting to see more and more of is these multi-agent workflows; they have a lot of tendency to become really complex really quickly. And so, we wanted to make sure that was simple on day one, but as we see more and more of these patterns emerge, we definitely want to make sure that AURA enables you to gain the benefits of either performance or reliability out of what that orchestration flow looks like.

One thing I'll also call out with orchestration, which is pretty interesting, is that when you think about how you are gaining better economics out of the tokens that you're using in some of these workflows, again, you're dealing with scale. And so, you want maybe the bigger model. Maybe you want an opus on how you're doing the planning and the reasoning in the top-level orchestrator. But then, on those sub-workers, you can actually declare a different LLM, a different model behind the scenes that operates as more of a delegated task worker, right? Like, hey, maybe I want to use Haiku. Maybe I want to use an open-source model. That actually is also something that AURA makes insanely easy to do using our declarative format, so that you can say, "Hey, I want to not only use a multi-agent workflow, but I also want to use smaller agents for the workers and ultimately, get better token economics out of the whole process." 

That's one of the things that we solved on day one that we've seen some pretty surprising, pretty exciting results out of just enabling that to happen and embracing the idea of a multi-agent system with a lot of different models in the mix.

[0:26:17] KB: Totally. Yeah, there's a lot of classic data categorization, extraction, etc., that is trivial to do with a small model. You really don't need to throw up and set it. You want that as a sub-piece of your broader thing. Yeah, making that easy is super helpful. To play back, making sure I understand, you're right now operating on single orchestrator set of available workers; the orchestrator is deciding what and just spawning things out. Then it can dynamically decide, "Hey, I got this from here, but actually, I want to send it over there," doing things. But it's single level of delegation.

[0:26:51] AE: Exactly. Yeah, exactly. To your earlier point, too, we're making it as simple as possible. A lot of our interactions are just utilizing flat files on the system. That's something that pretty much every LLM, every agent is good at interacting with is a file on disk. No, we're not introducing a lot of custom process. We're operating on the simple, most reliable thing that, when breaks, you know why it breaks. Ideally, it just doesn't break, because it's a simple enough mechanism.

[0:27:18] KB: I want to come back to talking about memory and human in the loop, because those are interesting. But that points in another direction that I think is really interesting to explore, which is the observability of the agents themselves. We've been talking about how you're using these to tackle observability data and things like that. But what tools does AURA have for making it self-observable, so that, as you said, when it breaks, you can tell why it broke and how to fix it.

[0:27:42] AE: Yeah. Being an observability company. This is one of the things that we made a very hard requirement for us to solve, basically, even when we didn't GA AURA when we were in a pre-release, an early access type of thing. We instrumented everything in AURA natively with OpenTelemetry. We're heavily invested in OpenTelemetry for the agents. We define everything. Again, in the README, you can see exactly how we're instrumenting that, what pattern we're using for OpenTelemetry, which we're built on top of Open Inference for OpenTelemetry. You can see exactly in the spans of that trace of the agent interaction. Hey, how is it doing the reasoning for the next step? Was the tool call successful, etc.? We organize that automatically, and we build on top of OpenTelemetry to make that happen.

The other thing that we have natively built into AURA is a really rich set of server-side events that can be returned back to the client that can really show you what's happening live as part of the investigation process, or what is the agent doing behind the scene? Definitely didn't want to get to the point where it's like, hey, I give this really complex task to maybe a multi-agent workflow and I just wait on the spinner, or anything like that, as that's executing. We have a CLI built into AURA, so you can very easily just start interacting with the CLI. It'll very easily show you all those different events that I just mentioned, so you can do /stream, you can do /expand. It'll show you, like, hey, what are all the activities that I can see from the agent happening behind the scenes as I'm interacting with it?

Then because it's built on top of OpenTelemetry, I can send that to my observability system, and that makes it really easy for me to understand the auditability of the interactions from the agent: what did it actually do and why, right? The reasoning steps across each process are also captured in that trace. We just wanted to make sure that when it's built on open standards, you can send it to anything that supports OpenTelemetry, and it becomes a great way for you to start building trust in your agents. Again, this is a big barrier in the industry, I'm saying, is that for SREs, anybody who's dealing with a production use case, you really have to understand exactly what's happening behind that agent in order to trust it. Otherwise, you're not going to put it into production. You're not going to offload more tasks to it. You're not going to really integrate it into your workflow. The observability or the transparency of what's happening behind the scenes, that was a insanely important piece that we wanted to solve on day one.

[0:30:09] KB: One of the big patterns I'm seeing right now, once again, doing the metaphor to coding agents, because that's where I live a lot of my time is looking at traces, essentially, of how are things going and using that to iteratively improve. If you're talking about an observability agent, or an SRE agent, it needs the same thing. But you can't just be looking at files on your laptop anymore. You've got to have those deep observability traces.

[0:30:31] AE: Totally. Yeah, exactly. Because we're built as an observability tool, our platform enables you to send those traces directly to us. Obviously, we have the ability to pull those in, visualize those, show you the different service mappings and the interactions. Most people have an observability tool in place. And so, it's easy for you to take AURA and just point to whichever OpenTelemetry provider you decide to use; the visibility that you're going to get into those workflows is not going to be limited to you using our commercial product.

[0:31:00] KB: Let's come back and talk a little bit about memory, because I think this is also a really interesting domain, and I'd love to get, once again, one or two levels deeper on how you approach it. As you commented, a lot of memory implementations out there are pretty naive. I'm going to use an even simpler example. You look at ChatGPT memory, or something. It remembers everything. It doesn't give me any visibility into what it remembers or why. When I'm working on something for my son's project, it says, "Hey, because you're a director, or you're a VP of engineering, you should be thinking about it this way." It's just this one big undifferentiated mess.

Obviously, that's not what you want in a production SRE context. You mentioned examples of exposing incident logs, or incident histories and things like that. How does your memory architecture work? Once again, first from a user perspective and then diving in under the hood?

[0:31:55] AE: That's a good question. A lot of this, you can actually see in our PR, is how we're developing the next iteration and what we're already starting to improve within AURA. The way that we look at it is there's different levels of memory. There's memory, like more turn-based or session-based, basically, that you want the LLM to be able to recall what was the last tool call that happened on the last couple seconds, right? Or what was the previous run of this agent able to come to as a conclusion that maybe is right in front of the agent at that moment. That's more of the turn-base, or session-based memory, which is the lower levels of where we want that really fast.

When you think about memory architectures, having DDR is like my RAM versus a hard drive versus something that's a offsite storage. We took the same approach with AURA, where there's very simple memory that's built for turn-based and session-based that again, you can tune along the way. Then what we're looking at, like the really interesting problem, is when we start to get into some of those longer-horizon memories. This is actually where we are working on this within the platform itself, within the Mezmo platform, to offer this as something that is a little heavy to do in line, but it's actually great to do as an async or background process that just gets exposed to the agent that it doesn't have to waste tokens on.

This is where we're looking at, like again, more of the needle in the haystack, incident over incident investigation, but tailored to the types of workflows that SREs would deal with, where those memories are not just about the last tool call, or the last iteration of this agent running, but it's like, hey, what happened in the last six months? What happened in the last 12 months? What happened with this service that I started to see, maybe a little bit of service degradation and also a change that somebody pushed from GitHub and also started to see some funky stuff in the logs, that all becomes a collective memory that we're creating as a simple briefing to provide to the agent. That just makes it easier for that agent to either solve the next thing the next time better, or potentially just short-circuit the process entirely and say like, "Hey, normally I would come to this conclusion of doing this next thing. But I can see the last time I did this thing," and I can compare that to ground truth in the background. I can validate whether or not that had the intended impact that I needed. Maybe that'll change what I do the next time that this happens, because now I've actually evaluated that in the background. That's where the longer-horizon memory is, something that we're very interested in.

Because again, if you look at just taking either the graph, memory MCP server that most people are familiar with, that you can just grab off of at the standard MCP servers, or something like Mem0, or MemPalace, or any of the very general MCP memory servers, we wanted to make sure that that was again, shortening the circuit to the outcome, or shortening the path to the outcome, where we know the types of tasks that SREs need to solve for. We know how memory becomes really important to some of those longer-horizon tasks. And so, we're just going to provide that on day one.

[0:34:54] KB: What does that end up looking like technically? Is that a kind of rag-like implementation? Is it exposed via another MCP, or it's a separate tool that you can query? How does that end up actually playing out in the agent?

[0:35:10] AE: Yeah. The way that we're exposing it today is just taking the simplest, again, lowest common denominator across the board, which typically ends up being another tool. The way that we look at it, we call them investigations. As I'm handling either a new investigation or looking at previous investigations, that's just another tool available to the agent that we exposed through our MCP server. How that practically looks is we're providing a briefing as part of that tool call, so it's the summary and then where the agent can go for the next steps, something that again, because we're focused on building on top of these lowest common denominators in the space, which a lot of this looks like just an MCP tool, you could plug what we're doing in the background for memory, or what we're doing in the background for context engineering, like longer horizon things into AURA. That's what we see is a great path to consume that.

You can also plug it into - you've already invested in that agent framework that you've already gone through the glass to get to that outcome that we were just talking about before, or you want to plug it into Claude, you want to plug it into wherever, you can easily do that. We did experiment with a little bit. Again, you could see this in our PRs, doing things like providing a virtual file system to the agent, where we can feed in those memories without the agent actually having to do the tool call. Some of that's in an experimental phase, where we're looking at how can we better expose these memories that don't actually require the agent to do a tool call and is rather just transparent to the agent, where it's not wasting tokens. Some of that stuff is in a research preview. Again, you can see that in our PRs and follow along with that.

[0:36:42] KB: Yeah. No, it's super interesting. Maybe this connects a little bit to the context engineering question, right, of what sets of things do you want to embed in your initial context, so it just knows it? Versus make it on demand, go and call it, versus, yeah, have it in an explorable database, or find some other way of finding it.

[0:37:03] AE: There's also one last thing that I want to make sure I also layer on here that's related to memory. We don't always call it memory, but it's on the same exact path. Which is things like institutional knowledge, right? More of the institutional memory, or institutional knowledge, right? Where, for example, every SRE team has a set of runbooks that they have internally. Maybe that lives in Confluence. Maybe that lives in GitHub. Maybe that lives in insert your favorite place to store runbooks. That becomes incredibly useful grounding for the agent. We also expose a really easy way for you to either connect us to where those runbooks are currently stored, if they expose something like a vector database, it's really easy to plug that in and use that as grounding for the agent, so the agent will always ground and respect itself based on, or respected the workflow based on what you've defined as the source of truth being your runbooks.

We've also actually published a blog post on, like, hey, if the agent has the ability to not only consume those runbooks, but as it starts to see things during its investigation process, how can it actually contribute back, and we've published a blog post on this, how we're actually doing this internally, where we have our runbooks stored in GitHub. We actually use AURA for a lot of our own SRE workflows internally. As we identify things that hey, this workflow has changed based on what's in the runbook. Instead of that becoming a human process, where somebody's maintaining the runbooks and it's only a one directional consumption by the agent, we've actually seen a ton of really positive success with providing the agent a feedback mechanism to basically iterate on those runbooks, open a PR and say, "Hey, I did this investigation and I need to update the institutional knowledge." That's just a really good example of the opinionated memory, where everybody has institutional knowledge in somewhere, or form.

[0:38:52] KB: Yeah. Well, I love that, because it closes the feedback loop. And it gets us to the last pillar that you talked about that maybe we want to dive into, which is the amount of human in the loop you have. You described here a version of human in the loop, which is I did a whole bunch of stuff, but here, let me suggest to a human in improvement. Yeah, how do you think about - you mentioned, which I love, this idea of having the gradient from almost entirely human with Copilot going on to completely automated. But what does that end up looking like? How do you end up configuring it in AURA, and where do you see different types of SRE tasks typically falling out in terms of that level of autonomy, versus human-run?

[0:39:35] AE: It's interesting, because the way that people are looking at human in the loop today is very dependent on the types of systems behind what the agent is interacting with. That's one parameter, or one dynamic. There's also, like, how confident are you in the workflow itself? Then there's also like, how confident are you in the data that has been returned through the workflow? There's an aspect of how you provide the ability for somebody to say like, hey, these types of tools, which maybe are read-only, or sorry, write, they have the ability to write, or they have the ability to do something that - it's a one-way door, right? I want to make sure that I provide a very hard barrier for the agent to be able to know that that is something that's insanely sensitive, and it needs to ensure that it asks for help before continuing on. That's one piece that we see everybody with some level of, like, hey, there's remediation, but I need to make sure that there's always a human that hits the go button before it does remediation, because I know that that's a one-way door that's really hard to come back from. That's one aspect of limiting, or providing human in the loop on the tools themselves.

Then there's like, how far do you want the agent to go in the process before ask for a person to let it continue on with go, right? Maybe you're not limiting access to the tools themselves, but you're limiting access to how far in the process the agent can get to, right? You can basically act as an assistant, but at the end of the day, the person who is implementing the remediation to what you've investigated is always going to be a person, I'm not going to provide you those types of tools and it's always going to be you're read-only, you're only getting me up to the point where you're creating a nice package for an SRE to go execute a script, remediate a problem, but you're coming to exactly what needs to happen before that point becomes a simple place for the agent to either determine that it needs to continue on, or just completely hand off the process.

Then the last one is where we start to really get into, I think, the true benefits that people are looking for, which is when I'm thinking about a truly autonomous workflow, where, hey, instead of SREs handling this N10, it's actually an agent handling this N10, that's really where we start to get into an aspect of, hey, how do you use some of the data that we were talking about before with the observability data, and grade that over time, where even if you think that that's a pretty good workflow and you have the right data and you have the right workload to find, you want to make sure that it is tested a certain amount of times before you give that the full thumbs up, continue on, operate autonomously, right? That's the graduation process. There's those three different areas there.

Now, how that looks specifically within AURA, it's all driven through the config file. Where it looks a little bit unique is, as soon as we start to get into those longer horizon things, again, where it's like, hey, I'm not just limiting access to the tool itself, but I'm telling the agent where it needs to go ask for help. That's where we're exposing a tool within our MCP server to basically provide to the agent. So, the agent doesn't need to go figure out, "Hey, you've told me that I need to go ask for help here, but I got to go figure out who's on call. I got to go figure out how to get access to Slack. I got to go figure out how to do X, Y, Z." Instead, what we're doing is that's a process that we're seeing across a lot of SRE workflows that needs to happen. We're just exposing a simple tool for the agent to be able to ask for help.

Then what we're doing behind the scenes is some of that correlation that I mentioned: hey, who's on call? Who do I need to go ask, trigger notification via Slack? Somebody give me the thumbs up, and then provide that to the agent, versus the agent again, having to do that itself. That's how we're not only defining the different types of human in the loop in the process, like governed autonomy is what I think about it, but also, make it so that our platform provides the simple mechanisms for the agent to ask for help from a single place without having to blow a bunch of context to go figure out all the possible places that it could go ask for help.

Like I said, the way that we operate with doing that, more is open source. We always expect people to be able to use AURA with or without Mezmo. You can definitely point AURA at a different tool. That's a different human-in-the-loop process. And we publish the spec there of, like, if you wanted a different human-in-the-loop process, here's how you can do it. Here's how you can define it. Then we operate on, hey, we open that spec. We've defined that spec. But then, for the actual implementation, okay, great. We're going to make the simplest path for you to realize that implementation, which ends up being just, hey, our MCP server is going to naturally provide this to you on day one, so you can consume it right off the bat.

[0:44:16] KB: Yeah. Well, and I think that's a really nice way to have a pairing between a commercial product and open source. If you say, like, look, all the doors are open. You can do all the different things. Here's some things that we know you're probably going to want to solve a lot of times that we solve well for you. Here you go. That gets into an interesting question around the future of AURA and in particular, around governance, right? Right now this is a Mezmo-run project, and you all are doing most of the work. Are you looking to get it into third-party foundation? Or, how are you thinking about governance of AURA going forward?

[0:44:50] AE: Yeah. Right now, AURA is a small but mighty project. I say that because the primary contributors are from Mezmo. We're starting to see more and more people interested in the space. The fact that we've gone with the Apache 2 license makes that a lot easier for folks to be able to contribute, without having to jump through a bunch of hoops. We're a member of the AAIF, so the agent foundation that's underneath the Linux Foundation, and we're active contributors there. There's definitely a future here where I think, as we start to get more and more interest in AURA, we have no intent of this just being the Mezmo way to run agents. We want this to be as general-purpose a best-practice standard in the industry.

I think, not to put the cart before the horse, because we still want to get as much proof and partner with as people as closely as possible, where we can very quickly make iterations where it makes sense. I think as it starts to mature as a project, definitely makes sense for potentially contribution to, I think CNCF is probably pretty crowded, but the great thing about AAIF is it's fairly new, fairly green field, and there's a lot of folks that are interested in moving the space forward through that. Definitely looking at that as a good option potentially in the future here.

[0:46:00] KB: Yeah, totally. Well, and I think it makes a ton of sense to keep it tightly controlled to start with, right? I've definitely seen people try to open things up a lot too early, and it leads to chaos oftentimes. The benevolent dictator for life, even if the dictator is a company, that's a good way to start a project and keep it moving. If folks have not used AURA, they are curious, they want to get started; maybe they want to try contributing or tweaking it. What is your on-ramp? What do you recommend?

[0:46:29] AE: Yeah. One, we have a Slack community. Everybody from Mezmo is there. You can get help if you have an idea. We're very interested in fielding what people want AURA to look like in the future and what ideas they have in the space. You can definitely open an issue on the GitHub repo, like you can for many things. PRs are definitely welcome as well, if you're interested in donating your tokens, right? We've tried to make that as coding agent friendly as possible, where we're heavily leaning on the Claude MD and Agents MD and things like that.

We're trying to make it as easy for folks to contribute to. But then, again, that Slack community is a great place where, like, if you don't know where to get started, or you're having some problems, or you just need a little bit of help, or have some questions, pop into that community and very interested in helping where we can. We're also very interested in partnering with people. If you're looking at how you want to change the future of SRE and you're aligned to this conversation that we just had and you want to partner with a company like Mezmo that's looking at building this firsthand and we have engineers actively working on this, definitely reach out and we're happy to provide any support, or implementation, things like that to make sure you're successful. A lot of different paths based on just community contribution versus true commercial partnership and design partnership there.

[0:47:48] KB: Yeah. I love that you're doing an agent-friendly open-source project. I know a lot of open-source maintainers have been resistant to agentic coding. But having that first and figuring out how do you design your workflows and your processes and your automations and everything to make that friendly, I mean, to me, that feels like what makes sense in this world we're now in.

[0:48:10] AE: Totally. Now we're in this point where the code is cheap, but the ideas are expensive, right? It's like, the easiest thing for us to do is make that process as streamlined as possible, right? We know that coding agents are the future and they're here to stay, and it actually lowers the barrier, right? There was a while where in order to contribute to an open-source project, you had to really be in-depth in that project and actually understand what's happening. Maybe be an expert in Go, Rust, or whatever. Because AURA is written in Rust, not everybody knows Rust, and we totally understand that. But every agent knows Rust, right? Anybody who has access to Opus, or any of the coding agents, right? You have an expert in front of you, and you have your tokens. Now the donation to open source becomes, hey, if you want to donate your tokens, these projects, like ourselves and other folks in the space, we just need to make it as easy as possible for you to do that.

[0:49:01] KB: Well, I realized we're getting close to the end of our time here. Are there any things we haven't talked about yet that you think would be good to talk about before we wrap?

[0:49:10] AE: There's a concept that we're really keen on advancing in the industry and how we operate as Mezmo, which is, there are two axes in the space, right? There's what production AI looks like as far as AI in production and all these things we're talking about, right? Like, multi-agent workflows. There's how you reliably tell tools. There's memory. There's things like that. That's all like, how does an agent operate well in production? Then there's another axis, which is AI for production. That's where you think about, like, what are the types of tasks? What are the types of skills needed? What are the types of tools needed that really enable these agents to handle these types of tasks that we see high-value, and something that's inherently hard to solve?

We think about production AI and how we're trying to shape the industry around, like, this is a problem. It's really the intersection of those two things, where we want to enable SREs to not only own their own agents and go through this process safely and reduce the risk to get to the outcome, but what we see as a healthy side effect, which I personally am really excited about just from being a practitioner earlier on in my career is really, this is our mechanism to also elevate the whole role of what SRE means, right? Where we're architecting reliability, more so than responding to things that we've implemented. We're taking more of a design approach for how we can make systems reliable, more so than being firefighters all the time. I think that's a really interesting opportunity that we have to move the space forward. Like I said, we're really excited about where this is already starting to show success and where we see this advancing in the next months and years and things like that, that really bring all the SREs today that are used automation. They're used to handling these really high-risk scenarios and just giving them the tools and the ecosystem to make that ready for the agent era.

[0:51:04] KB: I love that. It fits really well into something I've seen in a bunch of AI spaces, where a lot of people are trying to delegate their thinking to AI. But where it really shines is when you can use AI to elevate your level of thinking and really do something that's more impactful, deeper, more just leverage all of those different things. Can you maybe pull one example out of how using this at Mezmo has helped you elevate your SRE approach?

[0:51:32] AE: Yeah. One is, again, we've taken the approach of making it less like a firefighter and more like a reliability architect. All of our SREs, we have all of our engineers on call as well, right? We take the approach of the SREs are the ones building the guardrails and building the systems, building the workloads, but that makes it easier for other folks to also take that pager, be on call for the systems, where all that tribal knowledge that typically was trapped in an SRE's head, agents are a really good mechanism to make that a next iteration of as code, right? Where we get that out of people's heads and make it more automated and make it more standard practices.

So, that's really helped us to really iterate internally on what's the next iteration of SRE and really use our own ability to capitalize on our own harness and our ability to incorporate our own learnings there. We really just elevated our SREs internally so much to the point where it's made the role really exciting and really given people internally the ability to see what the future looks like, which then makes them also excited to talk to other SRE teams at other companies, which has been a cool site to see is we're getting to the point where we can actually share knowledge, build a community, build these standard practices that extend outside of them as well.

[END]
SED 1945		Transcript

	(c) 2026 Software Engineering Daily	1