3 ingredients for building reliable enterprise agents - Harrison Chase, LangChain/LangGraph

I want to talk today a little bit about trying to build reliable agents in the enterprise. This is something we work with a bunch of people for, both people building as developers inside of an enterprise looking to build agents for their company, but also people who are looking to build solutions and bring them and sell them into enterprises.

And so I wanted to talk a little bit about some of what we see kind of being the success tips and tricks for making this happen. So the vision of the future that I and other people, I think, have a similar view of for agents is that there'll be a lot of them.

They'll be running around the enterprise doing different things. They'll be an agent for every different task, we'll be coordinating with them, we'll be kind of like a manager, a supervisor. And so how do we get to that vision?

And what parts of this will kind of arrive before the others?

And so I was thinking about this question, what makes some agents kind of succeed in the enterprise and some fail? And I was chatting with my friend Asaf, he's the head of AI at Monday. He also wrote GPT Researcher, which is a great open source package.

I was chatting with him a few weeks ago. And a lot of the ideas here are borrowed from that conversation. He'll probably write a blog post about this with a slightly different framing, which I would encourage everyone to check out.

So I just want to give him a massive shout-out. And if you have the opportunity to chat with him, you should definitely take that opportunity. Thinking about it from first principles, what makes agents successful in the enterprise? It'll make it successful, it'll make it more likely to be adopted.

The greater the value of the agent if it'sright. These probably aren't going to sound kind of earth-shattering, but hopefully we'll get to some interesting points. The more value it provides when it'sright, the more likely it will be to be adopted.

The more likely it is to have success, the more likely it will be to be adopted. And then the cost if it's wrong. If there's big costs when it's wrong, then it will be less likely to be adopted.

So I think these are three kind of ingredients, which are pretty simple and pretty basic, but I think provide an interesting kind of first principles approach for how to think about building agents and what types of agents kind of find success.

And I say in the enterprise here, but I also think this applies just generally within kind of society. If we want to try to put this into a fun little equation, we can multiply the probability that something succeeds times the value that you get when it succeeds, and then do the opposite for the cost when it's wrong.

And of course, this needs to be greater than the cost of running the agent for you to want to put it into production. And so, yeah, fun little kind of stats/math formula. So how can we build agents that score higher on this?

Because this hasn't been anything kind of earth-shattering so far. Hopefully we'll get to some fun insights when we talk about how to make that equation kind of go up. So how can we increase the value of things when they goright?

And what types of agents have higher value? So part of this is choosing kind of problems where there is really high kind of value. So a lot of the agents that have been successful so far, Harvey in the legal space is one of them.

In the finance space, we see stuff around research and summarization. These are high-value work tasks. People pay a lot of money for lawyers and for research and investment research. And so these are examples of what I would say kind of high-value tasks are.

There's other ways to kind of improve the value of what you're working on besides just switching kind of the vertical completely. And I think we're starting to see some of this especially more recently. So if we think about RAG, or if we think about kind of existing question or older school question answering solutions, they would often respond kind of quickly, ideally within five seconds, and give you a quick answer.

And we're starting to see a trend towards things like deep research, which go and run for an extended period of time. We're seeing the same with code. We start with cursor. It has kind of inline autocomplete, maybe some chat question answering there.

In the past three weeks, there's been, what, seven different examples of these ambient agents that run in the background for hours at a time. And I think this speaks to ways that people are trying to get their agents to provide more value.

They're getting them to do more work. Pretty basic, but I do think that as we think about this future of agents working and what that means, that doesn't mean a copilot. That means something working more autonomously in the background doing more amounts of work.

So besides kind of focusing on areas or verticals that provide value, I think you can also absolutely reshift the UI/UX, the interaction pattern of what you're building to be kind of more long-term and do more kind of substantial patterns of work.

Let's talk about now the probability of success. How do we make this go up? So

