⚡️ Exo: Harnesses should see their own code and logs — Alex Krentsel, UC Berekeley / Google Research

Watch the full show on YouTube: https://www.youtube.com/watch?v=5lFD-34dhqE

• 0:03Speaker 00

  Okay, we're here in the Remote Studio with Alex Krentsel, a guest of EXO, but also UC Berkeley. Welcome.

• 0:08Speaker 01

  Thank you so much. Happy to be here.

• 0:10Speaker 00

  The reason we're recording is because I had to. When you showed up on my timeline, I didn't know that you had already showed up before. This goes to show you how much persistence there is on YouTube. But I actually had watched your lecture and then didn't register your name on OpenClaw.

• 0:25Speaker 01

  That's cool. Yeah, maybe I probably should have said it a few more times or put it in the slides. I was so focused on just talking about the architecture, I didn't go to pitch myself.

• 0:32Speaker 00

  Yeah, but also like maybe like your face on there, but also, you know, just like other work. But you know, that's all of a piece. Most recently, you showed up working with two of our former guests on the InSpace, Martin Casado and Ankur Goyal. When I actually talked to Martin on the podcast, he actually said that he was hacking away with you. And he didn't like, because he was like, I want coding so much. And I was trying to call out like, you know, this VC pretending that he codes. I was like, you know, what are you doing, man? And he was working on this, and now you've announced it. So I just wanted to give you the floor to talk about the EXO story. And then we can work our way back to whatever other background that you want to do.

• 1:17Speaker 01

  Yeah, for sure. Thank you. I mean, I'll start by saying, yeah, I've been building this with Martin and Ankur. They're both really excellent systems thinkers. As you might know, Martin's background is in a PhD in computer science. Actually, advised by my advisor, my PhD advisor, Scott Shanker at Berkeley. So that's kind of our shared lineage.

• 1:35Speaker 00

  Shared lineage, yeah. He was my board member when I was working at Nellify. And I was working, I was learning about, you know, virtualized networks and all those things.

• 1:45Speaker 01

  Yeah, yeah. We're kind of come from systems backgrounds. My background is fully in systems, and I'll talk more about that later. But just briefly to introduce EXO, so we're all on the same page. In a nutshell, EXO is an agent that's fully recursive. So it's able to safely edit all aspects of itself at runtime to kind of get better at the task that it's working on. And it's enabled by this very kind of minimal but opinionated harness architecture that splits out different pieces of what an agent is today into components that can be safely isolated from each other and thus safely evolved. I can talk much more about how it does this. But you should think about it as an agent that really does full recursive self-improvement.

• 2:27Speaker 01

  And I think it's really enabled today by the fact that we're we're entering a new layer in the ML stack in my mind. Where up until recently, we've still been really focused on trying to make models better at what they do. And when we say models, we're talking about the weights. We are training the model. First, it was large pre-training runs. Then it became find, kind of applying fine tuning to these models to get them good at a particular task in their thinking. I think the shift over the last year to agents has made us much more aware of the power that lies in the harness, the tooling, the body that we provide to the brain of the LLM. And the shift that's happening now is we're really entering a space where we're starting to realize that as we tweak these harnesses,

• 3:12Speaker 01

  they're going to get really good at particular tasks, either better at doing them or more efficient. So doing them with less token calls, less usage, driving costs down. Costs are a huge concern right now because frontier models keep getting more and more expensive because they're larger, they're harder to serve, they require more GPUs, et cetera, et cetera. And so the project came from, I've spent the last year or so of my research at Berkeley on discovery systems, so AI-driven discovery. This project come out of the Skylab at Berkeley called SkyDiscover. And it was this outer loop that tries to optimize and improve in a system. And what I got really curious about was, how do we take this to its extreme? You have some outer system that's optimizing some inner system. What if you want to optimize what you're doing, you're optimizing? Then you need some outer, outer loop, and it's this infinite recursion out.

• 3:58Speaker 01

  And the only way, I think, out of that is to collapse that loop down and make it so that the system itself is responsible for improving itself, which I'm calling to collapse the loop. So it's very different than having an outer observer that's looking and trying to make changes to the other system as it's running. I want the system to be able to change itself at runtime. And this is the kind of thesis for EXO.

• 4:20Speaker 00

  Yeah, and I'll maybe add a couple pieces of commentary here. The first people to realize this was probably the Py, OpenClaw people, right? Where they were like, well, the harness should modify itself to add whatever capability you need. But it is not fully self recursive in the way that you envision it. Second of all, so we can go into that, and you've already done an OpenClaw lecture, which I'm going to link to in the description, that people should see. And we can cover a bit of that if it's relevant to this conversation. The second of all is, I haven't followed this at all, for my stuff. So for my two companies, I have an internal bot that does work. And I have an external bot, Devin, that modifies the internal bot. It doesn't, the internal bot has no ability to modify itself.

• 5:02Speaker 00

  And I kind of like that separation, to be super honest, of like, okay, well, now this is like the pseudo do things, and then there's do things, and then pseudo do things, right? Like, the difference obviously is, it is not magical. It is like, you drive the car, then you open the hood to modify the car if you need. But most of the time, the hood is closed. And so then the question, the pushback is like, when do you need that AGI feeling of like, wow, it just modified itself without me asking? So those would be my two commentary pieces there.

