CEOInterviews.AI
Start App
Harrison Chase
Co-founder & CEO, LangChain

LangChain CEO Harrison Chase on the infrastructure bet he got wrong

📅 Sep 15, 2026 Browserbase 51 MIN 12665 VIEWS 80 SEGMENTS · 2 SPEAKERS
Chase (Co-Founder & CEO of LangChain) has rebuilt his product stack four times since 2022, chasing models that kept changing underneath him. In this episode of Navigators, Paul sits down with him to talk about what LangChain got right, and the one piece of infrastructure it built years too late. Harrison admits the team underestimated how massive the demand for raw inference would become, and how big general-purpose coding agents would get. He walks through the shift from LangChain to LangGraph to DeepAgents, why sub-agents rarely work the way people expect, and why LangChain now runs its own...

What Harrison Chase said

Written from the verified transcript and checked against it. Every figure links to the moment it was said.

Harrison Chase, CEO of LangChain, discussed the evolution of the company from an open-source side project in October 2022 to a commercial platform. He admitted building a gateway too late, underestimating demand for inference, and the market size of coding agents. Chase detailed the progression from LangChain to LangGraph in 2024, emphasizing low-level control, and the 2025 rearchitecture with Deep Agents. He noted the shift from custom cognitive architectures to more agentic harnesses, with customization via skills, tools, and middleware. Chase discussed the importance of observability and eval, and the growing interest in post-training models, though mostly for simpler tasks. He highlighted the need for governed runtimes, sandboxes, and auth gateways, and introduced Managed Deep Agents. He also shared his skepticism about candidates overly focused on using agents, and his frustration with AI slop.

Key takeaways

  1. LangChain built a gateway too late, underestimating demand for inference and coding agents.
  2. LangGraph launched in 2024 for low-level control, rearchitected LangChain on top of it in 2025.
  3. Managed Deep Agents binds harness with infrastructure for easier production deployment.
  4. Chase views candidates focused on using agents as a negative signal, emphasizing outcomes over tools.

Numbers and commitments

FigureWhat it refers toTypeAt
October 2022 LangChain launch date timeline 5:23
January or February of 2023 Company start date timeline 5:23
summer of 2023 LangSmith GA launch timeline 5:23
early 2024 LangGraph launch timeline 6:25
2025 Year of stabilization and rearchitecture timeline 6:25
360 people LangChain team size metric 45:43
50% Tasks where quality is good enough metric 34:42

Chapters

  1. 0:00Early LangChain origins
  2. 3:22Open source community changes
  3. 5:23Product evolution and timeline
  4. 9:11Gateway built too late
  5. 13:11Agent harnesses and domains
  6. 19:40Sandbox architecture and customers
  7. 29:28Post-training and model customization
  8. 33:35Quality, cost, and speed trade-offs
  9. 45:52AI slop and internal agent use
  10. 50:17Future runtime and Managed Deep Agents

Questions asked in this interview

12
  1. 0:25If you look back now at starting LangChain, would you do anything different?
  2. 0:30How similar do you think kind of like coding agent harnesses are to like a good harness for browsing the web?
  3. 3:02Hey, can you merge this thing?
  4. 8:52Would you do anything different or do you think it was the right order?
  5. 13:29I'm curious, how have you thought about the different domains of agents and then working backwards to the architecture they actually should have?
  6. 20:10Like how are you shifting the abstraction layer across the two different types of customers you might have?
  7. 30:11Do you see a lot more of them saying frontier? How does it balance?
  8. 33:00How have you seen your customers optimizing these ones?
  9. 37:54How have you thought about that as part of your greater platform or strategy and and what are customers asking for?
  10. 41:00And have you found that in enterprises like everything that you'd want to give agents access to is behind Okta or is behind kind of like this this auth sign up?
  11. 45:45Are do you have agents managing LangChain?
  12. 49:45What are the unsolved problems that you want to take on next that I can check in on next time I do this podcast?