there's two different aspects I want to talk about here. One, I think, is about the reliability of agents. If you've built agents before, it's easy to get something that works in a prototype. It runs once. Great, you can make a video, put it on Twitter, but it's hard to make it work reliably, put it in production.

And I think the core thing that we've seen and by the way, for some parts of

for some types of agents, that's totally fine. You can have agents that run for a while and kind of you don't know what they do, and that's totally fine. Especially in the enterprise, we see oftentimes that people want more predictability, more control over what steps actually happen inside the agents.

Maybe they always want to do step A after step B. And so if you prompt an agent to do that, great, it might do that like 90% of the time. You don't know what the LLM will do. If you put that in a deterministic kind of workflow or code, then it will always do that.

And so especially in the enterprise, we see that there are workflow-like things where you need more controllability, more predictability than you get by just prompting. And so what we've seen is the solution for this is basically make more and more of your agent deterministic.

There's this concept of kind of workflows versus agents. Anthropic wrote a great blog post on this that I'd encourage you to check out. I would argue that instead of workflows versus agents, it's oftentimes workflows and agents. We see that parts of an agentic system are sometimes looping, calling a tool, and sometimes they're just doing A after B after C.

An example of this is when you think about multi-agent architectures. If you think about an architecture that has agent A, and then after agent A finishes, you always call agent B, is that a workflow? Is that an agent?

It's this middle ground. And so as we think about building tools for this future, one of the things that we've released is LangGraph. LangGraph is an agent framework. It's very different from other agent frameworks where it really leans into this spectrum of workflows and agents and allows you to be wherever is best for your application on that kind of curve.

And where on that curve is best totally depends on kind of the application that you're building.

There's another thing that is different from just building and changing the agent. And I think there's oftentimes really high error bars that people have when they think about how likely an agent is to work. I think this technology is new.

When trying to get something built or approved or put into production inside an enterprise, I think there's a lot of uncertainty and fear around this. And I think that relates to this fundamental kind of

uncertainty around how this agent is kind of performing. And so besides just making it better, a really important thing that we see to do inside the enterprise, whether you're bringing a third-party agent and selling it as a service, or whether you're building inside the enterprise yourself, is to work to kind of reduce the way that people see the error bars of how this agent performs.

So what I mean by that specifically is that this is where observability and evals actually play a slightly different role than we would maybe think or we would maybe intend. So we have an observability and eval solution called LangSmith.

We built it for developers so that they could see what's going on inside their agent. It's also proved really, really valuable for communicating to external shareholders what's going on inside the agent and how the agent performs and where it messes up and where it doesn't mess up and basically communicate these kind of patterns.

And so again, the observability part, you can just see every step that's happening inside the agent. This reduces the kind of uncertainty that people have around what the agent and what it's actually doing. They can see that it's making three, five LLM calls.

It's not just one. They're actually being really thoughtful about the steps that are happening. And then you can benchmark it against different things. And so there's a great story of a user of ours who used LangSmith initially to build the agent, but then brought it and showed it to the review panel as they were trying to get their agent approved to go into production.

And they ended the meeting under time, which almost never happens if you've been to these review panels. And they showed them basically everything inside LangSmith, and it helped reduce kind of the perception or the risk that people had of these agents.

And then the last thing I want to talk about is kind of the cost of something if it's wrong.

There's similar to kind of the probability of things beingright, this plays an outsized kind of role in especially in larger enterprises among review boards and managers, people's perception of these agents. People hear stories of agents going wild and causing kind of brand damage or giving away things for free.

I think there's an outsized perception of kind of

what could happen if things go bad. And so I think there's a few kind of UI/UX tricks that people are doing and that successful agents have to kind of just make this a non-issue. So one is just make it easy to reverse the changes that the agent makes.

So if you think about code, and this is a screenshot of Replit Agent, it's a diff that it generates, a PR. Code's really easy to revert. You go back to the previous commit. And so I think that's part of the reason why we see code being one of the first kind of real places that you can apply agents besides the fact that the models are trained on it.