• 5:33Speaker 01

  Yeah, they're great points. Let me touch on both. So OpenClaw came around and took off in, really took off in February. And I think you're right. The thing that OpenClaw really discovered was how to make an agentic system that feels magical in that it kind of adapts to your workflow. It is adaptable. But I want to point something out. It's adaptable in a very particular, narrow way. So if we were to go and look at the architecture, there are particular places where the OpenClaw folks in the architecture have made it extensible. Those are, one, the one dynamic way, super dynamic way is memory. And all of these agent systems have some sort of memory. Literally, it is a memory.md file somewhere. There is a markdown file that things get written to.

• 6:16Speaker 01

  It gets injected in context every time the LLM, you know, is, constructs, like, we construct a call to the LLM, and we can edit that file. That's the main super dynamic way. Otherwise, OpenClaw exposes these places where you can extend it. You can add skills. You can ask the agent, here, look, go look at this skill, please add it. You can add tools. And by the way, this is very often kind of driven by human. A human will come in and say, hey, I want a skill for this. Let me go install this skill, and then ask OpenClaw to do this. And so it's absolutely self, it's absolutely improvement and extensibility. And memory is a form of self-improvement. But there's so much more going on inside of these agents. What is an agent, by the way? I think it's worth getting on the same page. Everyone has, I'm sure your audience knows very well about agents, but having a shared definition is important.

• 7:00Speaker 01

  I think about an agent as an LLM call that is wrapped in machinery that's used to construct context. It's really a big context construction machine. And also, it provides a way of executing actions. So part of the context is, here are the things I can do. And the LLM can say, please go execute this tool or this action. And the agent is responsible for actually taking that action and then reflecting it back. The machinery for constructing that context, all of that, I call policy. And so what goes into policy? It could be how you assemble the actual LLM call. Do you take the last 10 messages in your history? Or do you take the last 100? That's going to be more expensive, but provide more information. Or do you take the last 10 messages and then a summary of the previous 90? Which is how we think about compaction, et cetera, et cetera.

• 7:43Speaker 01

  These are all policy decisions that are static, that are defined for OpenClaw or for Py or for Claude Code, if you look at their source code. And so that is the kind of, that is the policy of what an agent is. The tools it can use, the skills it has, how it includes them in its context, how it constructs context. Anything about the actual agent's code, which is what EXO sets out to actually make fully recursively self-improving. It's not just certain points where you can insert additional skills. It has changed the very machinery of what skills are for your job.

• 8:12Speaker 00

  Yeah, and the policies that make it up. I was just wanted to, if, actually, we should have been screen sharing. We might, we might have used some charts. This might be appropriate time to pull up a little architecture diagram.

• 8:24Speaker 01

  Totally. Let me actually bring that up. It'll be easier to talk through. So just in here, we can see, and this is again from my lecture on Principles of Autonomous System Design, which was really a deep dive on OpenClaw, because it came out, you know, a couple of months, a month or so before I started working on EXO. But you can see in this architecture, the core layer of this,

• 8:48Speaker 01

  of what OpenClaw is, is this kind of gateway controller. There's a bottom layer that has the actual context assembly. And there's a top layer that has connectors, which is how you interact with it. And I've marked here in red the parts that are plugins. There are places that make this customizable. Let's say for your particular task, if you want to manage memory in a different way, let's say that you're working on something that is... You're doing some sort of development that's looking at a whole bunch of sets of different docs. You might want in your memory the docs for a bunch of different projects, but you probably, you might want to run rag over them to fetch the most relevant ones to include in the context. And so this memory plugin allows you to say, here's a different way of storing and indexing your memories. Great. A human comes along and sets that.

• 9:33Speaker 01

  Or there's tools and you can say, here's an additional tool I want to give to my, my open claw. Or skills and there's all of the like Claw Hub sites that list out a bunch of tools or skills that you can install. This is all still a human coming in and modifying. And you can come and say, please install this, this tool for me. But the shift that we're trying to make is all of the other things that are not red here, all of the connective arrows, all of the components. We believe all of that needs to be improvable by the agent, especially as the agents keep getting better. Because as they keep getting better, it's, it's this bitter lesson. You don't want to over specialize. Because you don't want the human kind of deciding all these architecture bits. As the model gets better, it knows how to architect the agent in a way that's most optimal for the given task.

• 10:14Speaker 01

  So that's kind of the shift. If I were to put Exo's architecture next to this, I'd say, I'd put red lines around all components here and say, they are all changeable by the agent itself.

• 10:24Speaker 00

  Yes, this, it's the most extreme version of what this does.

• 10:29Speaker 01

  What was the other question you wanted me to talk about?

• 10:30Speaker 00

  Do you want an explicit switch or an implicit switch is basically the question, right? Like implicit switch is the most like trusty AGI to figure everything out moment. And the explicit switch is for people who don't trust machines to figure things out.

• 10:45Speaker 01

  I will say, and then I'll go to discuss the other architecture, but I do want to touch on this now while it's still, still top of mind. I'll just point out, you are still trusting a machine when you have an outer separate agent modifying the inner agent. It's still not you making the changes, right? You're maybe helping direct it, but you still have to have the same trust in the machine that's making the changes. The question is, do you have an external system that, that inspects an internal system? Or do you let the running system itself inspect itself? And the cool thing that when I, when you merge the two layers together, the cool thing is that the same thing, the same system that is make, deciding to make changes is also deciding what to run and also deciding what to inspect.

