Jeff Huber
All right, Lance, welcome. Great to be here. I've always enjoyed this, this pod. I've listened to a bunch of them, so it's a pleasure to be here.
Lance Martin
Awesome to have you. Okay. The topic du jour is all things context engineering, compound AI systems, let's see, agent harnesses, et cetera. You've been writing about this for at least the last six months, maybe longer. Yeah. Maybe like give us quickly an introduction to the motivations of like what, why context engineering and then like what's changing and like, yeah, we'll go there.
Jeff Huber
Yeah, it's great. I mean, it's great to talk about this. We've been circling around each other on Twitter for months and maybe years, actually. So, yep. You know, I think many of us had an experience building our first agent. And what we found is not only do you have to do prompt engineering, you have to instruct the agent properly, but the agent goes off and performs actions, tool calls, and it receives context from those actions. And those things accumulate in the context window. I remember I took a deep research agent. It was a deep research workflow initially. I turned it into an agent. I just let it run. I let it perform web searches autonomously in a loop until some termination. And the overall cost was something like $3, and it was hundreds of thousands of tokens of context. And I think what people realize in building agents is, ooh, this is tricky because not only do I now have to do prompt engineering, I need to engineer instructions. That's still important, of course. But they go ahead and perform actions that receive context. So you have to manage that in some way. And I think there's a couple reasons for that. One is your nice work on context rot, for example. As context grows, performance degrades. And this has been observed by many people, including you. Yep. The other point is actually more practical even, which is just cost and latency. So, for example, my little deep research agent, the first time I kind of turned it into an agent, it was like, yeah, $3 per run. It's cost prohibitive, and it was quite slow. And I think a lot of people had that experience over the last year when they kind of migrated over to agents. And Karpathy kind of coined sometime in the spring this notion of context engineering. Like, hey, it's actually important to curate the information or context at every turn of an agent. And I think that really resonated. I started talking about that quite a bit. I did a meetup with Drew Brunig. He did some really nice writing on this topic. And I think it kind of took hold because people at Visceral were having that experience collectively of like, oh, yeah, it's actually tricky to build agents because not only do you have to manage prompts, you have to manage the context flowing in from these actions. And I think it's really the motivation. And actually, I think your work on context rot was very nice along these lines. Yeah.
Lance Martin
Yeah. I mean, it's something we saw was a real our whole focus is helping builders build useful AI systems. And like, you know, something we saw routinely in the people I worked with was like a struggle to get the most performance perform at like larger token context windows. Yeah. And And so we can actually study that and measure that. And even to this day, I guess I actually don't know, obviously, the internals. Though now all the large labs have acknowledged that this is the case, to my understanding. When we released that, there was no acknowledgment from large labs that that was the case. And now they acknowledge it. I've not seen any independent work from them. And maybe they have their own internal benchmarks. But I think that now we're kind of exiting bit of the era of like AGI maximalism. I think it's sort of like self-evident. You don't see as much of the narrative online about like, even like safety stuff. Maybe it's like actually underrated now. You know, safety was actually overrated for a while. You know, opening eyes afraid to release GPT-3. You know, and like now maybe safety is actually underrated in a way. But like, yeah, I think we kind of moved out of like AGI maximalism. Yeah. and into just like, okay, great. Like, you know, we have X trillions of dollars invested now into like the AI stack across the board. Like, we better see some value out of this in the near term or it's all going to come crashing down. Yeah, yeah, yeah. Maybe it's motivated by that, but.
Jeff Huber
Yeah, you know, it's interesting. And I think if you reflect back on 2025, I was doing this at the end of the year, I wrote kind of a new post on this on my Twitter. I think we saw some interesting trends with agents, you know, along these lines of content engineering. And I think maybe the most interesting trend was basically giving an agent a computer, but not in the way people necessarily thought at the beginning of the year. Like we can maybe reflect on this a little bit. Computer use has been discussed for years now. And I think the mental model originally was, okay, I'm gonna give an alum access to kind of my desktop and it can perform actions, it can click around. But actually what occurred more is, no, using a computer as a primitive for an agent, specifically giving it access to like a shell and a file system. And this helps significantly with context management problem. And, you know, what's funny is. In the past year, model context protocol drops. So suddenly, oh, I can like access all these tools. That's great. But I think the interesting insight is some of those popular agents, like I did a thing with Manus this year. Obviously, they just got bought by Meta. Cloud Code, obviously, was tremendously successful. And others, there's many kind of variants of kind of Cloud Code, now open source, that are really good. I've done some work on deep agents. There's OpenCode, AmpCode, and there's many. Yep. The insight is actually all of them use very few tools. Like what's pretty interesting is Cloud Code uses like a dozen tools. Manus uses less than 20 tools. Amp Code, similarly, there was a nice talk from the kind of lead engineer there. He was talking about how they curated the action space. And that works because you can use a computer to offload actions. Right. And one of the things that we kind of saw is that tools blowed up context. Yes. You know, for example, like the GitHub MCP server is like 35,000 tokens and 35 tools. Yeah. So if you load that in, now it's easier and easier to add tools to your agents. Yeah. But what happens is you blow up the context and they can be confusing. Yeah. And so an interesting trend that occurred over the course of the year, which informs a lot of the context engineering stuff that we might talk about, is this idea of giving agents a computer. And when you do that, a lot of interesting things fall out, which we could talk about a little bit.
Lance Martin
Yeah, I think there was this period of a few months at least where the discourse was very much about oh, no, we're giving this agent access to the linear MCP, and it has a bajillion tools, and it's really hard to get the agent to pick the right tool. And of course, I'm a bit of a hammer guy, so everything does look like a nail, admittedly. But I was like, why don't we just search for the right tool, guys? Yeah, that's right. That's actually what now seems to be the evolving emerging pattern is just that, right? Either literally MCP tool search or file system offloading, which is really just, again, I mean, grep may be centric, obviously, right? But it's still some version of search at the end of the day.
Jeff Huber
This is a super interesting to talk about. So I think there's another trend I noticed. So in addition to, you know, you give an agent a computer, that's great. Then what you can do is build what I kind of call, and I kind of got this from Manus. I did a webinar with, with Peak from Manus, their, their chief science officer, a multi-tier action space. And so the interesting point is there's a tool calling layer, and then there is basically the computer and the computer can have different, can perform different actions in a few ways we'll talk about. But at the tool calling layer, you're exactly right. And we can be, we talk about kind of there, you can do progressive disclosure of tools rather than dumping all those tools into context using a tool search tool. So like Anthropic talks about this now. And I'd done some work on this previously. There's a thing, there's a paper called Big Tool. Do you remember that? Where basically they just, and this actually is up your alley. So the index tool descriptions and just do semantic search over tool descriptions to fetch the right tool for the task makes sense. So the idea is building out a multi-tier action space with tool calling at the bottom layer where you can do things for progressive disclosure rather than dumping tool definitions like tool search. That's one thing you can do. But not only that, you actually can push those actions from the tool calling layer out to the computer. And I think that's the big trend. That's actually why... Manus, Cloud Code, use only like a dozen tools, but they can do tons of things. That's kind of a paradox. I think, and this was actually legitimate confusion I had, or kind of view I had years ago, or the first few years of agents. okay, I want my agent to perform n actions. Each action I'm going to encapsulate as like a Python script and bind that as an individual tool. So n actions equals n tools. And that's not what played out. What played out is, no, a few atomic tools that can do very general things and push all those actions out to the computer. So a good example here is even for MCP there's a trend of, no, push that out to the computer. So don't take that MCP server and bind it as tools to the LLM. Instead, like, Cursor does this. They had a blog post. It was interesting. They take their MCP servers, whatever ones you bind to the model, and they actually sync them to the file system. So they sync all the individual tools as files. It's clever, right? So then what you do is you basically just do, like, file search, like you said. Could be grep, could be otherwise. It could be indexed. Who cares? But that's the point. So you're pushing it out to the computer. It doesn't live in context. Push them out to the computer. In that case, it's files. managed to something similar, but actually they use something different. They do like a, they built a CLI for MCP. Yep. So it's like a CLI utility and like, I'm not sure how it works, but the point is they made the same point. Like do not take all these MCP servers and bind them to the model.
Lance Martin
Yep.
Jeff Huber
Push that out to the computer. Yep. Then you get into, you know, the computer all says bash utilities that Elm can use. That's great. It has whatever installed CLIs are available. That's great. And then there is being able to write code. So it can chain actions. And this is an old idea. The Kodak paper 2024 talked about this basically. instead of performing classic tool calling, just allow agents to compose actions by writing scripts. Simple idea, great idea. Manus talks about that quite a bit. That's what they did. So overall, if you roll it all back, it's like, okay, we have agents, we give them a computer, give them a few simple atomic tools to drive that computer, and then just push all our actions out to the computer. Like you said, you could do a tool search tool, the tool layer, and people can do that. But I think also people are saying, no, I'm just going to push my actions out to the computer, sync MCP search to the file system, let the agent write code as an example, use kind of built-in CLIs. And that's like the trend we saw. And it's kind of a nice architecture because it keeps that tool calling layer really thin, a few atomic tools, doesn't bloat the context. And for your actions, they can live out in this separate, in the computer basically.
Lance Martin
What is, I would reciprocate, I guess like, Thinking about like the state of things right now, there's both like, you know, the best practices. We don't know how many of these are like stable, long term best practices. Right. And there's also like stuff that's on like the edge and on the margin. Interesting, crazy ideas for how this will evolve. Like let's take first like the base case, which is, you know, like if i want to build an agent today that does uh well from the top of mind which i'll share a little bit about if you're interested what building is like this sort of like gtm engineering right agent system um right and uh gtm like good market yeah go to market okay yeah okay you know right sales account account research contact research like enrichment like yeah yeah right like i guess we don't have to use that exact example if you don't want to, but like, give me, give me like your mental picture. It could be something that you've built recently, either for, you know, personal or work. Like, you know, what, what is like kind of that, that harness look like today, I guess, like how would you set it up?
Jeff Huber
Yeah. Let's walk through that. I mean, that's a great one. So I actually spent a lot of time working on the deep agents harness at Lang chain. So that's an open source kind of, it's kind of a cloud code implementation style agent, but it's of general purpose. And I did a lot with that. I built, I built the skill system for it and so forth. So let's kind of talk through how, you know, harnesses are structured. Yeah. And this is just like one particular take on it, but it kind of captures a lot of the insights I think we've seen. So basically, first, how's the action space? So the action space is a multi-tier action space. a small number of atomic tools for the reasons we mentioned that saves tokens. It results in less confusion from the LLM. A few tools that are pretty simple that allow the agent to control a computer. So it could be like running locally, could be a virtual computer either way. So DeepAge is what I worked on, supports both. So that's point one. At the tool calling layer, a few simple tools similar to cloud code. I think that's a pretty good pattern. Manus uses it, AMP code, many, many kind of converged on like a few pretty simple atomic tools, glob, grep, file read write, things like that, right? That's kind of obvious. The second concept, I think, is progressively disclose things to the agent. So this progressive disclosure idea. I think the new skill standard for anthropics is a great example of this. So basically, it's a nice way to give an agent different standard operating procedures, instructed how to use built-in CLIs or tools, or maybe the tool layer is kind of more stable. But skills, I think, typically, in what I've seen, will give the agent like... SOPs for doing different things in the computer, like using different installed CLIs, or like writing code for particular tasks. So like I built skills, for example, for a bunch of things. I have a skill for writing, which I use with Cloud Code, which I use with Deep Agents, and it basically takes Strunk and White's Elements of Style, classic book on writing. It encapsulates that. I did this with my friend Noah Breer, who's really like a great writer. He kind of gave me the idea. We iterated on it together. But basically it's literally just a markdown file, a skill.md file, right? That's kind of the skill standard that lives on the file system. And that kind of has clear instructions from some of my own writing and like kind of trial and error, as well as from the book about how to write. So that's an example. I have a deep research skill that I built for deep agents and so forth. So, you know, again, point one, a very kind of thin, you know, tool calling layer, access to computer, progressive disclosure of context that can live on the computer, for example, for skills, they live in files, the agent can pull them in as needed. for like any command line utility. So actually, this is another funny one. I recently built this little utility called Langsmith Fetch. It's just like a simple command line utility. It allows you to get traces from Langsmith. And I built a number of skills that basically instruct deep agents to, when they're writing Langraph code, as an example, which always logs to Langsmith, It basically instructs, hey, if I'm debugging something and I want to grab the Langsmith trace, like here's how to use this CLI. So anyway, that's another good example of skills and how it can instruct an agent to use particular CLIs. So thin tool calling layer, progressive disclosure. Now let's talk through some of the kind of the tricks and techniques. So I think this idea of context offloading is a good one. And we've seen this quite a bit. So Manus does this. So basically, tool results can be token heavy. They get dumped into the chat history. They accumulate over time. And they're sent through each turn, which you don't want. And so kind of a trend is to offload them, to save them to the file system. Yep. And, like, you know, give the agent a pointer. Here is the tool result. This is maybe a summary. Here's the full result if you want to retrieve it. Mm-hmm. I think that's a good technique. Yep. So offload old stuff. And actually, Anthropic just added their SDK. It's called context editing. We had the notion of this as well. But this context of context offload is a good idea. So basically, offload old tool results. A related idea is offloading plans. So not only can you offload kind of old contacts and tools, but you can offload a plan. And I think this is actually... A scratchpad thing. As an example, a scratchpad concept. This is a good idea. So basically, Manus talks about... like they initially saved like a Manus to do that MD file to the Manus file system. Yeah. And they talk about in a blog post this idea of recitation. So like while an agent is performing a task, you can pull the plan back into context to like reinforce objectives. Kind of an intuitive idea. I think that's a good that's kind of a good trick. We've seen a lot of variants of this. We've saw like the Ralph Wiggum loop, which we could talk about later, but that kind of went viral on Twitter over the break. And One of the key components of that is just like a plan file that basically lives in the file system that each loop of the agent reads, picks a task from, and continues. So anyway, the point is offloading context is another useful technique. And you can offload two results. You can offload plans, read them both back into context as needed. And it saves the context window a bunch. So that's another principle. You know, one that's a little bit underappreciated, but I think is very useful, is caching context. So there was some interesting dialogue on this recently. Manus talks about cache hit rate as one of the most important metrics for production agents. And it makes sense. It's basically like, you know, you have this chat history. It can be long. And just cache it. and you know every incremental turn of your agent you're only in the kv cash correct so you're only adding um you know one two result at every turn let's see this big history that's invariant or it should be and that's like kind of the right we can talk about that more but the invariancy is not for reliability reasons so much as it is for speed and cost speed and cost yeah yeah the speed and cost take so so that that's another trick that you can add i think is very good so so i would say offloading caching these are some of like the agent tricks i think Another is context isolation. So subagents, this is talked about a lot. If you have an atomic task that you can kind of assign to a particular subagent and isolate all the context associated with that. Like research is a classic.
Lance Martin
Highly parallelizable.
Jeff Huber
Highly parallelizable. Highly parallelizable. And what we've seen is there's been some good interviews with Boris from Cloud Code. He talks about how they use subagents frequently within the Cloud Code team to do like code review, just like kick off and subagents for like each of these end tasks they want to like, you know, check for given PR, migrations, lint rules, things that are easily parallelizable. Subagents are kind of like a really good thing to do. Yep. I also think another interesting one is for long run agents, like the Ralph Wiggum loop. So tell us what is the Ralph Wiggum loop? This is fun. So Ralph Wiggum is a character from The Simpsons that I'm in danger thing. So basically it's a way to perform long running tasks with agents. And it's like a pretty simple idea. And actually he put it out like last July, but it just kind of caught fire. Okay. You never know how things catch fire online. Yeah. Online's a funny place. It is. But the idea is simply this, like you basically have a particular five, this is like one implementation. of it, but the idea is more general. It's a way to chain agents for long-running tasks. A good way to set it up is, and Anthropic put a little piece out on this, you have a plan file, which is just basically like a list of tasks that you want done. And this can be performed up front, maybe by the human or maybe an independent agent could generate the plan. And you have a file system. Like we said, a major primitive now is giving agents access to the file system. That's fine. And you have like a progress.txt file, which is like a scratch pad. and you kick off a loop. So one agent picks a task from the list, does that task, commits it all to the file system, that's fine, and updates the task list saying I did this, and writes some notes to progress.txt. That's all done by one agent in one context window. Agent two picks up on the next loop, reads git history, reads progress.txt, then reflects on the task list, does the next task. And this just proceeds until you're done. Pretty simple idea. But there's a plug-in for it for Cloud Code. It seems to be pretty effective. I think Vivek from LangChain just did it for deep agents. It's a simple idea that basically the insight is for long-running tasks, you can't fit the whole task in a single context window. So it's related to the idea of context isolation. So isolate individual tasks from a spec to different sub-agents, let that sub-agent cook. and let the agents communicate via Git, the file system in this progress.txt file. Pretty clever, simple idea, seems to be effective. So that's another good example of isolation. So we basically have a few interesting tricks We have give your agent a computer. We have keep the tool calling layer thin. Use progressive disclosure to sync things or to kind of discover context from the file system. This could be tools. This could be SOPs as skills. Use sub-agents for context isolation. You can use it in different ways for parallelization, for kind of these long running tasks. Caching, clever way to save costs and time. Offloading, nice way to clean, to kind of keep your context window clean. And this is another thing you mentioned. Offloading is also nice because it limits your need to perform compaction. Compaction is destructive. If you summarize your chat history, you lose stuff. So just offload it instead. Make it searchable. And I think those are some of the key principles that are pretty interesting.
Lance Martin
What? I mean... do we have AGA at home today? Or what are the limits? Like this pattern that you just laid out, let's take a state-of-the-art model of your choice. What can it not do? What have you found that it can't do yet?
Jeff Huber
So this is a really good segue into the last big category I think is very much an emerging frontier and is indeed not at all solved is what I might call evolving context. So Dwark has written a lot about this continual learning. It's obviously a major theme. You know, Letta AI, they've done a lot of nice work on agents and memory. They put out a nice blog post talking about continual learning and token space. So often we talk about continual learning, we're talking about actually updating model weights. You can also do continual learning in token space. And that is something like you have context stored externally, for example, in a file system to the agent that is evolved over time based upon things. This could be based upon the needs of a task. It could be based upon memories and preferences. It could be based upon skills. And so... i think this is an area that's super interesting and there's a few kind of cool emerging threads so like omar uh the dspi folks have done a ton of interesting work here so i think you can break this evolving context continue learning thing down into a few categories there can be evolving like tasks specific context or prompts so i think um the jepa paper from omar is really interesting on this point where basically it's like let agents do things, reflect over the trajectories, and trajectories plus scores, use some evaluation criteria for a given task, reflect over trajectories, then propose task specific prompt updates. And you have kind of a population of prompts and you continue testing and they have some interesting tricks there. But the key insight is, evolving task specific context, specifically task specific prompts over time. Right. By reflection. Right. So that's like kind of one thread of this evolving context thing. Another thread is I've done some early experiments. I called this cloud diary. I put it out on Twitter, but basically, um, So all your cloud code sessions are stored locally, actually. You can access them. There's these JSON files saved into like the .cloud folder. You can access them. And I built a little simple thing where I actually just kind of either within my cloud session or I can pull in the histories. I basically write like a summarized diary entry for each one. And I then later... asynchronously perform a reflection over my dire entries and then update CloudMD. It's a simple reflection loop where basically you're saying, okay, look at what I did, reflect on it and update my, my, my prompt, my system prompt, which is capturing CloudMD. And so, and, and specifically I'm trying to capture things like memories, preferences, get preferences, like, and I wrote a little blog post on this and it's been really useful. So like it's captured things like PR review is a good one. So like you get a bunch of comments in PR review and like those, you kind of, you address those with Claude in your given, you know, in your, in a given session. But then I have a little, I have a little plugin for this, but basically at the end of the session, you can say, create a diary entry from the session. It captures all those preferences and all those learnings. Right. Reflect on it and then update ClaudeMD over time at a later point in time. Yep. So that's another kind of notion of this context evolution can do a learning.
Lance Martin
Yep.
Jeff Huber
Which is super crude. You know, this is just like me creating some custom man's QR code. It's really crude, but it's like an interesting idea. Yeah. And there's a bunch of papers on this, by the way. Of course. You know, right. And then the third is skill learning. So lead is a good paper on this, but it's very similar. Yeah. Reflect over agent trajectories. If you see like an SOP, like a standard operating procedure, something that could be captured as a skill. Yep. Save it as a skill, write to the file system. Yep. Same idea. Yep. So I think those are three specific ways you can think about like evolving context. Yep. that are pretty interesting. And this seems to be a very much an emerging area. Like these are like, at least what I did is like super hacky. And I've also done, I did some skill learning stuff. I test that with deep agents. And again, it was just kind of like me writing some like custom prompts to, hey, reflect over these, reflect over this particular like trace. And if there's something that seems like a common pattern captures a skill and save it to the file system. Yep. So this is a big area. And obviously, there's a lot of talk about continual learning.
Lance Martin
Do you think that, I guess, where do you think that there's continual learning, quote, in token space? We just call it continual learning in skill.md files. Yeah, yeah, yeah. Exactly. And it sounds less fancy, but it is up there. And then there's also continual learning in the model weight. In the model weight. Obviously. uh, you know, continual learning and the skill that MD feels like easier to, I mean, people talk about memory for a long time, right? That's right. And stuff and like, you know, because like, where do we expect that to stop working and where will we need to start layering on that? Plus the model weights can some sort of continual learning story that the model weights as well.
Jeff Huber
Yeah, I mean, some of these discussions are a little bit outside my area of kind of what I've worked on, like tangibly. I think the take often for performing iteration in quote unquote token space, and that is like basically trying to evolve prompts, trying to evolve things like skills, trying to evolve things like memories, all external to the model, just living in context is like, it's pretty easy to do. You don't need to retrain. But it's crude right now. So it's like I'm writing custom like skill or I'm writing like custom commands for cloud code that perform reflection over like my session histories. But the nice thing is it's easily hackable. Whereas updates in... weights require some kind of retraining. And then there's, there's a bunch of ideas here. Like, like Laura was like big for a while. I think it's still obviously still big. But these are much harder for individuals to like test out, right? Like the ability to do things in token in token space is like super easy to test and hack.
Lance Martin
It's legible to the human, right? It's interpretable. It's also interpretable. You can edit it if you want to.
Jeff Huber
So this is actually, this is actually a very good point. It indeed is. It's, it's, it's human. It's human interpretable. And actually, you know, it's funny. I will occasionally go into my CloudMD and like edit it manually and like drop the update. If I don't like the rules that like the agent saved from this reflection loop, I'll just edit it, modify it. Whereas if it's in weights, it's not editable. It's not visible. So I think those are a lot of reasons why it's actually pretty interesting thing about context evolution, but external to the model and these living in, you know, these living in, for example, the file system. An interesting point, though, that this all leads to is, and I know you've commented on this a little bit, this RLM idea, recursive language models. I was hoping you'd talk about that. Yeah, yeah, yeah. We should get in this a little bit. So currently, a lot of these context management manipulation techniques, and we can go all the way back. We could talk about, go back to offloading. Offloading is like some heuristic I'm prompting it to the agent to say, okay, offload two results after like... according to this criteria, like after they're like this many turns old, just save them the file system, uh, apply compaction following some particular rules. And that's like prompted into the agents, but only do it at this particular point in time. Um, uh, sub agents often are like quite brittle, like, okay, spawn sub agents for these types of tasks. Like, um, um, And then all this context evolution is also very like, at least for me, yes, I'm like creating some custom commands, for example, for cloud code to instruct it, how to reflect over my prior sessions and like what to save in these dire entries. And when I do a reflection to update my cloud MD, I'm prompting very specifically. how to determine what to save. So anyway, if you look across all these prompt management techniques, it's a lot of hand-tuned prompting by the user or by the agent designer to govern this context management process. The RLM thing, which is pretty cool from Omar, Alex, and a few other folks now at MIT, and actually Prime Intellect has done a lot of this as well, Will Brown and others. And so this is pretty neat. you can indeed train models to manage their own context. And I know this link you're really interested in. That is a really interesting thread. I actually think... memory management is a great area for that. Because if you believe in this idea of memory management and token space and like, which I think is not a bad idea. So like you're working, interacting with the agent over time, you're accumulating very large numbers of sessions. You want some process to remember things from those sessions for the agent to learn, for the agent to like retain preferences, like all the stuff we're talking about. Um, managing that is like quite unwieldy and seems to be something that would be quite good for a model to learn to do. Yeah. And so I think, I think for all the things we talked about, for like offloading, and actually the RLM stuff talked about subagent spawning as one of the things that they are training the RLMs to do. Yes. So that's a great area for like this idea of like learn context management. Yep. Rules are sub-agent spawning. That's a great one. Rules for context offloading is a great one. But I think a really, really good one, maybe even more interesting is this context evolution or kind of memory management because it's going to be really meaty. There's lots of memories. There is, you know, many, potentially many different prompts or different tasks. There's lots of skills. Managing all this and refining them over time based on experience is going to be a huge thing.
Lance Martin
Yeah. I mean, it's interesting, right? Like both everybody has this intuition that like, I think we want to be able to, uh, iteratively instruct models or agentic systems that you want to use agents like, and also have them iteratively learn from their environment, both as a humanist in some sense, a part of their environment. Right. Um, and, uh, you know, yet today, like the most widely used memory system probably is like chat GPT memory. That's right. That's right. And most people don't love it. And so I guess it's interesting to try to ask the question, how hard is this problem? It certainly can't be easy, presumably. It intuitively feels like it could or should be. Yeah. oh, yeah, like, okay, whenever you're interacting with the world, with the environment, with the user, pay attention to the trail of logs, you know, break off stuff that you think should be important, store it somewhere, get it later. Okay, it just, like, should work. It's, like, kind of some, like, intelligence on the log, processing it, plus some search. Great. But it doesn't seem to be that easy. I guess, like, do you have an intuition for, like, why it's not that easy?
Jeff Huber
Yeah, this is actually a really good one. So, you know, there's, like, two sides of it. There is the... there is the like saving of context. So like saving or updating of context. And so that's like kind of the writing side of it. What to like, you know, a classic one in my little explorations here, like I'm reflecting over end sessions. What actually constitutes something that's worth saving? kind of tricky, very user specific. Like what preferences are actually like general that I want to say to my global cloud MD and what's like specific to this given session? Pretty tricky, kind of nuance, very user specific. So that's like problem one. Right. You can imagine I'm allergic to shellfish. Yes.
Lance Martin
Well, I'm not, but like hypothetically I was. That should be like a long running memory. That is a long running memory relevant across all sessions. I'm going through a Greek food phase, you know, like that's, maybe I'll get tired of it, you know, like, how do you know? What is the time window on these things? Exactly. And this obviously applies to actual real kind of like knowledge workflows as well, right?
Jeff Huber
That's exactly. So you're exactly right. And that's like the writing side of memories is tricky in that sense. And when I say memories, you know, it could be skills. It could be literally like preferences and memories. Exactly. It could be like prompt, you know, new prompts I want to save or something. It's all English. though. It's all English. It's all natural language. So it's like the right phase. And then there's, and then there's the read phase or the retrieval phase. Right. So I'll tell you something funny. So Simon Willison, uh, had a good talk at this year's AI engineer. You might've seen it. It was like one of the keynotes. And basically he talked about, he gave the example of cloud code or sorry, of, um, of chat GPT memories. And he was asking chat GPT to create an image of like a penguin for something. You know, he, he does a lot of stuff with penguins, right? He loves them. He loves, he loves penguins. Yeah. But it was interesting. So ChatGPT injected a sign in the image that said Half Moon Bay. He said, well, wait, where'd that come from? He happens to live in Half Moon Bay. It was the case, apparently, that ChatGPT retrieved a memory related to location and inserted it into the image. Right. Just like for whatever reason. Right. Doesn't know why. It's a case of erroneous memory retrieval that was not relevant to that given task. And it was like something he didn't want specifically. Right. And it's a good example of retrieval is also hard. So when to fetch certain memories and why and what context. So like writing's hard and retrieval's hard. I think those two things make it tricky to do this. And I think that's why it hasn't quite been cracked. That's one of the many reasons why it hasn't been cracked. But even I think in the RLM paradigm, if you can imagine training models to be really effective at this, So preferences, evolving context is always very user specific. It's like my personal workflow preferences typically, for example, in the case of memories. And that's something that like there always will need to be some kind of user supplied instructions, which is actually kind of fine. You could still have an LLM be extremely effective at memory management, but still like fetching from, for example, a user preferences file that's provided that like gives some additional rules. That's totally fine. So it's not incompatible, but I think it's just a note that whereas like sub-agent delegation, that part of context engineering feels like that could be pretty just kind of like baked into the model and like without much user. You could certainly have user-supplied sub-agents, and that's totally fine, but kind of the taste for when to spawn sub-agents, when not to, you can imagine that living in the model. But for something like context evolution feels trickier because it's so personal oftentimes. Yeah. The memory management kind of, like, mechanisms could be learned and very effective, but, like, there's always going to need to be some very acute user-provided instructions is my sense. Yeah. Which is totally fine.
Lance Martin
Yeah, maybe the intuition is, like, could you build a classifier for a given thing? Right. Like... And if you can build a classifier, then you should expect that that will be folded back into the model itself. Yeah. And then if you can't build a classifier that really ends up being more like, you know, some level of like business logic you need to bring to the model. So like, for example, like, you know, maybe something like remember allergies. Yes. Like that is broad enough, you know. Yeah. Sacramento is the capital of California. Yeah. The model will just learn that. Just learn that. Exactly. But for your app about food ordering. Yes. Right. Like remembering other more nuanced things. Yeah. Like that kind of classifier won't be, I think, trained directly into the models. But like when a task is a good candidate to call a subagent. Right. okay, this is kind of a research task. This is kind of paralyzable. Exactly. This task has a chance of like using a lot of tools or generating a lot of sort of data exhaust that I would want to keep from my main contacts. Right. That feels like that could, you could imagine developing a classifier, which is cross domain. That's right. And therefore, like, you maybe should assume that, well, then if you can train a classifier, by definition, it is RL-able. Yes. And by definition, the labs will RL it, which means that it will, you know, show up in like the next generation of models, basically.
Jeff Huber
Yeah, that's a good heuristic. Right. Like, you know, is this something that's like verifiable such that you could like define a classification task for it and like train a classifier on it, then it's well set up first line for it to be absorbed in the model. You're right. And for things that don't fall into that bucket indeed are probably not gonna get absorbed into like this kind of what you might imagine to be what we call the RLM layer, this new kind of RLM idea. It's like any learned context management. But look, a lot of things we're talking about, I think like offloading, this could be, this seems like something that will be absorbed into models, like kind of clear rules for offloading context instead of some like hand-tuned heuristic, like, okay, offload two results after like N turns. This is something that like a model can clearly learn to do. Yes.
Lance Martin
All the parameters will be learned.
Jeff Huber
Correct. Sub-agent delegation is a good one. Caching is a good one. And that's kind of already something that you can just like kind of turn on. And I think this context evolution bucket or continual learning bucket will be like, will be a really interesting area to think about and a little bit trickier because the rules are often trickier and very human, very user specific, I would say. Right, right, right. Yeah. But for example, I know you've been on this quite a bit. Yeah. how to best index and store, make memory searchable. That's something that an agent could be increasingly very, very good at, like a memory retrieval. And so some of the mechanics, I think, can get absorbed into the models. But there's always going to need to be, my sense is, a lot of user preferences overlaid on usage of some general memory management tools. Maybe that's the way to think about it.
Lance Martin
Yeah. Going back to file systems, it's been in the news. I think I've not been keeping track, but if I was keeping a tally here, probably approaching 30 times in this conversation. I guess, what is the intuition for... There's a lot of different ways to store and retrieve data. Yes. a file system is one very specific kind of way of doing that. So I guess, like, what is your intuition around, like, why has that taken off? What is your intuition around, like, how lindy or durable that will be? Yeah, yeah. What do you see as some of the downsides or some of the current shortcomings of file systems, I guess, as well?
Jeff Huber
Yeah, yeah. This is a good one. Okay, so, you know... Yeah. So Claude Code, Manus are two of the more popular agents of the past year. Both of them use a file system. If you think about the tasks, so Manus is kind of a general purpose agent for like consumer tasks, like do research on a thing. a lot of those types of tasks are doable without a huge amount of context i.e a file system is an easy and sufficient way to save like results from from like using web search tool just offload them yep so like a very nice useful primitive like a consumer focused agent that's handling like discrete like consumer centric tasks like research or slides something like that okay Cloud Code, of course, was a coding agent. Coding agents typically work in repos. If you plot distribution of repo sizes, a lot of them are kind of smaller. Actually, I just made that up. I have no idea. It's probably paraded. Probably kind of roughly true. So a lot of repos are relatively small, and relatively small repos, like you can get away with just like globbing, grubbing around. And this one we could debate. Sure. But I'm actually going to kind of segue into why I think your world is very interesting here. But I think for that reason, file system is a really nice primitive for code agents and for general purpose agents like Manus. In the case of code agents, because repos can often be smaller, and cloud code is very, very effective just with its simple Unix utils in small repos. Now, I saw recently... I think Boris actually commented on this literally in the last two or three days. Larger repos, it starts to fall apart. This is kind of the classic. So larger code bases, you can't quite just get away as easily with simple like log graph. The search space is larger. The search space is larger. Yeah. So Cursor came out with a nice piece talking about, hey, they use semantic search and they had some nice results on that. Boris recently mentioned that someone had to be experimenting with larger repos and like, okay, they did like SQLite indexing of the code base and like roll that into a custom command for cloud code. So look, it's completely compatible with this idea of indexing and search is, of course, relevant when the search base grows and that's relevant for larger repos. And that's still completely compatible with a code agent like Cloud Code. It's just like a search tool. It's totally fine.
Lance Martin
So one gap that you're elucidating here is that file systems... So I think file systems have become the data store du jour for a few reasons. Number one, because there's a lot of training data about how to do things on file systems. Correct. That's right. It's also trivially easy to generate a lot more training data. That's right. Yes. Coding agents are able to use the, you know, use command line to fix commands. That's right. That also enables a lot of, like, creativity and, like, combining lots of tools together. Bash is highly composable. You know, head this, pipe this, you know, kind of brings it all together. It is in some ways a multi-tool, right? It's not a single tool. It is a multi-tool.
Jeff Huber
And there's a whole thread on this bash is all you need. The bash tool is kind of the one tool you need. And yeah, it's highly composable, very easy way to do lots of stuff. And the models are extremely good at using it. You're exactly right.
Lance Martin
Yeah. And then there's, okay, so what are the limitations, at least as we think they may exist today? This is all I understand hypothetical. So one is that like, maybe if like expressive and powerful search is important for either pass rate and or speed and cost or all of the above, then like, you know, you can imagine accessory systems of some kind that make that better. Definitely. And a price search. Obviously, I think that I think about. What are other, not to put you on the spot, like what are other sort of like, here's one thing I'll bring up as like not a concern, but an open question. Yeah. Is like multiplayer mode. how are many agents and or many humans, many agents going to collaborate on the same pool of data? Presumably getting, you know, pushing and pulling from GitHub branches. I don't know. Yeah. Maybe going to work, but like it's not truly collaborative in that in that sense. Yeah. I'm thousands have this like last right wins, you know, sort of semantics. Right. So if you It's sort of you and I are editing the same file. We both have it open. I save, then you save. You would never know that I did anything, right? Because you did it. You stopped me. So I guess that's one thing I've been thinking about is a limitation of file systems. Obviously, if you're single agent mode, you don't care. But as we move towards this theoretical future of thousands of agents collaborating together to solve a problem at the same time, yeah.
Jeff Huber
So this is a really good one. You know, it's funny. I was thinking about like big topics for the following year. I think like continual learning in like token space or generally continual learning, you know, in weights is one big bucket. Another big bucket I think is multi-agent collaboration. It's exactly what you said. So, like, the patterns from multi-agents we've seen to date have been a little bit more like MapReduce. A bunch of parallel agents just doing independent things, then you pull it all together at the end. That's one pattern. Or this, like, Ralph Wiggum serial agent thing. Like, one agent takes a task, does the loop, saves it all, commits it all, second agent looks at the Git history and does the next thing, okay? So you have serial, you have parallelized. But, like, what about concurrency? So like Steve Yegi has this like Gastown thing. Have you seen it? It's kind of cool.
Lance Martin
I was only able to make it through about half of it. Yeah, yeah, yeah. My eyes are rolling back in my head. No offense, Steve. Yeah, yeah, yeah. It's a long piece.
Jeff Huber
And I actually haven't. It's a whole world view. It's a whole world view. It's a whole world view. But, you know, centrally it's about managing like, you know, N cloud codes as an example agent, like doing stuff concurrently. And so. Yeah. I think this is a really big area. I think it's multi-agent communication for concurrent tasks is like indeed not solved. I think Cognition had a good piece on this where they talked about like you know, individual sub-agents are making implicit decisions. They can easily conflict. How do you resolve conflicts? Then you get into like, well, okay, Git is one way to do that. It's what we use as humans. It can get very messy though. If you have 30 cloud codes working simultaneously on the same set of files, like there's a lot of opportunities for conflicting decisions. There is then maybe, I'm sure it is indeed doable. There could of course be mechanisms where you use Git and you use like merge conflict resolution to, you know, adjudicate all these things, but it's complicated. And so I think that's a really big area. My guess could be file systems plus like Git is used by humans. Agents may indeed use that same mechanism. That is one way it could be done. So file systems could still play reasonably well in this world. And like, look, if you're working with a common set of files, that's totally fine. They can live within this file system. And then agents can kind of be simultaneously operating on them in some way. I think how that's all done is like a really big area for 2026. Yeah. But I think that going back a little bit, I think what we're seeing is though in domains where you have large search spaces, you know, like enterprise knowledge databases or like large code bases, like look, like we are not just using a bunch of files in the file system necessarily. where specialized search tools are still very important and relevant. And it's interesting. I thought that point about, yeah, you can always load them as a command. You can add it many different ways. You can add it as a tool. You could add it to the tool calling layer we talked about. You could add it as a CLI that can be hit. It's fine. It's totally fine. Totally compatible with existing code agents that... Yeah, like a cloud code or any of those that use a file system as a primitive, they can still use more advanced kind of search tools that have used indexes that live, for example, on the file system somewhere, but are not just using the file system natively as a mechanism for storage. Yep, yep.
Lance Martin
Yeah, I think like I've been continually attempting to apply like the idea of a memory hierarchy. Right. You know, kind of like a normal classic computer. Right. Like to the language model regime. And my most like recent articulation of this is that there's just sort of these like layers of context.
Jeff Huber
Yeah.
Lance Martin
And the goal is to materialize a view across those layers of context in a just in time fashion that enables the agent to do, you know, the very best next action.
Jeff Huber
Yeah, right.
Lance Martin
And so there's like session context going on during that active agent session. That's right. There's like agent context, which is multisession. So I think, you know, skills, for example, is a good example of this.
Jeff Huber
That's like the agents, historical sessions, skills, memories, you're saying.
Lance Martin
Yeah, maybe it's agent friends also. You know, what can I learn from my agent friend? Other agents, okay. Yeah. You know, sort of slight different types. There's then like organizational context, which is like, okay, maybe for the agents to do the best job, they do need to know like what's going on inside of Slack or, you know, other data stores, right? Yes. Email. Right. Calendars. Right. There's way too many context graph things x.com diatribe now i saw you commented on that like i will i'm going to continue to a moratorium on them beat the drum that's great there's too many i just it's it's just a bit um well i saw that one early i think from j jaya gupta yeah yes That was, listen, it's good to see the idea. Good to see the idea. But now all the remixes. The end remixes. Clearly the AI slop remixes. The slop me guys are hitting.
Jeff Huber
The remixes are hitting. Please stop.
Lance Martin
Yeah, yeah, yeah. Anyways, so that's the third layer. Organizational context. Second session, agent, organization. And then lastly, global context. Web search would be a good example of this. What is other information outside of the walls of my organization that might be relevant to accomplishing what I'm going to do right now?
Jeff Huber
Right. So that, okay, that's interesting. So you can kind of, you can, there's two different ways to look at it. There's kind of, there is the action space of the agent. So the agent can use, it can use tools. It can use, you know, bash utilities on its computer. It can use, it can use code to do stuff. And then there is the types of contexts it needs to access. So that is like its own session history. Uh, it is like you were saying, like it's past sessions, uh, which indeed maybe live in the file system. Session history might also live in the file system. Uh, it is other agents doing things at this time. Maybe that lives, I don't know where exactly that lives. Yep. Um, skills live in the file system. Then you're saying there's organizational context and that lives like kind of more in like, knowledge bases and other things which are probably accessed via the it could be actually the tool calling layer could be accessed as like clis if you have like a cli for like whatever database yep okay so that's fine and then there's global context and that's typically is access that could be easily accessed like um through clis as like for different search tools for example yeah web search web search or whatnot so okay that makes sense as like the the context categories And then the mechanisms for retrieving it, again, just fall back to our old action space of there's tools and there's the computer, which has CLIs that are available and any other utils you give it that it can just write scripts for. Does that make sense? Yeah. Okay. Yeah.
Lance Martin
I mean, I will log my bias here, which is I think that everybody's asking for file systems, but I think everybody wants a database. You want many writers. It's like, how do we... The earliest computing in the 70s, 1670s, what did they have? They had file systems. Like, databases were invented for a reason. For a reason. They were invented to solve problems like multiple writers and multiple readers and, you know, resource contention and scaling and, like, some level of schemas and, like, there's a reason these things exist. And so, like, I guess my, like, my hot take is that the file system is a bit of a fad. It is a way to give, what are the benefits of file systems? Like, number one, it's easy to put into the training data, and so that means that agents become good at it. Yeah, yeah, yeah. I think that, like, databases will be, exposed as file systems and sort of obviate the need for that. Plus I think also agents just over time will just get better at using tools that they're given. And like they won't be as reliant on like kind of what was represented in the training data sort of directly or specifically. They'll get more like metacognition skills basically. And then number two, yeah, the file system stuff. No, I'm blanking on the file, number two now. Yeah, I just think it's like a bit of a, it's a good meme. I like it. I just think it's like, is it durable? Is it linear? Are we going to be using literal file systems 10 years from now?
Jeff Huber
Yeah, yeah, yeah.
Lance Martin
Like I kind of doubt it.
Jeff Huber
Yeah, so there's maybe a bit of a nuance here that's interesting. So there is file system as a primitive that the agent uses to get stuff done. Yeah. Which means a file system is just like a place where agents storing its skills. It's storing like, um, it's where it can offload stuff that it's doing over the course of the session. Right. Um, Versus file system as the place where the context that much of the novel context that the agents will need, like that category you laid out, will live. And my sense is file systems are nice as an agent primitive, like for offloading. Just take that example. Sure. Like an agent is doing stuff and just give it a file system that can just save stuff there. That's totally fine. Yep. Versus... Versus do I need a file system to like dump literally all the context the agent will need to perform tasks into the file system so it can just read those files. That might not be Lindy because that is like maybe overfitting to the coding use case where agents are operating in repos that happen to have all the context agent needs to do stuff in the file system, i.e. in this repo. So it's like mixing up two ideas. One idea is like the file system is primitive, which is kind of a nice thing for agent to have. Gilder Files is looking at offload stuff. It can save its skills. That's totally fine. That's cool. Versus like... like the stuff you want the agent to use to get stuff done, that's like, that can live in like, you know, that can live like behind APIs. It could be knowledge, it could be like, you know, enterprise knowledge bases. It could be like, you know, it could be using like search tools. That stuff does not need to live in the file system. And the one interesting crossover here is I think memories, which is, you know, something that the agent, it's like specific to the agent. It's like part of the agent's kind of like, you know, internals, so to speak. that's something that like, I think there is maybe a bias, like just save it all the file system. And I think that's a place where like, Oh, actually like just using retrieval for that in particular might be indeed quite useful because it's going to be a large search space. Um, so anyway, that, if that makes sense, I'm literally just thinking out on the fly, but it's like, Separating out the file system as just like another primitive for the agent that like helps it get tasks done. Versus literally like, I need to save all my context of the file system so the agent can use this grep tool or glob tool to read it. Like that's like kind of a wrong, overfitting to the coding use case. Know what I mean?
Lance Martin
Yeah, it could be, yeah. I think we should register this bet. There's no clear sides here. That doesn't matter. But we should register this claim or thesis and revisit it in maybe two years. We're clearly not at peak file system. So I think it will become much larger before it becomes smaller.
Jeff Huber
Well, and just to wrap that up, I do think there's kind of this point, like, listen, these agents are using dual-use tools. They're using the tools that we use. And, like, we use file systems, so why shouldn't agents? And so, like, to the extent that we use file systems, agents may use file systems. But, like, you know, listen, I use web search, and that does not live in my personal file system. So maybe there's just some, like, you know, listen, agents kind of converge on using tools in the same way we do. Yeah, that is interesting. And, like, where do we use file systems and where do we not? Agents will probably reflect that, you would think. Right.
Lance Martin
Yeah, there was, I guess, a move where like all document authoring was on local file systems. Yeah. So it's a facto you're saving these like, you know, Microsoft Word files like to your local file system. Yeah, yeah, yeah. And then like, okay, well, we actually want collaboration. Yeah, really nice to have real time collaboration. So I can move to the cloud, you know? And so like, yeah, I still keep my like to do list. Yeah. As like a sublime window on my desktop. Yeah. Because that's not a collaborative document. Yeah, really. But almost everything else I do in a team context ends up finding its way. Yeah. Like some sort of, you know, you know, Google or notion. Yeah. So it's interesting.
Jeff Huber
You know, another interesting thing along these lines, it's tangentially related is, is, you know, listen, if we are going to say a sandbox is an important agent primitive, then we could debate that. But like, it's, it's both, you know, like a runtime, it's like a shell as well as like a file system, like sandboxing becomes a very important, like dependency for agents. And we're already seeing that, right? Like, um, you know, obviously there's a lot of companies that are doing this, but like that becomes kind of a thing. And like, oh, if I'm an enterprise, I want to like, you know, deploy agents. You need to think about sandboxing now.
Lance Martin
I think sandbox is like a full fat VM, in my mind, is the question. That's the current method today that we're sort of taking. Either it's Firecracker, maybe you're using VN isolates, but it's still its own thing. I don't know how. I think that's more of a short term than a long term stable thing. Just because like, again, at certain levels of speed is scaling costs like you kind of don't want to have like owned resources. You want to have shared resources. We move from, you know, punch card computing to time sharing, right? Like for computing, because like it was useful to be able to share resources. But yeah. Yeah. Um, okay. What do you, let's say to kind of wrap things up here, like, uh, or attempt to like lots of open, fun conversations. Like what thing are you most excited about right now? And it's kind of, you know, let's say over the horizon of like the next, like, you know, a couple months on like kind of this like harness conversation and file some conversation. Yeah. Yeah.
Jeff Huber
I think what I'm most interested in is, and not to rehash it too much, but I think the topic of memory is obviously extremely important. And natural learning and assimilation of preferences and personal knowledge. That seems to be a major frontier. It's usually important. I play with it quite a bit. And without it, agents are just really brittle across tasks. And I see this all the time. So I think that's like one category. Another category is we talk about multi-agent collaboration. That's a good one, but I don't want to belabor that because it's obvious. We need to get better at that. And I also don't have that many views on it, like how to do it. So anyway, I'm going to table that one. I'll come back. We talk more about that later. Great. Um, I'll say something kind of like, uh, you know, a little bit, yeah, another one that's like kind of well trodden, but like, listen, using, um, using general purpose agents for mundane life management, um, And there's a lot of talk about this. I spend a lot of time trying to build different personal assistant agents. And look, we talked about this previously. You have three kids. I have two kids. Life is busy. I actually want to run my life. And I always have conflicts with my wife about tasks and life management. I want to run more of that personal stuff out of AI systems and have AI systems help me to do things. And that means specifically they need to be able to access... amazon and other systems and like track things over time so it brings in memory it brings in learning yeah but like you know agents for more than just like coding so like i've also been using coding agents very extensively last year i've been using agents quite a bit for research i use them a lot for writing so i do a lot of writing with agents but like more personal management so that's like not super novel and observation but it's actually something that like Like, I think Peter Steinberger has this new, like, Claude, C-L-A-W-D. That's, like, kind of a, like a, you know, a personal management thing. And Anthropic just launched Claude Cowork. Yep. Like, listen, there's a lot of interest on agents for, like, just general purpose life and knowledge management, not just, like, coding. And that's going to be a big thing. And I'm actually personally interested to use that more to, like, manage my life. Yep. Which is practical for someone like you or I with kids and family and just a lot going on.
Lance Martin
Totally, yeah. Yeah, the age of personal software is so exciting. It is. Obviously, there's both some level of packaging that can be delivered, but also just like... I mean, it is so easy now to just build cool stuff. Like I built a personal Raycast replacement. I built like a basically personal like coding harness. I built a personal like local like agent kind of ID type thing. Yeah, absolutely. Like it's just like, I mean, it's a new era.
Jeff Huber
You know, I'll throw another out there. And actually this was a bit inspired over break. Toby from, from Shopify had talked about using cloud code to do some stuff with like medical data. I think like MRI or something like that. And I think, I think medical is a great domain. So actually I am a past life. I did a PhD in comp bio. It was computational bias. I have a bit of a background there. I think it's really interesting. Yeah. I do some like personal health stuff, just like, you know, like biohacking only a little bit, but like, I think this is a great area. uh for you know ai systems to help and it's something i'm tracking very closely totally um so bioscience is another really really good one that i'm i'm very interested in
Lance Martin
I think that's an excellent place to wrap. For AI to be really, really durable, it has to find its way into actually being very helpful to the mass populace. That's right. And so I think the pieces are in place now. We're going to see that happen in the next 12 months.
Jeff Huber
Yeah. Hey, it was a lot of fun. Dude. Absolutely. So great. Yeah, it was great. Thanks for coming by. Good to meet you in person finally. Likewise. All right.