It's also that when you use these agents, you create all these commits. And well, it depends how you do it. Replit does it in a very clever way where every time they change a file, they save it as a new commit.

So you can always go back. You can always revert kind of what the agent does. And then the second part is having a human in the loop. So rather than merging code changes into main directly, open a PR that's putting the human in the loop.

And so then the effect of the agent, it's not kind of like making changes. There's the human who's kind of approving what the agent does. And this seems maybe a little subtle, but I think it completely changes the cost calculations in people's minds about what the cost of the agent doing something bad is.

Because now it's reversible, and you have a human who's going to prevent it from even going in in the first place if it's bad. And so human in the loop is one of the big things that we see people selling into enterprises and building inside enterprises really leaning into.

So to make this a little bit more concrete, what are some examples of this? I think deep research is a pretty good example of this. If we think about this, there is a period of time up front when you're messaging with deep research that you go back and forth.

It asks you follow-up questions, and you kind of calibrate on what you want to research. That puts kind of the human in the loop. It also makes sure that it gets a better result. So it increases kind of the value that you're going to get from the report because it's more aligned with what you actually want.

And then deep research, it doesn't take this and publish it as a blog out in the internet or it doesn't take it and email it to your clients. It produces just a report that you can read and decide what to do with.

So it's not actually doing anything. It's up to you to take that and do things. I think similarly, when you think about code, it's another great example of so Claude code also has this ability where it asks questions.

It clarifies things. This is to kind of both keep the human in the loop, but also make sure that it yields better results. And then again, with code, maybe you're not making a commit every time you change things, but it's on a separate branch.

You open a PR. You're not pushing kind of directly to master. And so I think these are examples of things in the general industry that kind of follow some of these patterns. So OK, so we've figured out a few levers that we can kind of pull to kind of try to make our agents more interesting to be deployed in the enterprise.

What next? What next is kind of like how do we scale that? So if this kind of has kind of positive value, then what we really want to do is just multiply this a bunch and scale it up a bunch.

And I think this speaks to the concept of kind of ambient agents, which is when we think about agents working in this futuristic view, agents working in an enterprise doing things in the background, they're doing things in the background.

They're not being kicked off by humans kind of still in the loop. They're being triggered by different events. And I think the reason that this is so powerful is that it scales up this positive expected value thing even more than we can.

I can only really have one. Maybe I can have two chat boxes open at the same time, but now there can be hundreds of these running in the background. And so when we think about the difference between chat agents, which I would argue we've mostly seen, and ambient agents, one big difference is ambient agents are triggered by events.

That lets us scale ourselves. Instead of a one-to-one, it's now a one-to-many conversation that can be happening. And so the concurrency of these agents that can be running goes from one to unlimited. The latency requirements also change. So when chat, you have this kind of UX expectation that it responds really, really quickly.

And that's not the case with ambient agents because they're triggered without you even knowing. So how do you know? How do you even care how long it's running? And so what does this let you do? Why does this matter?

This lets you do more complex operations. So you can do more things. So you can start to build up kind of a bigger body of work. You can go from kind of changing one line of code to changing a whole file or making a new kind of repo or any of that.

And so instead of this agent just responding directly or calling a single tool call, which usually happens in these chat applications because of the latency requirements, it can now do these more complex things. And so the value can start kind of increasing in terms of what you're doing.

And then the other thing that I want to emphasize is that there's still kind of a UX for interacting with these agents. So ambient does not mean fully autonomous. And this is really, really important because autonomous, when people hear autonomous, they think the cost of this thing doing something bad is really high because I'm not going to be able to oversee it.

I don't know what's going on. It could go out there and run wild. And so ambient does not mean fully autonomous. And so there are a lot of different kind of human-in-the-loop interaction patterns that you can bring into these kind of background, these ambient agents.