• 11:28Speaker 01

  And so your system itself can try things and look at how it does and how its, its own internals perform and make changes to itself as it runs. So you could say, and I can give you a really good example. We've had Exo running, playing, playing Pokemon. And while it's running, the system itself decided to try inspecting the like RAM of the game. And then went and mapped the RAM to, and people have reversed, in the past, people have reversed engineered this manually. They figured out what components in the memory map to different things in the game. So there's like in the memory, there are certain places where you store the positions in the world. The Pokemon that's currently active, are you in a battle or not? Literally booleans in, in the code, in the memory. And the agent was able to modify, Exo was able to modify its own integration with the game

• 12:12Speaker 01

  and feed this into the system message to better inform its decision-making as it progresses. An outer loop would have to kind of like think about that and potentially try design, tell it, launch it, see how it does, reflect back. If the system itself is evolving, as it makes changes, it can inspect things and use that inspection, runtime inspection to inform its design process. So I think it's a more powerful way, a more fully expressive way of doing self, self-improvement than an outer system that's.

• 12:39Speaker 00

  Yeah, fair enough.

• 12:40Speaker 01

  Okay. Now maybe let me talk about, I'm happy to talk through the Exo harness, Exo architecture, if that's useful.

• 12:45Speaker 00

  Yeah, let's do it.

• 12:47Speaker 01

  Yeah.

• 12:47Speaker 00

  We love, we love a good architecture diagram on this pod. Usually I'm the person drawing it on Exo the draw. So this, you actually saved me a bunch of work here.

• 12:56Speaker 01

  By the way, so you know, for context, right? I don't think I mentioned this earlier. I'm a PhD at Berkeley, advised by Sylvia Ottesami. I work at Scott Shanker and Jan Stoica. And I'm coming strictly from systems. I started my PhD before ChatGPT really took off. And I was a core networking person. So I'm a, I've done my work kind of in core systems, designing wider network architectures for SDN controllers. Just how you decide what path your data takes through the internet. And then I do formal verification for networks. And I've kind of come from a lineage of really thinking about system architectures and trade-offs and designs. I'm not an ML person kind of coming down into agents. I'm a systems person coming up.

• 13:37Speaker 00

  Yeah. Well, I think the beauty about AI engineering is there's room for both systems people and model people. I would say Berkeley tends to be the systems over models or systems orchestrating models people, obviously. Because it's the school of, what's the, what's the term? Compound AI.

• 13:56Speaker 01

  Compound AI systems. Yeah. Yeah.

• 13:59Speaker 00

  So, so, so yes, I do, I do, I do see both sides. I do think that there is some tension that people don't address with regards to how large model researchers always say things like, oh, the next big model will wash things away. You know, we'll wash the harness away. And obviously over here, we're building harnesses. It both can be true.

• 14:21Speaker 01

  I agree with you. My bet is this though, that people keep trying to get models to do things that align with their goals. And alignment is an unsolved problem. We keep trying to like, like RHF, like try to align these models to do the right thing. In harness space, we actually have an opportunity to enforce certain properties by the architecture of the system that we design, which is totally different than trying to bet on the model, the LLM, the weights containing the rules that we want. Like for example, if you never want to delete your history, you have to enforce that in the architecture of your harness, rather than just asking in context, please LLM, don't ever do anything that'll delete my history. Because we keep seeing that there's ways to trick the model.

• 15:03Speaker 01

  So that's the place that I think architecture holds and really shines for a systems person. Okay. So let me talk through the Exo architecture a little bit. This project Exo is really, it's a self-improving agent, but that's enabled by this architecture for the harness that's opinionated and very carefully partitions agents. And so I just want to draw the parallel to how we think about agents today. If I come down here.

• 15:30Speaker 01

  When you think of Claude code, Claude code is both an agent, people colloquially think of it as an agent. It's also a harness and they're kind of shipped together. And you drop it into an environment where it works. And so, you know, a common workflow for me is I spin up a VM. I go in there, I, you know, start Claude, I do Claude login.

• 15:52Speaker 01

  And then I work on a project in there. I clone a repo. I have to log in with my GitHub credentials, by the way, so that I can go and push things for me. And then I'm working in this isolated space. I trust it relatively, and I do, you know, dangerously skip permissions. So that in this VM, and then by the way, I can accept here, oh, this is kind of risky because I've actually logged in. I have to have my, like, maybe I have some keys there. I have my, certainly my GitHub credentials there, but okay, fine. At least it's not going to destroy my computer because it's running in, in a VM somewhere. The architecture that we're proposing is one that decomposes the idea of an agent into kind of three distinct important layers. And I'm going to show them first more generally, and then I'll come back to the detailed design here. It decomposes an agent into an executor, an Exo harness and a sandbox.

• 16:37Speaker 01

  And these layers all have different properties. This is very important. So we think of the harness, the Exo harness down here as needing to keep all state, the minimal set of things that we want to have protected from the agent. It's stuff that the agent uses, but that we want to have protected. And the executor contains all of the policy. And we talked about policy earlier. Policy entails how you assemble your context, what are your prompts? How do you do compaction? What are your skills? What are your tools? Anything about how the actual agent is deciding what it's going to do. Right? So in this way, we have a really nice split. The executor is fully stateless. So it's a fully stateless process.

