Exo: Harnesses should see their own code and logs — Alex Krentsel

0:03 Okay, we're here in the remote studio with Alex Cransel, I guess, of EXO, but also UC Berkeley. Welcome. >> Thank you so much. Happy to be here. >> The reason we're recording is because I

0:12 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

0:22 had watched your lecture and then didn't register your name on OpenClaw. >> 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

0:29 on just talking about the architecture. I didn't go to pitch myself. >> Yeah. But also like maybe like your face on there, but also you know just like other other work. But uh you know that's

0:39 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. When I actually talked with Martin on

0:52 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

1:02 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

1:13 then we can work our way back to whatever other background that you want to do. >> Yeah, for sure. Thank you. I mean, I'll start by saying, yeah, I I've been

1:20 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

1:30 my adviser, my PhD adviser, Scott Anker, at Berkeley. So, that's kind of our shared lineage. >> Shared shared lineage. Yeah. He was my board member when I was working at

1:39 Nellifi and I was working I was learning about uh you know, virtualized networks and all those things. >> Yeah. Yeah. We're kind of come from systems backgrounds. My background is

1:50 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

2:01 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

2:11 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

2:23 should think about it as an agent that really does full recursive self-improvement. Um, and I think it's really enabled today by the fact that we're we're entering a new layer in the

2:34 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

2:44 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 I think the

2:56 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

3:07 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,

3:25 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?

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

3:48 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

3:56 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

4:07 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

4:16 change itself at runtime. And this is the the kind of thesis for Exo. >> Yeah. And I'll maybe add a couple pieces of commentary here. Uh the first people to realize this was probably the PI

4:26 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

4:36 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

4:45 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. So so uh for for my two companies I have an internal bot that does work

4:56 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

5:06 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

5:17 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. Uh and so then the question the push back is like when do you need that AGI

5:27 feeling of like wow it just modified itself without me asking. So those would be my two commentary pieces there. Wherever you want, >> they're great points. Let me touch on

5:35 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

5:46 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 if we were to go and look at

5:57 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

6:08 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. It gets injected in context every time the LM you know is

6:19 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

6:31 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

6:39 skill for this. Let me go install this skill. 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

6:48 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

6:56 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

7:08 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

7:18 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

7:28 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

7:47 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

7:58 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

8:07 can insert additional skills. It has changed the very machinery of what skills are for your job. >> Yeah. And the policies that make it up. Uh I I was just wanted to if if actually

8:16 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. 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

8:35 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

8:45 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

8:56 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

9:07 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

9:16 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

9:26 allows you to say here's a different way of storing and indexing your memories. 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

9:35 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

9:47 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 read here, all of the connective arrows, all of the

9:55 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

10:12 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

10:23 the agent itself. >> 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

10:32 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

10:42 machines to >> to figure things out. >> 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

10:50 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

11:00 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

11:11 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

11:21 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

11:34 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 Pokémon and while it's running the

11:44 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

11:55 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

12:03 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:12 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,

12:21 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. >> Yeah, let's do it. >> Yeah,

12:47 >> 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

12:56 >> 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

13:07 strictly from systems. I started my PhD before chat JPT really took off and I was a core networking person. So I'm a I have done my work kind of in core systems designing wider network

13:19 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

13:28 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. 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

13:48 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,

14:15 will wash the harness away. And obviously over here we're building harnesses. Both can be true. >> I agree with you. My bet is this though

14:24 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

14:36 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

14:45 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

14:56 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

15:04 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

15:16 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

15:28 here, uh, when you think of cloud code, cloud 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

15:39 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

15:53 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

16:02 know dangerously skip permissions so that in this VM and and by the way I can accept here. Uh oh, this is kind of risky because I've actually logged in. I have to have my like maybe I have some

16:11 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

16:20 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

16:29 design here. It decomposes an agent into an executor, an exohornness, and a sandbox. And these layers all have different properties. This is very important. So, we think of the harness,

16:43 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

16:56 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

17:06 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 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

17:29 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

17:38 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. Or

17:50 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

18:01 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

18:12 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 executive can propose changes to itself

18:24 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 ex harness provides a mechanism for snapshots. And what this is really

18:35 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

18:46 fundamental architecture behind behind Exo. And I want to point out what these layers give us. So an agent now and this is the the hardest piece I think in understanding exo and

19:00 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

19:12 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. >> I like this breakdown is very clear. I

19:23 have questions about some of the bullet points here, but I want to get the full top level first before we go into details. >> Yeah. So I'll go one more slide to kind

19:33 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

19:44 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

19:52 policies all the compaction tools skills LM call etc. 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

20:06 its own code for the executive itself. 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

20:21 in the exo harness a a special guard guardian kind of process that will allow the executive to be rebuilt at runtime midstep and also provides some sort of uh kind of soaking process where after

20:36 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

20:46 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. It can ask to rebuild its own code and swap midrun and as a result

20:57 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

21:06 adapters, etc., etc. So that is the final step that allows EXO to be kind of fully recursively self. >> It also means that propo changes can be parallelizable because

21:19 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? You know, teleportation classically, I think people want to run things locally

21:47 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

21:57 that this refers to? >> 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

22:09 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

22:17 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

22:27 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

22:37 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. There's a stream of events

22:48 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

22:58 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

23:07 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

23:17 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

23:25 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

23:33 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

23:52 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

24:00 off, so I only give it as an example. >> Yeah. 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

24:10 is driving most of Daytona's growth right now, which is very funny. Obviously, Daytona has good sales and I I should be clear that Daytona has done a lot of other GTM work outside of just

