Transcript
Intro and background on the team
0:03 · Okay, we're here in the remote studio with Alex Cransel, I guess, of EXO, but also UC Berkeley. Welcome.
0:08 · Thank you so much. Happy to be here.
0:10 · The reason we're recording is because I had to when you showed up on on my timeline. I I didn't know that you had already showed up before. This is this goes to show you how much uh persistence there is on YouTube. But like I actually had watched your lecture and then didn't register your name on OpenClaw.
0:25 · 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:32 · Yeah.
0:32 · But also like maybe like your face on there, but also you know just like other other work. But uh you know that's all that's all of a of a piece. Um most recently you you showed up uh working with two of our former guests on Leon Space uh Martin Casado and Anker Goya.
0:50 · When I actually talked with Martin on the podcast, he actually said that he was hacking away with you and he didn't like because I he was like, I want coding so much and I was trying to call out like you know this 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:17 · Yeah, for sure. Thank you. I mean, I'll start by saying, yeah, I I've been building this with with Martine and Encore. They're both really excellent systems thinkers. As you might know, Martine's background is in a PhD in computer science. Actually, advised by my adviser, my PhD adviser, Scott Anker, at Berkeley. So, that's kind of our shared lineage.
1:35 · Shared shared lineage. Yeah. He was my board member when I was working at Nellifi and I was working I was learning about uh you know, virtualized networks and all those things.
1:45 · Yeah.
1:45 · 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.
Defining the Exo agent thesis
2:04 · 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. We 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:26 · Um, and I think it's really enabled today by the fact that we're we're entering a new layer in the like 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. You 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.
The shift in the ML stack: from model weights to agent harnesses
2:53 · I 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, they're get really good at particular tasks, either better at doing them or more efficient.
3:17 · So doing them with less token calls, less usage, driving cost 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, etc., etc. And so the project came from I've spent the last year or so of my research at Berkeley on discovery systems. So AIdriven discovery, right?
Origins of the project: Sky Discover and AI-driven discovery
3:37 · This project come out of the sky lab at Berkeley called Sky Discover. 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 the way you're doing your optimizing then you need some outer outer loop and it's this infinite recursion out 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.
4:07 · 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 the kind of thesis for Exo.
4:20 · Yeah.
4:20 · And I'll maybe add a couple pieces of commentary here. Uh the first people to realize this was probably the PI openclaw people, right? Uh where they were like, well, the the harness should modify itself to to add whatever capability you need, but it is not fully self-reursive in the way that you envision it. Second of all, so so we can go into that and you've already done an open call lecture which which I'm going to link to in in description that people should see and we can cover a bit of that if if it's relevant to this conversation. Uh the second of all is I haven't followed this at all my for my stuff.
4:51 · So so uh for for my two companies I have an internal bot that does work and I have an external bot Devon that modifies the internal bot. It doesn't the internal bot has no ability to modify itself. 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 um the the difference obviously is it is not magical. It it is like uh you you drive the car then you open the hood to to to modify the car if you need but most of most of the time the the hood is closed.
5:24 · Uh and so then the question the push back 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:33 · Wherever you want, 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.
Comparison to OpenClaw and agentic adaptability
5:50 · But I want to point something out. It's adaptable in a very particular narrow way. So if if we were to go and look at the architecture, there are particular places where the open cloud 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.
6:10 · Literally it is a memory MD file somewhere. There is a markdown file that things get written to. It gets injected in context every time the LM you know is constructs like we construct a call to the LM 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 a human. A human will come in and say, hey, I want a skill for this. Let me go install this skill.
6:40 · And then ask OpenCloud to do this. And so it's it's absolutely selfimp 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.
What is an agent? Policy, context, and action
6:55 · Everyone has I'm sure your audience knows very well about agents, but having a shared definition is important. I think about an agent as an LM 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 LM can say please go execute this 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.
7:26 · 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.
7:36 · Or do you take the last 10 messages and then a summary of the previous 90 which is how we think about compaction etc etc. These are all policy decisions that are static that are defined for openclaw or for pi or for cloud 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.
8:06 · 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:12 · Yeah.
8:12 · And the policies that make it up.
8:14 · Uh I I was just wanted to if if actually we should have been screen sharing we might we might have used uh some charts that this might be appropriate time to pull up the a little architecture diagram.
8:24 · Totally. Let me actually bring that up.
8:26 · It'll be easier to talk through. So just in in here we can see and this is again from the my lecture on principles of autonomous system design which was really a deep tie on openclaw because deep dive on openclaw because it came out uh you know a couple months a month or so before I started working on exo but you can see in this architecture the core layer of this of what open is is this kind of gateway controller uh 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.
Architectural overview of Exo
8:56 · 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.
9:24 · And so this memory plugin allows you to say here's a different way of storing and indexing your memories.
9:31 · Great. A human comes along and sets that. 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 uh like clawhub uh 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.
9:48 · But the shift that we're trying to make is all of the other things that are not read 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.
10:04 · 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. 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:24 · Yes, this that's the most extreme version of what this does. What was the other question you wanted me to talk about? 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 search is for people who don't trust machines to to figure things out.
Implicit vs. explicit system modification
10:45 · 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.
11:05 · 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. And so your system itself can try things and look at how it does and how it's in in its own internals perform and make changes to itself as it runs.
11:37 · So you could say and I can give you a really good example.
Real-world example: Exo playing Pokémon
11:40 · We've had Exo running playing playing Pokémon 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 and people have reverse in the past people have reverse engineered this manually. They figured out what components in the memory map do 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 Pokémon that's currently active, are you in a battle or not? Literally booleans in in the code in the memory.
12:06 · And the agent was able to modify Exo was able to modify its own integration with the game and feed this into the system message to better inform its decision-m as it progresses. An outer loop would have to kind of like think about that and potentially try a 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.
12:32 · 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 Yeah, fair enough.
12:40 · Okay, now maybe let me talk about I I'm happy to talk through the exo harness exo architecture if that's useful.
12:45 · Yeah, let's do it.
12:47 · Yeah, I we love we love a good architecture diagram in on this pod. Usually I'm the person drawing it on a scarlet draw. So this you actually saved me a bunch of uh work here by the way. So you know for context right I don't think I mentioned this earlier. I I'm a PhD at Berkeley advised by Sylvia Nasami. I work with Scott Shanker and Yan Stoka and I'm coming strictly from systems. I started my PhD before chat JPT really took off and I was a core networking person.
Krentsel's research lineage and systems thinking
13:13 · So I'm a I have done my work kind of in core systems designing wider network architectures for SDN controllers um 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:37 · Yeah.
13:37 · 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 uh what's the what's the term compound um AI compound AI systems yeah uh yeah so so so yes I I I do I do I do see both
14:03 · sides I do think that uh 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, will wash the harness away. And obviously over here we're building harnesses. Both can be true.
14:21 · 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.
14:48 · 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. 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.
15:10 · 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, uh, when you think of cloud code, cloud code is both an agent. People colloquially think of it as an agent.
15:35 · 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 um, I spin up a VM, I go in there, I, you know, start cla 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 it can go and push things for me and then I'm working in this isolated space. I trust it relatively and then I do you know dangerously skip permissions so that in this VM and and by the way I can accept here.
16:07 · Uh 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 exohornness, and a sandbox. And these layers all have different properties.
Decomposing the agent: Executor, Exo Harness, and Sandbox
16:38 · 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 executive 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?
17:12 · So in this way we have a really nice split. The executive is fully stateless.
17:17 · So it's a fully stateless process and the XRS 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, cloud code runs in the same environment as the code itself that it's editing. You drop it in and cloud code is running as a process on your machine, editing other files on your machine.
17:47 · Or you drop cloud 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 a bash 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.
18:19 · So the executive 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.
18:29 · And our ex 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. Um so this is the fundamental architecture behind behind Exo. And I want to point out what these layers give us.
18:51 · So an agent now and this is the the hardest piece I think in understanding exo and the exoh harness architecture is decomposed. It's split across these three layers. It is the conversation history that's stored in the exohness the state plus the policy that's running which is an executive 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:21 · 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:30 · Yeah.
19:30 · 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 executive up here that runs and here you can see policies all the compaction tools skills LM call etc.
19:55 · 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 executive itself.
Achieving full recursive self-improvement
20:11 · And now as a result the part of the decision- making in that the LM 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 a special guard guardian kind of process that will allow
20:27 · the executive to be rebuilt at runtime midstep and also provides some sort of uh kind of soaking process where after being rebuilt we try to bring up the executive let it proceed one step and if it breaks itself off accidentally, it'll get rolled back to the previous state automatically. And those are that's the minimal set of components that are needed because now you have an exeutor that can see its own code. It can edit its own code.
20:52 · It can ask to rebuild its own code and swap midrun and as a result and finally it's 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, etc., etc. So that is the final step that allows EXO to be kind of fully recursively self.
21:14 · It also means that propo changes can be parallelizable because they it it's sort of a there's atomicity in the commit of this the changes in the in the execular the harness overall a good separation of concerns. If you want to go back Yeah.
21:35 · the the first thing I land on is is the this last point transferable for teleportation. How important is that?
21:41 · 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 code of agent state. Is there something else that this refers to?
Transferable agents and teleportation
22:00 · 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.
22:16 · 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. The user comes in, uses your app, you have some library that goes and logs to a database.
22:46 · 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 exhessar 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.
23:12 · 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 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 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:42 · Why Day Daytona? I you you just know them. For me, it's actually I'm coming from some of my previous eval on on Harbor, the 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.dev for some of my stuff where I move it off, so I only give it as an example.
24:02 · Yeah.
24:02 · Uh well, no, you know, we've had both uh Daytona and E2B on the podcast. Uh but I just think this this this like single recommendation by the Harbor Guys is driving most of Daytona's growth right now, which is very funny.
24:14 · Obviously, Daytona has good sales and I 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 by that preference is is nice nice to nice to see that you you can actually reward good experiences there. Okay, so I want to keep going on other parts. Uh can we go back to the architecture diagram?
24:38 · I think there are some things here that can be maybe like dived into things I've wondered for example are uh where do sub agents live right the things I've wondered are do you need a router to to do the DSPI type of recursive optimization uh you know prompt and tool call and LM optimization um which which does help.
Addressing sub-agents and secret management
25:09 · Uh, and then yes, actually I I have often thought about secret store, which most agent setups do not have, and you really do need this secret store. So, I I'm just calling out things that stand out to me here. We tackle whichever gets your gets you going. And I want to remind you here that we're kind of there's two things we're talking about. There's EXO, the agent built over top of this, and that's done by kind of mounting the executive code in a sandbox. And there's the exo harness here as I'm describing it, this architecture.
25:37 · Um, and some of the questions you're asking me about are how we decided where to put components of the exo harness, which I 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:52 · Yeah.
25:52 · So looking here, the decisions on like how do I want to spawn out sub agents, it's kind of a policy decision in the executive. So you have code written that can go and spawn sub aents that that that is a kind of a decision that happens. Yeah. When do you spawn them?
26:10 · When they run, what tools do they have?
26:11 · What access do they have? All of that to me is up in the executive and is used at runtime.
26:18 · None like the simple exo as it's built today doesn't natively come with sub aents but absolutely can be implemented in the same pattern just in code. Like really the way to think about this executive 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. But it's up to you how you how you write that code. But state that you have for example like memory. You might see memory here.
26:44 · The way you choose to record or inject memory lives in the exeutor, 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 executive. The actual state at runtime lives in the exo harness.
27:05 · Yeah. You have to se separate compute and storage basically in order to make it teleportable to resumable everything, right? Like people sloppily coming these things a lot.
27:19 · Then we can mention the secret store.
27:20 · 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
27:44 · 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 And so that secret is kind of injected in the execut without actually exposing it in the space where the tools can see what is being used which is in the container.
28:11 · Yeah. And also like an access log in case uh you need to sort of do some history of of debugging after something goes wrong.
28:20 · Yeah.
28:20 · Yeah. Exactly. Also I I guess like even the the the the very fact of secrets being accessed uh 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 and I often wish that there was more work on like monitoring of that kind of stuff where you typically would just have like it tail it pipes out to like a Slack channel and people just keep an eye on it. But that's that sounds terrible.
28:54 · Yeah.
28:54 · 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 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:12 · Yeah.
29:12 · Well, well, I mean, you you have the I guess the the leeway because you're designing Exo to, I guess, you know, put the recommended best practices in there from day one and then and you know, everyone who gets you harness gets uh the benefit.
29:26 · Yes. Yeah.
29:27 · I have further variants of this if uh 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? Uh does that change anything at all? just like voice agents or like things that have to respond in like relatively real time.
29:46 · If I can briefly just share if people want to go try this, I I want to point out where they can go.
29:50 · Yeah, you know, we we have our G GitHub here that is at github.com/exoharnness/exo and there is a 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 a oneline install script and that'll get you going and get you running and I can show what that looks like soon. But but I'll point out we also have Exo comes with some pre-built adapters.
30:18 · 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 an adapter for Discord, um 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 adapter.
Interruptible work and system architecture
30:42 · So you can have you can have Exo kind of join and chat with you in 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 yet where it's kind of Yeah. It's a pipeline cascade thing.
31:00 · Yeah.
31:00 · 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 open claw architecture. As wonderful as it is once an agent kind of goes and starts working on a thing in a thread that thread is not interruptable. As a thing is off working if you try to ping 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.
31:30 · You say, "Hey, do you know what's going on over in that other thread? Like why is it [laughter] not answering?"
31:35 · Which is like not entirely correct. So the way that we we're going to need to reinvent what that kind of interactive 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 will look much more like a systems osy 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 or you open tmux and you put it in a separate in a pane on the side.
32:05 · I I expect this will be an an architecture decision of how you put tasks in the background and expose them to the agent as they're running. That's the extent it might take.
32:13 · I thought I thought you were going to say, you know, you you send signals, right? Sigant or Sig whatever.
32:19 · Yeah.
32:19 · Yeah. Totally. No. No. Exactly. So So same way that you you can background a process and when it's done it'll send some signal. 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 that pub sub. I think that's the architectural systems thinking for me on this.
32:36 · Yep. Okay. So, I think that that that all makes sense. Then and then another sort of kind of housekeeping question, I guess. Did you implement ACP uh the protocol from Zed that normalizes over a lot of coding agents?
Normalization and protocols (like ACP)
32:52 · Do you know about it? Do do you have any opinions, differences of opinion?
32:56 · That's a great question. No, actually, we we haven't gotten there yet. I remember seeing it in the open claw architecture as a as a way of allowing spawning other coding agents um within within openclaw. That's actually a great suggestion for something to do next week.
33:08 · Yeah, throw throw your clanker at it.
33:10 · Throw it.
33:11 · Yeah, I mean you know you know I I think that everyone's trying to normalize. I think this 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. uh data bricks has like a slightly different one too and like well let's just figure out what what it is then but then also there's the just the general discomfort of like the the any common
33:39 · 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 pi right like that that's why openclaw adopting pi instead of saying like we will you know interop 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:02 · 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.
34:23 · You know, these pieces are hardening. I think it's start to think it 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:32 · Let's bring that in. Uh so again one of my favorite podcasts of of last year I think was an very great founder and systems thinker and all incredible thinker. Incredible thinker.
34:42 · What's he done basically like can you attribute credit to like what did Martin do? What did what did Arer do? And then also let's talk a bit about like what has been seen in production like what whatever stories you have.
Team roles: Martin Casado, Ankur Goyal, and Alex Krentsel
34:53 · Totally. Yeah, this project I think is pretty unique because it has these different very different people coming in. Uh Enkor is an incredible systems thinker, sees a lot of how people are using agents out in uh 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.
35:23 · I'm in the millu 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 been focused on evolutionary systems and AIdriven discovery and loops on how you improve things. You know loops really came into the discourse some a couple 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:50 · No, that's how these things go, right? Uh, but also, I don't know if you got the memo, but loops are dead. Graphs graphs is all we talk about now.
35:57 · Graphs are bad.
35:58 · Okay.
35:58 · Yeah, this is a post. This This is to be clear, this is a post. This is just influencers making fun of themselves for like, well, every few months you got to cycle it. So, you got something new to talk about.
36:09 · Do you know what's coming after graphs or I'd love a tip off?
36:12 · I don't know. Markdown is all you need again. I don't know.
36:15 · Yeah, I look forward to that. But to to go back to kind of we have 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 there you know encore is thinking about this at at brain trust we should get together and talk.
36:45 · 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 safety? And encore took a first stab at the layered architecture. uh and
37:05 · 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 this space of AIdriven discovery I was really wondering what if you collapse the AIdriven discovery loop into the executive itself provide and
37:27 · 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 it originally kind of driven by encore more we shifted to focus on this self-improvement that a lot of my research has been in that space and so I
37:52 · think my imprints are really there and Martin you know you said earlier hey oh maybe this just a VC just talking about oh yeah yeah right you you code Martin really codes you know Martine's really in this coding day-to-day so it's been super fun the the the the three of us working together. If you look at the commits, we're all there. So, our team is not just posing as I'm sure you know, but yeah, this is Yeah.
38:12 · Well, you know, you got to see you got to see the the proof in the pudding. I guess I guess the last question I 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 like what do you do?
Solving the evaluation and reward hacking problem
38:30 · This is such an excellent question. So let me let me say a few words about this. Um and this is also coming out of some of my research that I'm doing at Berkeley with Yan. We're about to put out a paper on exactly this which is in all these optimization problems the final difficulty is you always have to provide some evaluator and that evaluator has to kind of reflect your your 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 pernicious failure mode. So there's a couple cool things that we do for this.
39:02 · 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 inference 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.
39:21 · One of the things we did in Exo, which is really cool. Well, the exoh harness the conversation 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 the the executive has access to constructing context and also reasoning over the past conversations and the costs associated with different parts of those conversations.
39:42 · 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 I noticed I I asked, hey, 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 rearchitected its its own Discord adapter at runtime.
Production story: Driving down costs by 96
40:02 · Made changes, observed them, tested them to really scope down the context that was included in each of the LM calls as they were built by scoping it to certain conversations and certain threads only rather than pulling messages from across different threads in in Discord in a way that drove down the cost to I think like it was like a 96 decrease 96% decrease.
40:23 · And by the way, we committed this back afterwards. So the changes it made uh improved itself, decreases cost, and then we ended up committing that to the actual code that's that's there now.
40:31 · Are you doing this subject to no regressions in eval? You know, there's no box that says evals in in there. But like should an should an exo harness ship its own evals?
40:41 · 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 that's a reward hack reward hack exactly preventing reward hacking and so you definitely want some sort of eval evalish thing that it can
41:12 · go and check that 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?
41:20 · Are you including the right context?
41:22 · Context that makes a reasonable response possible. It's kind of more of a binary.
41:25 · 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 hold out 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 uh uh check that at 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 one.
41:48 · So I expect us to build out a bit more tooling in the process of in the in the context providing it that as it improves itself it should also track performance and define some way of tracking that.
41:59 · Well you know if you ever need an eval guy I've heard brain trust is pretty good. I don't know it might be might be biased here.
42:05 · That's exactly right. I I think we have the some of the leading people here in the room for exo thinking through that problem.
42:13 · Excellent. Okay. Well thank you for you know you're great speaker. Clearly you do this a lot. you're about to go teach in Ethiopia for for God knows why, but like uh thank you for spending some time with us, especially on your on your time off. So, this is excellent work and I'm really it's really inspired. I hope more people study this and also adapt the ideas. It does you don't even have to use the architecture if as long as you get the idea right. I think that it will make for much more generally useful agents which is something I I want.
42:40 · Yeah.
42:40 · Thanks for having me. I wanted to ask one other thing if if we have a minute. There's one other case I want to make that I think is of interest to this audience. Yeah, 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 6 months, which is we've moved from iterating on model weights, training model weights to iterating on this harness and this agent layer.
Why now? The convergence of code generation and harness development
43:09 · 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 LMS are producing output tokens in that same space.
43:30 · They're writing code. They're getting good at writing code. And so this is the crucial difference. You had LM before, but the process of improving the actual LM was changing weights. it was deltas.
43:40 · You do back propagation, 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?
43:50 · 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 is this. 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-reursive.
44:08 · It's not just autoc catalytic which is where you you use a computer to help design the next 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 this is in this 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 well I mean you know you want to be fully fully selfreing you got to train your own models right like you got to like hook up some GPUs and like well like you know the model's not good here let's fine tune there [laughter]
44:38 · agreed But I'll just point out that there you get autoc catalytic catalytic 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 in this.
44:49 · You're very purist about this.
Systems theory, Lisp, and future potential
44:51 · I'm very purist about this. I maybe coming from academia this is my my my fault. Yeah.
44:57 · Does this uh 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 uh you know that it's it is on the order of a programming language type of abstraction if you really think about it like that is a system and and programming language design and PLT uh program like theory does translate I feel I feel that a little bit.
45:22 · Yeah.
45:22 · Yeah. That's a great comparison. I had thought about that. Yeah. There's probably some some comparison to draw here to some sort of programming language that it it contains its own contract constructs within itself.
45:33 · Yeah. Lisp.
45:34 · Yeah. Yeah. Lisp definitely comes to mind.
45:36 · Yes.
45:36 · 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 is this takeoff moment will come from being iterating in the same layer that you are producing. I 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:53 · Yeah.
45:53 · Excellent. Well, uh, I am very glad to at least make this initial contact. I'm sure this is not the the 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 there's more that that we'll we'll see from you, but thanks for the overview.
46:09 · Thanks so much for having me on and a really fun conversation. I look forward to talking.
46:12 · We'll put your we'll put your contact details below. If people want to contribute in any meaningful way, uh, what is the best place to get started?
46:20 · Yes, we so welcome contributors. Um, 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/exoharnness/exo.
46:32 · 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. Um, it'll be linked below.
46:47 · Yeah, pro pro tip. When you join these kinds of early communities, it's actually not just about the project. It's also about the people and uh 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. Um so awesome. All right. Well, I I'll I'll cut it there. Thank you so much.
47:05 · Thank you.