• 17:19Speaker 01

  And the Exo harness contains the layer that has the conversation history, any secrets that might be needed, such as API keys, artifacts or snapshots of an environment. And finally, we have a sandbox layer, which is the actual environment where things are happening, where things are taking place. This is not supernatural to think about because today Claude code runs in the same environment as the code itself that it's edited. You drop it in and Claude code is running as a process on your machine, editing other files on your machine. Or you drop Claude code into a VM where it runs in a VM and is editing files on that VM. We split that out where the actual actions, like you want to go, the agent wants to go run a bash

• 18:00Speaker 01

  a command of some sort, gets executed in a sandbox, which is distinct from the actual policy process that can be running anywhere else. But what this gives you, this nice split is it gives you an isolated execution environment down here. It gives you protected state. And then it has a very explicit stateless layer that's safe for self-evolution. So the executor can propose changes to itself in a way that you will not lose any history. You won't leak secrets because they're not exposed to the LM itself. And our Exo harness provides a mechanism for snapshots. And what this is really nice for is you can snapshot the sandbox environment and the agent, the, the policy itself can choose at runtime as it's running to try to make some changes and roll itself back.

• 18:45Speaker 01

  So this is the fundamental architecture behind, behind Exo. And I want to point out what these layers give us. So.

• 18:55Speaker 01

  An agent now, and this is the hardest piece, I think, in understanding EXO and the EXO Harness architecture, is decomposed, it's split across these three layers. It is the conversation history that's stored in the EXO Harness, the state, plus the policy that's running, which is an executor, plus a sandbox that it's running on. And those together define an agent as we think about them today. Hopefully that makes sense.

• 19:21Speaker 00

  I like this breakdown is very clear. I have questions about some of the bullet points here, but I want to get the full top level first before we go into details.

• 19:29Speaker 01

  Yeah, so I'll go one more slide to kind of just make this fully concrete and then we'll go into all the details. So again, this is my view of the architecture that enables EXO. But in this architecture, again, to make this really concrete, you have sandboxes, you have a harness that holds on to your state, that's fully stateful, and you have the executor up here that runs. And here you can see policies, all the compaction tools, skills, LLM call, et cetera. So the step that EXO takes, what really makes EXO be a self-improving agent, is it goes and it will mount in its sandbox its own code for the executor itself.

• 20:11Speaker 01

  And now as a result, the part of the decision-making in that the LLM can make is it can say, hey, go edit some aspect of its own harness at runtime. And we have in the EXO Harness, a special guardian kind of process that will allow the executor to be rebuilt at runtime mid-step and also provide some sort of kind of soaking process where after being rebuilt, we try to bring up the executor, let it proceed one step, and if it breaks itself accidentally, it'll get rolled back to the previous state automatically. And that's the minimal set of components that are needed because now you have an executor that can see its own code, it can edit its own code, it can ask to rebuild its own code

• 20:54Speaker 01

  and swap mid-run, and as a result, and finally is protected by an EXO Harness that will roll it back. And also this mechanism can build new tools, write new skills, change anything about how the context is assembled, adjust adapters, et cetera, et cetera. So that is the final step that allows EXO to be kind of fully recursively self-improving.

• 21:13Speaker 00

  It also means that changes can be parallelizable because it's sort of a, there's atomicity in the commit of the changes in the executor, the harness. Overall, a good separation of concerns. If you want to go back, yeah, the first thing I land on is this last point, transferable for teleportation. How important is that? You know, teleportation, classically, I think, people want to run things locally and then they're like, I want to close my laptop, I want to move it to the cloud. That's kind of the only reason that people do teleportation of agent state.

• 21:56Speaker 00

  Is there something else that this refers to?

• 21:59Speaker 01

  Yeah, this is a great point. So in a world where you're running a single agent, working on a single task, there is like very little need for teleporting your stuff away. Just you either run it locally while you're working, or by the way, if you want it to just be always on, you have to run it remote to begin with. Like it has to be on a server somewhere so that when you shut your laptop, it's still going. So I get your point. The benefit here is, what if you want to scale up to working on a bunch of different tasks in parallel? You have a bunch of different conversations. This is a very real need. It's not a need for you and I managing our email, but it could be a need for a company. Let's say that a company is wanting to spin up a conversation in an agent or a dedicated agent to each user's usage logs.

• 22:43Speaker 01

  The user comes in, uses your app, you have some library that goes and logs to a database, there's a stream of events coming in, and there's some kind of reasoning you want an agent to do over that stream as it happens. Well, you might want to wake up a dedicated kind of sandbox environment for each of those conversations, which by the way is fully doable in the EXO Harness architecture. If you're trying to do this for 100 users, great, it's going to fit on your one machine up to 100 containers running at once. If you want to do this for 50,000 users, you're going to start running out of space on your machine. So you might have enough policy processes because you only need a couple to be awake at a time, but you're going to have a lot of different customers who are being woken up at different times and different dedicated sandboxes coming up. So a benefit of this teleportation is, once you start running out of space for running

• 23:26Speaker 01

  kind of sandbox containers on your machine, you can start moving some of them off to the cloud, either starting new ones up in Daytona or moving existing ones up to Daytona or some other provider. You might want to give access to some sort of resources that aren't available locally. So that's the benefit I see of teleportation.

• 23:41Speaker 00

  Why Daytona? You just know them?

• 23:45Speaker 01

  For me, it's actually, I'm coming from, some of my previous evals were done on Harbor, the makers of Terminal Bench, and they had Daytona just integrated. We actually have integrations for a number of other providers, E2B. I use actually EXC dev for some of my stuff where I move it off, so I only give it as an example.