24:21 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

24:33 good experiences there. Okay, so I want to keep going on other parts. Uh can we go back to the architecture diagram? I think there are some things here that can be maybe like dived into

24:51 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

25:06 uh you know prompt and tool call and LM optimization um which which does help. Uh, and then yes, actually I I have often thought about secret store, which most agent

25:17 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

25:28 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

25:36 harness here as I'm describing it, this architecture. 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

25:44 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. >> 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

26:06 that is a kind of a decision that happens. Yeah. 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 executive and is used at

26:16 runtime. 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

26:28 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

26:37 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. The way you choose to record or inject memory lives in the

26:48 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

27:00 executive. The actual state at runtime lives in the exo harness. >> Yeah. You have to se separate compute and storage basically >> in order to make it

27:11 >> teleportable to resumable everything, right? Like people sloppily coming these things a lot. >> Then we can mention the secret store. The secret store is really great. We

27:22 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

27:32 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

27:54 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

28:09 being used which is in the container. >> 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. 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

28:32 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

28:45 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. >> Yeah. Yeah. Yeah. Yeah. Yeah. I think

28:55 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

29:05 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. >> Yeah. Well, well, I mean, you you have

29:13 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

29:25 uh the benefit. >> Yes. Yeah. >> 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

29:35 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. >> Yeah, you know, we we have our G GitHub here

29:55 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

30:08 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

30:17 out we also have Exo comes with some pre-built 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

30:25 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

30:38 into the answer to your question. We actually went and built voice mode into Exo to the to the Discord adapter. So you can have you can have Exo kind of join and chat with you in in Discord in

30:50 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. 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

31:11 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

31:21 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

31:29 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 [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

31:46 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

31:59 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. I I expect this will be an an

32:08 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. >> I thought I thought you were going to

32:15 say, you know, you you send signals, right? Sigant or Sig whatever. >> Yeah. Yeah. Totally. No. No. Exactly. So So same way that you you can background a process and when it's done it'll send

32:24 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

32:31 architectural systems thinking for me on this. Yep. Okay. So, I think that that that all makes sense. Then and then another sort of kind of housekeeping question, I

32:42 guess. Did you implement ACP uh the protocol from Zed that normalizes over a lot of coding agents? 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

33:04 within openclaw. That's actually a great suggestion for something to do next week. >> Yeah, throw throw your clanker at it. 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

33:21 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

33:34 then also there's the just the general discomfort of like the the any common protocol is always going to be lowest common denominator so and then what right like does it actually provide the

33:45 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

33:56 It makes makes it simpler to be to be super honest like you don't have to have modules for everything. >> No, that makes sense. I I think it's something we'll look into. We've been

34:05 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

34:15 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

34:52 whatever stories you have. >> 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

35:01 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

35:13 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

35:20 very technical. And you have me as a as a as a researcher at Berkeley. 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

35:33 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

35:42 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. >> Okay. Yeah, this is a post. This This is to be clear, this is a post. This is just influencers making fun of themselves for

36:05 like, well, every few months you got to cycle it. So, you got something new to talk about. >> 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. >> 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

36:24 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

36:34 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

36:44 at 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

36:50 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

37:02 at the layered architecture. uh 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

37:15 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

37:37 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

37:48 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 just a VC just talking about oh yeah yeah right you you code Martin

38:00 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

38:08 is not just posing as I'm sure you know, but yeah, this is Yeah. >> 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,

38:18 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? >> This is such an excellent question. So

38:32 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

38:40 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

38:50 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

38:58 pernicious failure mode. So there's a couple 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

39:07 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,

39:15 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. Well, the exoh harness

39:24 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

39:37 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

39:46 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

39:54 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. Made

40:04 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

40:13 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. And by the way, we committed this back

40:24 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. >> Are you doing this subject to no

40:33 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? >> Yeah, with the Discord case, it's a

40:43 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

40:52 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

41:00 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

41:09 sort of eval evalish thing that it can 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? 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

41:28 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

41:38 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. So I expect us to build out a bit more

41:50 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. >> Well you know if you ever need an eval

42:01 guy I've heard brain trust is pretty good. I don't know it might be might be biased here. >> That's exactly right. I I think we have the some of the leading people here in

42:10 the room for exo thinking through that problem. >> Excellent. Okay. Well thank you for you know you're great speaker. Clearly you do this a lot. you're about to go teach

42:18 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

42:29 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

42:38 agents which is something I I want. >> Yeah. 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

42:46 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

42:54 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

43:04 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

43:18 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

43:48 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

43:56 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

44:07 entering a stage where this is fully self-reursive. 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

44:15 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

44:24 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

44:31 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] >> agreed But I'll just point out that

44:40 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. >> I'm very purist about this. I maybe coming from academia this is my my my fault. Yeah. >> Does this uh does this remind you of

44:59 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

45:09 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

45:21 little bit. >> Yeah. 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

45:28 language that it it contains its own contract constructs within itself. >> Yeah. Lisp. >> Yeah. Yeah. Lisp definitely comes to mind.

45:36 >> 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 is this takeoff moment will come from

45:44 >> 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. 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

46:02 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. >> Thanks so much for having me on and a

46:10 really fun conversation. I look forward to talking. >> We'll put your we'll put your contact details below. If people want to contribute in any meaningful way, uh,

46:18 what is the best place to get started? >> 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

46:28 our GitHub, github.com/exoharnness/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

46:38 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.

46:44 Um, it'll be linked below. >> 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

46:53 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

47:02 I'll cut it there. Thank you so much. >> Thank you.