There can be an approve/reject pattern where for certain tools you want to explicitly say, yes, it's OK to call this tool. You might want to edit the tool that it's calling. So if it messes up a tool call, you can actually just correct it in the UI.

You might want to give it the ability to kind of ask questions so that you can answer them. You can provide more info if it gets stuck kind of halfway through. And then time travel is something that we call human on the loop as well.

So this is after the agents run. If it messed up on step 10 out of 100, you can reverse back to step 10 and say, hey, no, resume from here, but do this other thing slightly differently. And so human in the loop, we think, is super, super important.

The other thing that I want to call out just briefly is I think there's this intermediary state where we're starting to beright now. I wouldn't call deep research or Claude code or any of these coding agents ambient agents because they're still triggered by a human.

But I think these are good examples of kind of sync-to-async agents. And so Factory is a coding agent. They use the term kind of async coding agents. And I really like that. But I think this kind of sync-to-async agent is a natural progression if you think about it.

Right now to start, or a year ago, everything was a sync agent. We were chatting with it. It was very much in the moment. The future is probably these autonomous agents working in the background, still pinging us when they need help.

But there's this intermediate state where the human kicks it off, uses that kind of human in the loop at the start to calibrate on what you want it to do. And so I think that table I showed of chat and ambient is actually probably missing a column in the middle.

That's like these sync-to-async agents. Anyways, an example of some of the UXs that we think can be interesting for these ambient agents are basically what we call agent inbox, which is where you surface all the actions that the agent wants to take that need your approval.

And then you can go in and approve, reject, leave feedback, things like that. Just kind of tie this together and make it really concrete what I mean by ambient agents. Email, I think, is a really natural place for ambient agents.

These agents can listen to incoming emails. Those are events. They can run on however many emails come in. So that's, in theory, unlimited. But you still probably want an agent or you still probably want the human, the user, to approve any emails that go out or any calendar events that get sent depending on your level of comfort.

And so this is a concrete thing. I actually built one that I have myself. We've used it to kind of test out a lot of these things. If people want to try it out, there is a QR code that you can scan and get the GitHub repo.

It's all open source. And I think it's not the only example of ambient agents, but it's one that I've built myself. And so we talk a lot about it internally. That's all I have. I'm not sure if there's time for questions or not, one or two questions if people have them.

So my question is, although everybody is talking about agents, but only code-generating agents are the ones who are getting funding. Is it because you can measure what you have done and you can reverse what you have done? But for all other agents, you can do a lot of stuff, but you cannot measure what you have done.

You cannot reverse what you have done.

Yeah, I think I think there's a variety of reasons. I think those two measure and well, OK, so the measure thing, I think probably more so. A lot of the large model labs train on a lot of coding data because you can test whether it's correct or not.

You can run it, see if it compiles. Same with math data. Math, it's verifiable. So math and code are two examples of verifiable domains. Essay writing is less verifiable. What does it mean for an essay to be correct?

That's far more ambiguous. And so because of these verifiable things, you're able to bootstrap a lot of training data. And so there's a lot of training data in the models already about code. And so the models are better at that.

That makes the agents that use those models better at that. Then the second part, I do think code lends itself naturally to kind of this commit and this draft and this preview thing. I think that's more generalizable. So legal is a great example.

Legal, you can have first drafts of things. That's very common. Same with essay writing. I think the concept of a first draft is actually a really good UX to aim for. It lets you do far more. It also puts the human in the loop.

And so you kind of get this dual kind of like if you put the human in the loop at every step, that doesn't provide any value. Each step is so small. So the key is finding these UX patterns where the agent does a ton of work, but the human's still in the loop at key points.

And first drafts, I think, are a great kind of mental model for that. And so anything where there's first drafts, legal, writing, code, I think that's a little bit more generalizable. The verifiable stuff, that's a little bit tougher.

Yeah.

Yeah. Oh, no. Good. I'll talk to you afterwards.

Cool. Yeah, more than happy to chat after. Thank you all.