• 24:01Speaker 00

  Yeah, well, no, we've had both Daytona need to be on the podcast, but I just think this like single recommendation by the Harbor guys is driving most of Daytona's growth right now, which is very funny. Obviously Daytona has good sales and I should be clear that Daytona has done a lot of other GTM work outside of just Harbor, but like, yes, just on the pod itself, like the number of people that are very influenced by that preference is nice. Nice to see that you can actually reward good experiences there. Okay, so I want to keep going on other parts. Can we go back to the architecture diagram?

• 24:41Speaker 00

  I think there are some things here that can be maybe like dived into. Things I've wondered, for example, are where do subagents live, right? The things I've wondered are, do you need a router to do the DSP type of recursive optimization, you know, prompt and tool call and LLM optimization, which does help. And then, yes, actually, I have often thought about secret store, which most agent setups do not have, and you really do need a secret store. So I'm just calling out things that stand out to me here. We tackle whichever gets you going.

• 25:26Speaker 01

  And I want to remind you here that we're kind of, there's two things we're talking about. There is EXO, the agent built over top of this, and that's done by kind of mounting the executor code in a sandbox. And there's the EXO Harness here as I'm describing it, this architecture. And some of the questions you're asking about how we decide where to put components of the EXO Harness, which I will talk through now, but EXO is a thing built over top of this that's fully recursively self-improving, whereas this is an architecture to enable that.

• 25:51Speaker 00

  Yeah.

• 25:52Speaker 01

  So looking here, the decisions on like, how do I want to spawn out subagents? It's kind of a policy decision in the executor. So you have code written that can go and spawn subagents. That is a kind of a decision that happens, when do you spawn them? When they run, what tools do they have? What access do they have? All of that to me is up in the executor and is used at runtime. Like the simple EXO as it's built today doesn't natively come with subagents, but absolutely can be implemented in the same pattern, just in code. Like really, the way to think about this executor is, it's a block of code and these modules here are really me laying out conceptually what components go in that block of code,

• 26:37Speaker 01

  but it's up to you how you write that code. But state that you have, for example, like memory, you might see memory here, the way you choose to record or inject memory lives in the executor. But the actual memories themselves go down in the EXO Harness as artifacts for that conversation or for that agent. And so it's kind of like the how you do things is defined in the executor, the actual state at runtime lives in the EXO Harness.

• 27:05Speaker 00

  Yeah, you have to separate compute and storage, basically, in order to make it teleportable to resumable everything, right? Like people sloppily can mingle these things a lot.

• 27:18Speaker 01

  Then we can mention the secret store. The secret store is really great. We want it to live in the EXO Harness so that it's not exposed directly to the LLM. This is, again, if you think about dropping an LLM, let's say you're working on a project, building a harness even, well, for that harness to be able to run in your environment, you probably need an API key. And if your agent is running in the same environment as your API key, that is now fully kind of exfiltratable, like fully readable. And so it's very helpful and very handy and actually quite important to separate out a secret store that stays in the EXO Harness on the host process from the sandbox in which operations are taking place. And so that secret is kind of injected in the executor's

• 28:01Speaker 01

  LLM call to provide the secret without actually exposing it in the space where the tools can see what is being used, which is in the container.

• 28:11Speaker 00

  Yeah. And also like an access log in case you need to sort of do some history of debugging after something goes wrong.

• 28:20Speaker 01

  Yeah, yeah, exactly.

• 28:22Speaker 00

  Also, I guess like even the very fact of secrets being accessed, if there's an unusual pattern of access, that should be monitored as well. If my very routine task is somehow requesting my AWS keys, like something's wrong, even if I have it there, you know, and I often wish that there was more work on like monitoring of that kind of stuff, where typically we just have like it pipes out to like a Slack channel and people just keep an eye on it. But that sounds terrible.

• 28:53Speaker 01

  Yeah, yeah, yeah, yeah. I think there's a lot of things happening right now that are just, the space is so new and these things are so powerful that we just are going to do this, whatever we can just to start extracting value from these systems, we're just going to do whatever is easiest and works right now. But it is not necessarily the place we're going to settle, I think.

• 29:12Speaker 00

  Yeah. Well, I mean, you have the, I guess, the leeway because you're designing Exo to, I guess, you know, put the recommended best practices in there from day one and then, you know, everyone who gets, your harness gets the benefit.

• 29:26Speaker 01

  Yes, yeah.

• 29:27Speaker 00

  I have further variants of this if we want to dive in there. A very quick one, which I'm not expecting a ton of responses for. Any thoughts on real time agents? Does that change anything at all? Just like voice agents or like things that have to respond in like relatively real time?

• 29:46Speaker 01

  If I can briefly just share, if people want to go try this, I want to point out where they can go. We have our GitHub here that is at github.com/exoharness/exo. And there is a bunch of docs here linked at the, at the top. You can kind of learn about the architecture of Exo and how it works and some tutorials. But coming back over to the GitHub, there's a quick start of just a one line install script and that'll get you going and get you running. And I can show what that looks like soon. But I'll, but I'll point out, we also, Exo comes with some prebuilt adapters. So the same way that I showed you, you know, people familiar with OpenClaw know that it has adapters that are really the way it interacts with and can receive messages from the outside world. We ship Exo with

• 30:29Speaker 01

  an adapter for Discord, an adapter for IRC and for WhatsApp. You can very easily add your own. And this all leads into the answer to your question. We actually went and built voice mode into Exo to the, to the Discord adapters. You can have, you can have Exo kind of join and chat with you in Discord in a voice chat, but it's still in a, it's not an interactive model, the way that you're talking about. Yeah, where it's kind of.

