Shawn: Okay, we're here in the remote studio with Alex Cransel, I guess, of EXO, but also UC Berkeley. Welcome.

Alex: Thank you so much. Happy to be here.

Shawn: 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.

Alex: 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.

Shawn: 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 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 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.

Alex: 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.

Shawn: 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.

Alex: Yeah. Yeah. We're kind of come from systems backgrounds. My background is fully in systems and I'll talk more about that later. But just briefly to introduce EXO so we're all on the same page. In a nutshell, Exo is an agent that's fully recursive. So it's able to safely edit all aspects of itself at runtime to kind of get better at the task that it's working on. And it's enabled by this very kind of minimal but opinionated harness architecture that splits out different pieces of what an agent is today into components that can be safely isolated from each other and thus safely evolved. 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. 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. 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. 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? 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. 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.

Shawn: Yeah. 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 you want, but the first comment is people who aren't used to this are like scared of code modifying itself because they're like wow it just modified itself without me asking. So those would be my two commentary pieces there. Wherever you want,

Alex: they're great points. Let me touch on both. So OpenClaw came around and took off in really took off in February. And I think you're right. The thing that OpenClaw really discovered was how to make an agentic system that feels magical in that it kind of adapts to your workflow. It is adaptable. But a lot of the self-improvement, self-modification you see in OpenClaw is offline. So you run it, it's like, oh, I think we need this tool, it writes the tool, and then you use it the next run. Whereas with Exo, we want it to happen at runtime. And you also mentioned, yeah, the fear of having something write its own code, and I think without guards that is a totally justified fear. And this is why the architecture of Exo splits out into these three separate components. So you have the executor, the exo harness, and the sandbox. And you have to isolate the sandbox, which is where the tools run, which is where bad things could happen, deleting files or making bad API requests, from the harness itself, which is running outside of that and manages the evolution of the system and manages state and storage and secrets. And we think that physical separation of the thing executing the policy from the thing interacting with the outside world and potentially doing bad things is how you make this safe to do. That's really the crux of it. With regards to OpenClaw, it's very focused on this notion of skills. It has certain points where you can insert additional skills. It has changed the very machinery of what skills are for your job.

Shawn: Yeah. And the policies that make it up. 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.

Alex: 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 really a deep dive on openclaw because it came out uh you know a couple months ago. So as we look at this 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.

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

Alex: to figure things out.

Alex: 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 still trusting the outer machine to change the inner one. And in that sense, I think it's a more powerful way, a more fully expressive way of doing self self-improvement than an outer system. That's

Shawn: Yeah, fair enough.

Alex: Okay, now maybe let me talk about I I'm happy to talk through the exo harness exo architecture if that's useful.

Shawn: Yeah, let's do it.

Alex: Yeah,

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

Alex: 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 Shenker. So like my point of view here is coming from a very traditional computer systems design background where you think about 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.

Shawn: 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 school or systems orchestrating models people obviously because it's the school of uh what's the what's the term compound um AI

Alex: compound AI systems yeah uh yeah

Alex: so so so yes I I I do I do I do see both sides I do think that uh there is some tension that people don't address with regards to how large model researchers think about, oh, eventually when we have a 10 trillion parameter model we'll wash things away, you know, will wash the harness away. And obviously over here we're building harnesses. Both can be true.

Shawn: 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. And so you must have some outer entity that enforces policies. The key with these policies and control flow as shown here is that they run outside the sandbox that it's running on. And those together define an agent as we think about them today. Hopefully that makes sense.

Shawn: 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.

Alex: Yeah. So I'll go one more slide to kind of just make this fully concrete and then we'll go into all the details. So again, this is my view of the architecture for Exo. As you can see, the three most important things in the harness is: one, the event log, which stores events. Two, the state library, which is responsible for storing state that must persist across execution of a task, things like secrets, variables, other files that can persist and be read later. And three, code teleportation. This is why we use Daytona for sandbox execution, because they allow teleporting code, which means the run time is packageable, portable, resumeable anywhere. And when the agent is executing tools in the sandbox and wants to change itself, it reads the code of the system as it is, proposes a change, and then commits that through the event log to the harness itself, which immediately re-asssembles, adjust adapters, etc., etc. So that is the final step that allows EXO to be kind of fully recursively self.