Harrison Chase 0:00 ↗
I actually think when I'm talking to candidates and all they can talk about is using agents to run and do their job, I actually think that's a bit of a negative signal.
Paul Klein 0:06 ↗
Why is that?
Harrison Chase 0:07 ↗
I think there's things that agents are good at and there's things that they're bad at. And I think the focus on tools more than outcomes is not a good thing. My general philosophy has been like build up kind of like a team or a process or an ethos of just iterating super rapidly rather than like being super dogmatic and sticking to like yeah this is kind of like the way it has to be done.
Paul Klein 0:25 ↗
If you look back now at starting LangChain, would you do anything different?
Harrison Chase 0:28 ↗
I think we built a gateway way too late.
Paul Klein 0:30 ↗
How similar do you think kind of like coding agent harnesses are to like a good harness for browsing the web?
Harrison Chase 0:35 ↗
What I have found is that code creates, you know, memory or creates skills that can be referenced in future agents and for browsing tasks which are highly repeatable. That's really beneficial.
Paul Klein 0:46 ↗
What are some of the second order effects that you've seen from like LangChain or agents built on LangChain and like how have you oriented your product around that?
Hey everybody, I'm Paul Klein, founder of Browserbase and we're here on Navigators, our series where we meet with AI leaders navigating the future of what's happening in AI. Today I have on the show Harrison Chase, co-founder and CEO of LangChain. Now LangChain is one of the companies I first used when I was building with AI. It was instrumental to the way that you could build agents before they were called agents, but a lot has changed since then. So I'm excited to talk to Harrison about all this stuff. Harrison, thank you for joining with us.
Harrison Chase 1:24 ↗
Thanks for having me, Paul. Excited to be here.
Paul Klein 1:26 ↗
Tell me more about LangChain, what it was when you started and what it is now.
Harrison Chase 1:30 ↗
Yeah, so LangChain started as a side project. So I was at my previous job, knew I was going to leave, didn't know what I was going to do. And so this was fall of 2022, was going to a bunch of meetups and talking to folks. And as I was talking to folks, saw that this was actually the time around generative AI, specifically the image stuff. So Stable Diffusion had just come out and so everyone was doing stuff with that but there was a few wacky people doing things with LLMs. And so I saw some of the things they were doing and it was like early days of like RAG. I think there was a few very basic like math or computer use things and so saw some common patterns, put that in LangChain which was an open source Python package. Tweeted it out. I still remember Karpathy liked my tweet and that was like a huge victory. Yeah. And then just kind of kept on like not, you know, didn't have any like grand illusions with it or anything. Just was doing it for fun and then kept on building on it and tweeting about it more and a month later ChatGPT comes out and it becomes pretty clear that everyone is going to want to build some AI experience. And a lot of the AI experiences that we were focused on were called agents. And I actually distinctly remember over Thanksgiving break that year we were trying to figure out how to name a class in LangChain and we called it like agent executor and the agent part was right. The executor part was wrong. That was a terrible part. But we, you know, we were thinking of these things like LLMs running in a loop for a while early on. And so yeah, launched that as an open source and then started a company around it a few months after that. So ended up leaving my job and...
Paul Klein 3:02 ↗
We actually met when you had just started that company. Super early, I caught you at a hackathon and I walked up to you because I found a bug in LangChain. I think you had a PR. Hey, can you merge this thing? So the community support around LangChain from the very beginning, it was super viral and it's becoming a little more commonplace but that was like unprecedented amounts of community love around a framework that you built which is a huge accomplishment.
Harrison Chase 3:22 ↗
Yeah I think one of the things that I distinctly did was again like I wasn't intending to start a company around it. I was just using this to explore the space and so I was also using it as a way to just like connect with old co-workers and other people and yeah build with other people. So Sam Whitmore, who I think we both know, who started a startup and now is at Cursor, she was one of the main contributors to early kind of like LangChain and I'd worked with her at Kensho and it was a fun kind of like, you know, reconnection there and so yeah like I think whether it was people that I already knew or the whole community absolutely that was a big part of early things. I look now and I think open source has actually changed a bunch for better or worse because of a few things. One, I think yeah there are these just like massive spikes in popularity of these projects. So AutoGPT is an even better example that came out a few months after LangChain and was like the most popular thing ever and then you see a similar thing with like OpenClaw. And so I do think they're... I wonder if it's because like coding's become easier and so you have more people doing it. I think you see these just like massive spikes in inflections in these projects. But also if you look at a lot of these projects now, I actually don't think the same sense of community is there because you have all these AI generated kind of pull requests or issues that may or may not be good and it's really hard to parse through and I know projects including ours are trying to figure out how to deal with this influx of new AI generated again PRs or issues and so I look back on the early days and I do think things are a little bit different. I do think in projects today there's a little bit less of that sense of community.
Paul Klein 5:01 ↗
Yeah. And so you took that initial framework and it's so hard to build this framework, these technologies for AI because AI was changing so much. So I imagine you started with this thing organically out of the library and the models kept changing underneath you. How did you turn this into a company and how has LangChain the framework changed over time? What do you think about LangChain the company also growing over time?
Harrison Chase 5:23 ↗
Yeah, it's a good question and they've definitely both evolved a lot. So maybe like going kind of like in a timeline view, you know, we launched LangChain October 2022. We started the company in like January or February of 2023. And from that point we were working on our first kind of like commercial solution which is LangSmith, observability and eval for agents. And the thing that we realized that actually has guided basically all of our products since then is that like the hard part of building agents is getting them to do what you want reliably. Like it's the context engineering, the harness engineering, the prompting. Like sometimes they do it, sometimes they don't. What context do they need to have? What tools do they need to have? And the right way to do that has changed over time. But everything that we've built from the frameworks to evalability has really helped with like letting engineers try to make these agents more reliable. So we started building eval observability. So it's not open source. This was kind of like our commercial platform. We launched that GA in summer of 2023.
And then one of the things that happened is as you noted like things were just changing really rapidly. Like early days it felt like a lot of the primitives for building agents were kind of like quicksand underneath our feet, like stuff was just changing and so in early 2024 we launched a second framework called LangGraph and so this I think the trend that we saw was that again to this theme of people wanting more control over the agents that they built, people found LangChain was too high level for people and so they wanted to go lower level and so LangGraph really emphasized like low-level control, like there's no hidden prompts, there's no hidden like cognitive architectures, you have full control over everything and so we did LangGraph 2024, kept on doing observability and eval, and then in kind of like 2025 I think things have kind of like actually stabilized a little bit in terms of how we build agents specifically. I think this idea of an agent from the technical point of view has always really been like just run an LLM in a loop and let it call tools. That was the core idea of AutoGPT, that was the core idea of some of the agents in LangChain. The issue is the models just weren't good enough at that point in time, but then they got good enough. And this really started to happen in early 2025. And so Claude Code is an example of when I think this first started really working. In parallel, we also started to discover basically all the tricks that would go into harnesses. So giving it access to a file system and using that to like write plans and like offload like large tool calls and things like that. Like I think a lot of the primitives that come with coding agents can actually be generalized to other more broad types of agents as well. And so I think in 2025 the ground stopped feeling like quicksand and we were able to start building more on top of each other. And I think that's when we released, that's when we did a big rearchitecture of the open source. So we rearchitected LangChain to be on top of LangGraph. We then built Deep Agents which was an even more opinionated agent harness on top of LangChain. We kept on building LangSmith with observability and eval. And then the last like six months or so, again as these harnesses have become more stable, the infrastructure for a lot of these harnesses has also become more stable. And so we've started to build into LangSmith our commercial platform things like deployments and sandboxes and a gateway and a no-code agent builder which really kind of like bring together the harness and the infrastructure needed to run it. And so that's kind of been the progression over time. Basically initially 100% open source then add on observability eval. And then very recently in the past six months or so more of this like runtime deployment aspect.
Paul Klein 8:52 ↗
Yeah, it all seems so organic and it's the same approach that we've taken at Browserbase starting with, you know, infrastructure for the browsers and like a framework to control it and then like more layers on top. I often ask myself this question. I'm curious what you would think if you look back now at starting LangChain and the progression of products and layers that you've built. Would you do anything different or do you think it was the right order?
Harrison Chase 9:11 ↗
I think there's some things we missed for sure. I think we built a gateway way too late. I remember talking about this as a team a year, year and a half ago. And we just didn't really know like what we could provide that was different on top of like LiteLLM or an OpenRouter. Although I think LiteLLM was really like the main thing at the time. And I think clearly there's one of the things that I've just consistently underestimated is just the demand for just inference that is out there. Like it's massive. The other thing by the way is just how big and general purpose coding agents would be, that market also massive. But yeah I think we should have built kind of like a gateway earlier on. I think that is a core building part. I think that's probably one thing that we did a little too late and we should have done earlier. I'm actually curious for your guys' kind of like journey through things as well because I know because you guys have also kind of like balanced the line of like building a harness for browser agents versus building like the tools, right? Like I think you just did Stagehand v4 which was really focused on the tools and letting people, and correct me if this is off, but like more focused on the tools and letting people build their own harness and I think previously you had your own harness more. I'm curious how you've thought about that.
Paul Klein 10:22 ↗
Yeah, you know it's funny. I think like every company in this space in the infra space for AI we probably nail the primitive like in our categories and then like you try and poke at the edges of the primitive and find out what's right or what's wrong or where we've built too high of an abstraction or too low. So Browserbase like the core browser offering, browser and cloud, pretty much nailed that like that is necessary, there's a lot of challenges with it so that's the core and then we had a framework on top of it, Stagehand, which opened up basically an SDK to control that browser and the early reason we built Stagehand was actually like oh we could just bundle in the prompts similar to how LangChain had bundled prompts to make it easier to translate an action from a user like click this button, click the buy now button on the page to the actual command but as models have gotten better and better. Your prompt abstractions over the actual context which in this case for us is like the web page has become like an unnecessary layer. So we still have that for legacy users who actually really like it who've like added semi-determinism into their code bases. Our more and more advanced customers are like no just give me like the best possible version of the tool to move the mouse to this point like really optimize the tool layer as opposed to offering like layered sub-agents. I think sub-agents as like an idea has proved to be a little more challenging how they're actually implemented. Sub-agents need to own like complete ideologies of a task not like execute a single part of a task. It's very small like we'd have a sub-agent to click that button to save context. So it just the tools and techniques of how to build great agents or agents that can call systems has evolved so much over time and I think as a founder I'm sure you feel the same way. It's hard to pull away from the ideas you had in the past. You have to constantly reset your priors on what makes sense. And that's been something that's always challenged me as we've been building. And as I look towards model capabilities, the bets that I've been making right now have always been like I believe model capabilities will converge on human capabilities. Therefore, like this move to the file system where agents are going to have their own file system, it just actually makes a lot of sense because that's what people will do. And if models are converging on people's capabilities, you probably want to master the people tools because that's what they're trained on. So, it seems like the market has gone full circle from being let's build a completely bespoke thing for AI agents to oh, let's just give them the tools that we already have because they're actually learning on all of those things.
Harrison Chase 12:40 ↗
This is something I actually struggle with a lot because on one hand I agree with what you're saying and I think it's very tempting and very easy to kind of like anthropomorphize these LLMs and be like, "Oh, if I was this LLM, this is what I would want." But they are like just different things and so I don't like what is the right like level to do that at? I genuinely don't know. And to your point, like maybe if you run on a lot of these kind of like tasks that are labeled by humans, it starts to converge to that. But you know, these LLMs are great at things that humans are not great at and we should keep those and we should lean into those as well.
Paul Klein 13:11 ↗
So that's something I'm sort of... I'm actually so... like going off of the file system thing that you said. We were talking about this a little bit earlier, but how similar do you think kind of like coding agent harnesses are to like a good harness for browsing the web? Did you learn things from there? Are there things that you think are just different and need to be added in some form?
Right. Code mode or agents that write code to execute tools are called APIs. I think that's a great counterargument to the, you know, humans. Agents will use tools like humans, right? Because, well, they're just going to execute code. They're more like compilers or operating systems. And that narrative has proved to be really, really good. I think that agents writing code gives a lot of flexibility. But there is like that autonomy slider of like do we trust it to write all this code? Can it write code repeatably? Should it reuse that code? What I have found is that code creates, you know, memory or creates skills that can be referenced in future agents and for browsing tasks which are highly repeatable. That's really beneficial. So agents that write code to control a browser is actually the approach we took in our most recent framework, Stagehand v4, because we're like well agents will call our framework almost more like writing little scripts to do these tasks and you'll compile bigger and bigger scripts over time and that's why our recent framework doesn't have any really models integrated at all. It's all but the tool layer. So code mode seems very relevant for agents doing repetitive tasks. I think a lot of agentic work is repetitive. Like when I talk with enterprises, they actually have like a, you know, a document that says here's all the steps I wanted to do with some fuzzy parts, it's very rare that I see just-in-time agentic use cases these days where the agent is doing something completely brand new. I think trying to bucket all the agents down into one certain type of agent is very challenging. And I've always thought about like domain specific agents like agents that browse the web, agents that do software engineering, agents that do deep research. I'm curious, how have you thought about the different domains of agents and then working backwards to the architecture they actually should have? I think different agents that do different tasks need to have different architectures.
Harrison Chase 15:11 ↗
Yeah, I mean I think this is the core use case that we think about enabling is basically how to help people build agents for their product or for their domain or for their use case. I think the answers have changed a bunch over time and are still changing. So early on when we built LangGraph, the idea was that you'd create a completely custom cognitive architecture for each thing that you do. You'd lay out kind of like how you were saying like there were these processes and there are like these just like yeah different steps or different, you know, sequences of things you want to do and so you'd lay that out in a graph and then there was some fuzzy part and so you'd put that in an LLM call and that could maybe be like a conditional kind of like edge in some of these graphs. And I think that's really good for places where you have more of these kind of like well-known processes and you care about determinism to some extent. And we still see people using LangGraph for that and it's really popular in like financial services and financial industries for that reason. At the same time I think a lot of what people were doing with those things were honestly things that were just more agentic. So, an example of this that we actually did early on was we wrote a deep research example and it was a LangGraph application and it had like first you're going to plan and then you're going to get like these three bullet points and then you're going to fan out and then you're going to fan back in and then you might review your work. And deep research is really just an agentic task. Like I really think it is like there's so many different things you might go down that it's kind of tough to put that into like a graph-like workflow. And so basically we've seen this trend towards more of just like yeah these agent harnesses for doing things like deep research and then the way that you customize it starts to become skills, tools, prompts. We have a concept that we call middleware but that's similar to like hooks in Claude Code or something like that. And you can also add in... I think a lot of customizing it this way is about adding in deterministic things. So like adding in a check like goal mode. Hey, when you think you're done, run another check to like check whether you satisfied the goal. Like that's an explicit deterministic check that you kind of do and then if it fails, it goes back to the start. So this adding some determinism in there. And so great, you can do that with middleware, you can do that with hooks and things like that. And so that's how you kind of start to customize some of these harnesses. And but I do wonder, you know, talking about the difference between different domains like coding for a lot of coding tasks you need a full-on sandbox because you want to install arbitrary dependencies and you want to spin up a server or something like that. We've seen some back and forth when thinking about kind of like document processing. How much of that do you need? Do you need kind of like just access to like a file? So we have a concept in Deep Agents of like a virtual file system where you can just interact with a file system. You can read and write files using the same way that kind of like a coding agent would, but you don't have to spin up a sandbox which is like a heavyish piece of infrastructure. So it's a lot easier. And so we have one customer that early on they were just doing that for their document analysis bit. And I caught up with them the other week and they're like, you know, we actually moved everything into a full-on sandbox because people want to use like PowerPoint CLIs and like yeah, you know, you can't really mock that. You kind of need a full-on sandbox for that. Vercel has their Just Bash thing, which is another thing in this vein where it tries to like mock out the bash file system. Pydantic has Monty, which is kind of like a fake kind of like Python interpreter. And yeah, so I think there... so on one hand, yeah, maybe for some of these other tasks, you don't need the full-blown coding stuff. Maybe you do and you kind of just do want like all these different CLIs installed and that's the way to do it. And so one of the things I'm thinking a lot about right now is like, yeah, what like great skills, MCPs, instructions, middleware, absolutely those are how you customize it. Are there like deeper differences than that? And I don't know the right answer. I think we're still thinking through that.
Paul Klein 19:10 ↗
Yeah, it's so true. And like even like installing a browser on a sandbox, like that's not very sufficient, right? There's so many extra steps you'll have to do to get like the browser working on the web. There's like these web bot auth protocols to allow agents to go places or observability to record the browser session. Like how much of that are you scaffolding into the sandbox itself? How much are you relying on third party providers for? I do think that there is some clear stack and in a way a browser is a sandbox, right? Because it, you know, it's running its own, you know, JavaScript in the memory, WebAssembly can be working there too.
Harrison Chase 19:40 ↗
Well so okay question about that because I think one thing that's popped up in like this sandbox usage is like how do you... like what's the right architecture for the agent and the sandbox? Does the agent run in the sandbox or does the agent like separate the brains and hands and run outside and connect? And so I'm curious for like browser stuff like...
You mentioned, you know, in some ways a browser is like a sandbox. Do you see people mostly running the browser whatever as a separate thing and having the agent over here as a separate thing and just talking to it as a tool or do you actually have to collocate them?
Paul Klein 20:10 ↗
Yeah, I've seen more and more that people are separating the agent brain from the tool calls especially because you want to be able to like look at the data in between and make sure it's not sending any bad data towards the tool. Like let's say, like let's remove like sandboxes and browser for a second just to keep it high level. Like let's say your agent has a tool to make an API request or something. It just has a network tool. Like you probably want some layer between the agent saying issue this network request that looks for like PII or social security numbers and strips it out before it goes out to the web. So like separating those and that like control layer makes a lot of sense. Also to avoid like prompt injection coming back from the tool into the agent like having those separate is important. You kind of want to have a safety zone around your agent logic. But then yeah, for the browser I think that maps to all tools like all tools probably should run outside the agent loop or sorry the agent harness in some sort of safe environment that could be destructible like one-time use. You probably don't want to have tools reused across the same sandbox or same like virtualization layer because then what if some pollution happens from the last tool that's called or how do you like manage the file systems across those tools? Like all these things are just super challenging for us to figure out and in the end I'm always looking towards what are our customers doing. It's tricky because you hear customers speaking very different things and I think your customers are probably even more diverse than ours because like some of my customers I describe as like the cracked engineering teams that really push things forward and then other customers are really getting started on their AI journey and trying to build for both is very very challenging and you almost have to move up the abstraction layer from the cracked teams to the more like newer teams or enterprisy teams. How do you think about that? Like how are you shifting the abstraction layer across the two different types of customers you might have?
Harrison Chase 21:47 ↗
I think we look at those AI builder engineers for like where the future of agents is going 100%. And not everything, you know, not everything going on there is going to be kind of like enterprise grade or even like the right way to do things, but people are experimenting. And I think that's really cool to see. And I think if you see people experimenting with the same thing in three slightly different ways, you're like, "Okay, there's something kind of like interesting there." And so you know when people do bespoke things if it's the first time we see it and they're like hey like I'm trying to do this bespoke thing there's nothing easy in kind of like Deep Agents to do that. I think that's where now we feel good about our open source story where there are different levels of abstraction and there's like LangGraph at the lowest level and so if you want to do anything you can do it in LangGraph like you can use LangGraph for just like arbitrary things like...
Paul Klein 22:38 ↗
You fork it to like there's always an escape hatch into the lower levels of the...
Harrison Chase 22:42 ↗
Exactly. So it's like LangGraph, LangChain, Deep Agents and depending on what you want to do you can kind of go down those different layers. And so but then like once we see people doing like the same thing like yeah three times we're like okay, you know, like an example of this would be offloading of tool calls. So tools return really large responses. I think it's generally standard practice now, but wasn't like a year ago to basically dump that to a file system and say, "Hey, here's the first like thousand characters of that, but if you want to read the rest, you can like go just navigate this file." And so now that's part of Deep Agents. And so we try to do that because absolutely there are a bunch of teams that want to take... So I actually think there's two things here. I think like it's yes like maybe they're not as AI-pilled as others, but I also think it's like there's all these lessons that we're learning from coding agents that are actually just more broad than just like, you know, a coding agent that you run locally. And so when a lot of these people want to take these best practices and use them for their first-party agent which may not be a coding agent and may not even run in a sandbox or things like that. But yeah, we want to take these common things and bring them so that everyone regardless of whether they're building coding agents or not, regardless of whether they're AI-pilled or not, can kind of like take them and use them to build agents of their own. So that's kind of how we think about balancing it.
Paul Klein 23:59 ↗
Yeah. And it makes sense. I mean, I'm starting to think a lot more about where the models are going to go because I think like if we look back two years, things have come and gone quite a bit. Like remember one of the labs launched like this DAG builder, this workflow thing and then like I was like everything's over and then I've never heard about it again right like computer use launched there was like this thing sucks it's never going to work like Operator was not that good that actually held back my industry a little bit like it's computer use is bad like no it's changed right like we've had these highs and lows and these head fakes around technology changes that can make it really hard to predict what's going to stick and what's not. How do you think about that for these like bleeding edge innovations? Like how do you tell if something is like a long-term, you know, innovation or just a temporary thing?
Harrison Chase 24:45 ↗
I mean, I think so I definitely hack around with a lot of stuff and so like whenever I'm trying to really understand like a product or technology, like I'll just go build with it or use it or try to build something in that way or something like that and then if I think it's like reasonable and exciting for whatever reason, either it makes it easier or it enables something that wasn't before, that's how I get like the most conviction of things. I think it is like a weird mix of being realistic about where things are but also optimistic about the future. Like yeah, we had something in LangChain called agent executor in like November 2022 but like we did not go all in on that because we realized that, you know, it just didn't work at the time. And so like, you know, counterfactual what if we had... what if we were just like hey we're going to start building an agent harness in 2022. I like... I don't know what would have happened like, you know, would people have used us? Probably not because you couldn't really build anything with that. So I think it's a weird mix of like what can you build now and what can you be practical with now and then yeah what can you architect for the future. My general philosophy has been try to not like make any crazy wild bets... or what's a better way to say this. I think my general philosophy has been like build up kind of like a team or a process or an ethos of just iterating super rapidly rather than like being super dogmatic and sticking to like yeah this is kind of like the way it has to be done. And obviously if you can make that bet on like, hey, this is outlandishly true and correct...
Paul Klein 26:30 ↗
bet and I'm going to stick to it for like 3 years, that is like incredibly impressive and like you'll there's probably a lot of value to be captured there.
Harrison Chase 26:36 ↗
That's browser based, right? I mean like I I I do agree though. I think I made this dogmatic bet on the browser in 2023 like a can use a browser and like there wasn't much evidence of that and like for the first I'd say almost a year browser automation done by a large language model was super hacky like we used to draw bounding boxes on stuff and like send it to screenshot and we'd annotate the screenshots for the LLM and so much has changed uh but I do think like those like having that core founder conviction in certain principles and ideas that's what makes our companies, you know, go really far and then at the same time you have to have some degree of skepticism about like what is the right way that fits onto the world like it's a worldview and then there's reality.
You have to like iterate on that as well like I mean when you were talking earlier about like yeah you know initially people wanted the higher level thing but now they want the low level like that you know like the core idea of LangChain has always been that people want to build their own agents for their particular domains and their particular tasks. What that has looked like has absolutely changed and so I think like there's like yeah having kind of like a mission and and a focus. And then there's there's more kind of like small micro things which actually matter a ton because if you get those wrong like yeah you can be like yeah you know I I built an agent harness in 2022 and and you know no one used it why not? It's like yeah well that you know like directionally like interesting yeah people want to build agents but like the micro was like yeah that's not the right way to do it at the time and so I think there is this balance which is tough to...
Paul Klein 28:02 ↗
Yeah and my roadmap has become more and more dominant about like second order effects like you know for the browser stuff a lot of time I'm spending right now is on agent identity and how we the browsers log in and how make sure these are trusted and like browser based in the future might be more of an identity company than a pure infrastructure company because that's a really really important problem to solve with a lot of counterparties.
For you and I think some of the stuff you did around observability like the second order effects around agents like you have to observe them and then you can use that data to actually make them better and self-improve and reflect back. What are some of the second order effects that you've seen from like LangChain or agents built on LangChain and like how have you oriented your product around that? I imagine some stuff on the data and the trajectory side has been very useful for your customers.

33 more exchanges in this transcript

Sign in free to read the rest of this interview. No card required.

Sign in to read the full transcript

Cite this transcript

APA, MLA, BibTeX
APA

Chase, H. (2026, September 15). LangChain CEO Harrison Chase on the infrastructure bet he got wrong [Interview transcript]. Browserbase. CEOInterviews.AI. https://ceointerviews.ai/interview/3085115/

MLA

Harrison Chase. "LangChain CEO Harrison Chase on the infrastructure bet he got wrong." Browserbase, 15 Sep. 2026. Transcript, CEOInterviews.AI, https://ceointerviews.ai/interview/3085115/.

BibTeX
@misc{chase2026_3085115,
  author       = {Harrison Chase},
  title        = {LangChain CEO Harrison Chase on the infrastructure bet he got wrong},
  howpublished = {Interview transcript, Browserbase. CEOInterviews.AI},
  year         = {2026},
  month        = {sep},
  url          = {https://ceointerviews.ai/interview/3085115/},
  note         = {Speaker-attributed transcript with timestamps}
}