• 30:57Speaker 00

  Yeah, it's a pipeline cascade thing.

• 31:00Speaker 01

  Yeah, it's a pipeline thing. So as I think about how this needs to change for, I think there might need to be some better notion of like interruptible work for agents on their side. This is another thing that kind of really I noticed has bothered me with the OpenClaw architecture, as wonderful as it is. And once an agent kind of goes and starts working on a thing in a thread, that thread is not interruptible. As the thing is off working, if you try to ping it, it just won't respond. You don't even know what it's doing, which is really frustrating. So the way you have to get around this is you go and you start a different conversation. You say, hey, do you know what's going on over in that other thread? Like, why is it not answering? Which is like, not entirely correct. So the way that we're going to need to reinvent what that kind of interactive

• 31:43Speaker 01

  interruptible work looks like in the agent layer, which is separate from the work going on, I think, in the, like, in the model layer and in this like interactive model space. But I think we'll look much more like a systems OS thing where the same way that when you're working in your terminal, you want to start, start something, you maybe put it in a background or you open T-Max and you put it in a separate, in a pane on the side. I expect this will be an architecture decision of how you put tasks in the background and expose them to the agent as they're running. But that's the extent of my thinking.

• 32:13Speaker 00

  I thought, I thought you were going to say, you know, you send signals, right? Sigint or Sig.

• 32:18Speaker 01

  Yes, yeah, totally. No, no, exactly. So same way that you can background a process and when it's done, it'll send some signal that you can be woken up. Yeah, there'll be some sort of signal passing or some sort of pub sub bus where you start a process as a pub sub, you write to the pub sub. I think that's the architectural systems C thinking for me on this.

• 32:36Speaker 00

  Yep. Okay. So I think that that all makes sense. And then another sort of kind of housekeeping question, I guess. Did you implement ACP, the protocol from Zed that normalizes over a lot of coding agents? Do you know about it? Do you have any opinions? Differences of opinion?

• 32:56Speaker 01

  That's a great question. No, actually, we haven't gotten there yet. I remember seeing it in the OpenClaw architecture as a, as a way of allowing spawning other coding agents within, within OpenClaw. That's actually a great suggestion for something to do next week.

• 33:08Speaker 00

  Yeah, throw your clunker at it. Throw Exo at it. Yeah, I mean, you know, I think that everyone's trying to normalize. I think this is a classic systems design thing. You know, you have like 10 coding agents. Well, let's, let's make the one API to rule them all. And so ACP is the current one. You have a different one. Databricks has like a slightly different one too. And like, well, let's just figure out what it is. But then also there's the, just the general discomfort of like, the, any common protocol is always going to be lowest common denominator. So and then what, right? Like, does it actually provide the value versus just having like a pie, right? Like, that's why OpenClaw adopting

• 33:51Speaker 00

  Pi instead of saying like, we will, you know, interrupt with like 10 different agents. It makes, makes it simpler, to be, to be super honest. Like, you don't have to have modules for everything.

• 34:02Speaker 01

  No, that makes sense. I, I think it's something we'll look into. We've been really focused on first, what does the architecture need to look like to enable self improvement? And then second, building out that kind of self improving agent piece. And I think now that we have people starting to want to use Exo for different things, you know, this is running in production, the Exo harness and agents built over top of it is running in production at Brain Trust. You know, so these pieces are hardening. I think it starts to think, it is time to think about how to make this as easy for others to integrate with as possible. So that's a great call out.

• 34:31Speaker 00

  Let's bring that in. So again, one of my favorite podcasts of last year, I think, was of Ankur, very great founder and systems thinker and all those things.

• 34:40Speaker 01

  Incredible thinker.

• 34:42Speaker 00

  What's he done? Basically, like, can you attribute credit to like, what did Martin do? What did, what did Ankur do? And then also, let's talk a bit about like what has been seen in production, like whatever stories you have.

• 34:53Speaker 01

  Totally. Yeah. This project, I think, is pretty unique because it has these different, very different people coming in. Ankur is an incredible systems thinker, sees a lot of how people are using agents out in, in his role at Brain Trust. And is just also, yeah, he's excellent to work with. Martin, obviously fantastic VC, also an incredible systems thinker, but coming from a different perspective as a VC, sitting and looking at these different pitches that are happening and different products that are out there. And obviously also deeply very technical. And you have me as a, as a, as a researcher at Berkeley, I'm in the milieu of the things that are not directly on the production path, but are on the kind of, where is the research bleeding, cutting edge? And especially I've

• 35:35Speaker 01

  been focused on evolutionary systems and AI driven discovery and loops on how you improve things. You know, loops really came into the discourse some, a couple of months ago with some big tweets. In the research space, we've been talking about these loops, I think, since last summer and really deeply. But, you know, they weren't trending on Twitter.

• 35:51Speaker 00

  That's how these things go, right? But also, I don't know if you got the memo, but loops are dead. Graphs, graphs is all we talk about now.

• 35:57Speaker 01

  Graphs are back. Okay, yeah.

• 35:59Speaker 00

  No, no, no. This is a shitpost. This is, to be clear, this is a shitpost. This is just influencers making fun of themselves for like, well, every few months you got a cycle. It's like, so you have something you need to talk about.