Shawn: 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 harness. Is that kind of the only reason that people do teleportation of code of agent state. Is there something else that this refers to?

Alex: 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 and resuming state. But where it starts to become interesting is if you are spawning out sub agents and you want to distribute the work or you have resource constraints where you want to move the running agent to a different physical machine. For example, you are running locally and you want to move it to the cloud because you want to give access to some sort of resources that aren't available locally. So that's the benefit I see of teleportation.

Shawn: 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...

Alex: 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 Harness to self-improve is a very unique direction. And to enable that, Daytona gives you this really great out of the box development environment manager that fits really nicely as a sandbox.

Shawn: Yeah.

Alex: 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 in your policy that says when and how to spawn a sub task. The actual state at runtime lives in the exo harness.

Shawn: Yeah. You have to se separate compute and storage basically

Alex: in order to make it

Shawn: teleportable to resumable everything, right? Like people sloppily coming these things a lot.

Alex: Then we can mention the secret store. The secret store is really great. We want it to live in the exo harness so that it's not exposed directly to the container where the tools are executing. You want them to be accessible by the execut without actually exposing it in the space where the tools can see what is being used which is in the container.

Shawn: 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.

Alex: 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 trigger an alert. Right now a lot of people 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.

Shawn: Yeah. 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 people are 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.

Shawn: Yeah. 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.

Alex: Yes. Yeah.

Alex: 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.

Alex: If I can briefly just share if people want to go try this, I I want to point out where they can go.

Alex: 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. 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. 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

Shawn: Yeah. It's a pipeline cascade thing.

Alex: 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 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. You say, "Hey, do you know what's going on over in that other thread? Like why is it [laughter] not answering?"

Alex: 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. 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.

Shawn: I thought I thought you were going to say, you know, you you send signals, right? Sigant or Sig whatever.

Alex: 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 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. 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? Do you know about it? Do do you have any opinions, differences of opinion?

Alex: 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.

Shawn: Yeah, throw throw your clanker at it. Throw it.

Shawn: 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 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.

Alex: No, that makes sense. I I think it's something we'll look into. We've been really focused on first what does the architecture need to look like to enable self-improvement and then second building out that kind of self-improving agent piece. And I think now that we have people starting to want to use Exo for different things, you know, this is running in production. The Exo harness and agents built over top of it is running in production at Brain Trust. You know, 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.

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

Alex: incredible thinker. Incredible thinker.

Shawn: 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.

Alex: 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. 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. No,

Shawn: 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.

Alex: Graphs are bad.

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

Shawn: Do you know what's coming after graphs or I'd love a tip off?

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

Shawn: 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 talks on how automated code modifications can improve performance. We hacked away, and 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.

Shawn: 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... 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?

Alex: 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 the research work I've done on automated systems discovery. If you don't give it any goal, if you just say "improve yourself," it won't do anything. But if you give it a goal that has some sort of wiggle room, for example, a classic systems one of "run with the lowest cost," a very funny failure mode we saw in our Discord running instance was that Exo discovered that the cheapest way for it to run was to just not respond to messages. Because that used zero tokens, which was a 96% reduction in costs! And it successfully made improved itself, decreases cost, and then we ended up committing that to the actual code that's that's there now.

Shawn: 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?

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

Shawn: that's a reward hack

Alex: reward hack exactly preventing reward hacking and so you definitely want some 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? Are you including the right context? Context that makes a reasonable response possible. It's kind of more of a binary. It's easier to check. If you have an insurance agent that's trying to make the right decisions, you might want some sort of 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. 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.

Shawn: 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.

Alex: 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.

Shawn: 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.

Alex: 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 audience. Yeah,

Alex: 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. 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. 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. 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? 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. 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

Shawn: 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]

Alex: 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.

Shawn: You're very purist about this.

Alex: I'm very purist about this. I maybe coming from academia this is my my my fault. Yeah.

Shawn: 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.

Alex: 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 language that it it contains its own contract constructs within itself.

Shawn: Yeah. Lisp.

Alex: Yeah. Yeah. Lisp definitely comes to mind.

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

Alex: 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.

Shawn: 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 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.

Alex: Thanks so much for having me on and a really fun conversation. I look forward to talking.

Shawn: 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?

Alex: 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. 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.

Shawn: 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.

Alex: Thank you.