• 36:09Speaker 01

  Do you know what's coming after graphs? Or I'd love, I'd love a tip off.

• 36:12Speaker 00

  I don't know. Markdown is all you need again. I don't know.

• 36:15Speaker 01

  Yeah, I look forward to that. But to go back to kind of, there are these three players. And so this started from, I gave my kind of lecture on principles of autonomous systems back some months back and it got a lot of engagement from the community. I love to see people's responses. Martin came and gave a talk also on, at Berkeley on the future of where harnesses are going. And we kind of linked up there and met up to talk. And at the same time, he said, hey, we, you know, Ankur was thinking about this at Brain Trust, we should get together and talk. So we got together in a meeting room and just started talking about, you know, what does this architecture need to look like? What are the properties that you need? And really, this started with a bigger focus on the Exo harness. How should you architect these agents to, to provide scalability and

• 36:58Speaker 01

  safety? And Ankur took a first stab at the layered architecture. And again, brilliant systems thinker. And as we started building that out, the first three, four weeks, I got very interested in what this layered architecture will enable us to do with self improvement. And coming from the space of AI driven discovery, I was really wondering, what if you collapse the AI driven discovery loop into the executor itself, provide, and which is enabled by the fact that you're kind of have this protected layer of the state in the middle and a separate protected layer of the sandbox. And so after spending three, four weeks on really the three of us building out the, the Exo harness or hardening

• 37:41Speaker 01

  it, originally kind of driven by Ankur more, we shifted to focus on this self improvement. That a lot of my research has been in that space. And so I think my imprints are really there. And Martin, you know, you said earlier, hey, oh, maybe this is just a VC just talking about, oh, yeah, yeah, right. You code. Martin really codes. Martin's really in this coding day to day. So it's been super fun, the, the, the three of us working together. If you look at the commits, we're all there. So Martin is not just posing, as I'm sure you know, but yeah, this is, yeah.

• 38:12Speaker 00

  Well, you know, you gotta see, you gotta see the, the proof in the pudding. I guess the last question, yes, RSI is like a very trending big topic here. Have you tried just telling Exo to improve itself with no goal? Or do you give it a goal? Or what do you do?

• 38:30Speaker 01

  This is such an excellent question. So let me, let me say a few words about this. And this is also coming out of some of my research that I'm doing at Berkeley with Yon. We're about to put out a paper on exactly this, which is, in all these optimization problems, the final difficulty is.

• 38:44Speaker 01

  You always have to provide some evaluator and that evaluator has to kind of reflect your goals because otherwise there's no signal for the thing to hill climb or to optimize. Or that signal, it might find a signal for itself, but it might not align with what you actually want. And that's also a dangerous, a pernicious failure mode. So there's a couple of cool things that we do for this. For one, one very standard thing that you might want your agent to do is you might want your agent to run more cheaply. Costs for improvements are really high and one of the big issues is like even just how do you assemble your context? How much of the history do you include? I can tell you with OpenClaw, my bills for running OpenClaw ran way up because of the way it assembles its context. It puts so much stuff in there. One of the things we did in EXO, which is really cool, the EXO harness, the conversation

• 39:25Speaker 01

  log stores not just what you talked about, but it also is annotated with costs for each of the messages. And so because of that, then when the executor has access to constructing context and also reasoning over the past conversations and the costs associated with different parts of those conversations. So very early on, one of the first things that was most exciting to me was after we built self-improving kind of EXO, we asked it, hey, I noticed, I asked it, hey, but how much did the last message cost in the Discord adapter? And it was like, it was 16 cents. It's like, are you serious? 16 cents? That's actually crazy. Like, go work on driving that down. And so it went and re-architected its own Discord adapter, got runtime, made changes, observed them, tested them, to really scope down the context that was included in each

• 40:09Speaker 01

  of the LLM calls as they were built by scoping it to certain conversations and certain threads only, rather than pulling messages from across different threads in Discord, in a way that drove down the cost to, I think, like, it was like a 96 decrease, a 96% decrease. And by the way, we committed this back afterwards. So the changes it made improved itself, decreased its costs, and then we ended up committing that to the actual code that's there now.

• 40:31Speaker 00

  Are you doing this subject to no regressions and evals? You know, there's no box that says evals in there, but like, should that EXO harness ship its own evals?

• 40:41Speaker 01

  Yeah. With the Discord case, it's a little easier because it can go and then test and try reading messages from different places. As I'm using it, I can say, hey, something's wrong here. It's a slightly simpler case. If you're going off and having it do some other task that it wants to improve its costs on, a very funny failure mode is it could totally be like, okay, I'm just not going to do it because that's the cheapest way for me to save money, right? And we see this in AI-driven discovery.

• 41:04Speaker 00

  And it's a reward hack.

• 41:05Speaker 01

  Reward hack, exactly. Preventing reward hacking. And so you definitely want some sort of eval-ish thing that it can go and check that the performance is still at the place that you would like. So in Discord, performance is very easy. Are you responding to my messages? Are you including the right context? Context that makes a reasonable response possible. It's kind of more of a binary. It's easier to check. If you have an insurance agent that's trying to make the right decisions, you might want some sort of holdout eval set. And you can either provide that to your agent or you can work with the agent collaboratively to construct internal tools for itself to check that at runtime as it's evolving itself. So I agree with you. The problem of specifying what you want to an agent is still an open

• 41:47Speaker 01

  one. So I expect us to build out a bit more tooling in the process of, in the context, providing it that as it improves itself, it should also track performance and define some way of tracking that.

• 41:59Speaker 00

  Well, you know, if you ever need an evals guy, I've heard Brain Trust is pretty good. I don't know, might be biased here.

• 42:04Speaker 01

  That's exactly right. I think we have the, some of the leading people here in the room for EXO thinking through that problem.

• 42:12Speaker 00

  Excellent. Okay. Well, thank you for, you're a great speaker. Clearly you do this a lot. You're about to go teach in Ethiopia for, for God knows why. But like, thank you for sending some time with us, especially on your time off. So this is excellent work and I'm really inspired. I hope more people study this and also adapt the ideas. You don't even have to use the architecture. As long as you get the idea right, I think that it will make for much more generally useful agents, which is something I want.

• 42:40Speaker 01

  Yeah, thanks for having me. I wanted to ask one other thing. If we have a minute, there's one other case I want to make that I think is of interest to this audience.

• 42:46Speaker 00

  Yeah.

• 42:47Speaker 01

  I think I want to answer a question that you didn't ask me, but you could have, which is like, why am I claiming that RSI is possible now with this architecture in a way that it wasn't before? What's the difference? And I want to point something out that's happened the last six months, which is we've moved from iterating on model weights, training model weights, to iterating on this harness and this agent layer. And the big difference here is that the medium is now, the medium for these agents, for this harness layer, is the same as the actual like building material. And what I mean by that is the agent harness is a couple thousand lines of code and our LLMs are producing output tokens in that same space. They're writing code. They're

• 43:31Speaker 01

  getting good at writing code. And so this is the crucial difference. You had LLMs before, but the process of improving the actual LLM was changing weights. It was deltas, you do backpropagation, gradient descent, changing weights, modifying weights. But you have a trillion parameter model. You can't feed the weights of that model back into itself and ask it, how do you adjust yourself? It just doesn't scale. It's not in the context. You could ask an LLM, hey, give me some ideas for how to train and then go try to apply those ideas and run them. But it was not in the same medium. Whereas now, the harness as it runs, the agent is producing and writing code and can change its own code as it runs, which is why I believe we're entering a stage where this is fully self-mercursive. It's not just autocatalytic, which is where you use a computer to help design the next

• 44:13Speaker 01

  computer. But the computer itself is made of physical chips that are laid out, right? So there's layers in between as you loop back around.

• 44:19Speaker 00

  Yeah, that's fixed.

• 44:20Speaker 01

  This is in the same exact, the code is the thing being produced and is also the thing running at this layer, which is why I think it's the right layer to think about RSI.

• 44:28Speaker 00

  Well, I mean, you know, you want to be fully, fully self-recursing, you got to train your own models, right? Like, you got to like hook up some GPUs and like, wow, like, you know, the model's not good here and that's fine too there.

• 44:37Speaker 01

  Agreed. But I'll just point out that there you get autocatalytic improvement. You are using the system to help improve yourself, but it is not in the same medium. So that's the thing I want to call out. And this layer-

• 44:49Speaker 00

  You're very purist about this.

• 44:50Speaker 01

  I'm very purist about this. Maybe coming from academia, this is my fault. Yeah.

• 44:57Speaker 00

  Does this remind you of other systems? What I'm thinking about is like, you know, people often bring up like small talk and like stuff, conversations like this where, you know, it is on the order of a programming language type of abstraction, if you really think about it. Like, that is a system and programming language design and PLT, programming language theory, does translate. I feel that a little bit.

• 45:21Speaker 01

  Yeah. Yeah. That's a great comparison. I hadn't thought about that. Yeah, there's probably some comparison to draw here to some sort of programming language that it contains its own construct, constructs within itself.

• 45:32Speaker 00

  Yeah, Lisp.

• 45:33Speaker 01

  Yeah. Yeah, Lisp definitely comes to mind. Yes. Yeah. Yeah. There's a moment like that happening now and this is the moment that's going to be a flywheel, I feel like, because this takeoff moment will come from being iterating in the same layer that you are producing, I think. So that's why I'm so excited to be in this space right now. I think we're all super lucky to be like, just in this moment in time.

• 45:52Speaker 00

  Yeah. Excellent. Well, I am very glad to at least make this initial contact. I'm sure this is not the last time you'll be on the show, but it's good to at least get an introduction to your work. I'm sure there's more that we'll see from you, but thanks for the overview.

• 46:08Speaker 01

  Thanks so much for having me on. A really fun conversation. I look forward to talking again.

• 46:13Speaker 00

  We'll put your contact details below. If people want to contribute in any meaningful way, what is the best place to get started?

• 46:19Speaker 01

  Yes. We so welcome contributors. You know, Marty and Anker and I are all building together with a handful of other people. Please come to check out our GitHub, github.com/exoharness/exo. And on there, there's a link to our Discord. Just come hop in, come hang out. If you're just interested in these topics, come join and discuss with us because it's a very formative time. This is still very early. We're always looking for contributors and more discussion partners. So yeah, just reach out there, follow me on Twitter. It'll be linked below.

• 46:46Speaker 00

  Yeah. Pro tip, when you join these kinds of early communities, it's actually not just about the project. It's also about people and what you end up doing with them in future years. So whenever I've seen these kinds of early communities, it's actually a really good time to join these things. So awesome. All right. Well, I'll cut it there. Thank you so much.

• 47:04Speaker 01

  Thank you.