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. There'll be, you know, 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 like arrive before the others?
And so I was thinking about this question: what makes some agents kind of like succeed in the enterprise and some fail? And I was chatting with my friend Assaf. He's the head of AI at Monday. He also wrote GPT-Researcher, it's 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 like first principles, like what makes agents successful in the enterprise: it will make it more likely to be adopted the greater the value of the agent if it's right. These probably aren't going to sound kind of like earth-shattering, but hopefully we'll get to some interesting points. If the more value it provides when it's right, 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 like ingredients which are pretty simple and pretty basic, but I think provide an interesting kind of like first principles approach for how to think about building agents and what types of agents kind of like find success. And you know, I say in the enterprise here, but I also think this applies just generally within kind of like society. If we want to try to put this into a fun little equation, you know, 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, like 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 like stats math formula.
So how can we build agents that score higher on this? Because this hasn't been anything kind of like earth-shattering so far. Hopefully we'll get to some fun insights when we talk about how to make that equation kind of like go up. So how can we increase the value of things when they go right, and what types of agents have higher value?
So part of this is choosing kind of like problems where there is really high kind of like 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 investment research. And so these are examples of what I would say kind of like high value tasks are.
There's other ways to kind of like improve the value of what you're working on besides just switching kind of like 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 like existing or older school question answering solutions, they would often respond kind of like quickly, ideally within 5 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 like inline autocomplete, maybe some chat question answering. There in the past like three weeks there's been what, seven different examples of these ambient agents that run in the background for like 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 like as you 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 like 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 like more long-term and do more kind of like 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 types of agents that's totally fine. You can have agents that run for a while and kind of like 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 like 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 more the solution for this is basically make more and more of your agent deterministic.
There's this concept of kind of like 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 in to this spectrum of workflows and agents and allows you to be wherever is best for your application on that kind of like curve. And where on that curve is best totally depends on kind of like 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 like uncertainty around how this agent is kind of like performing.
And so besides just like 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 eval plays 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 like patterns.
And so again, like the observability part, you can just see every step that's happening inside the agent. This reduces the kind of like uncertainty that people have around what the agent is 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 like the perception or the risk that people had of these agents.
And then the last thing I want to talk about is kind of like the cost of something if it's wrong. Similar to kind of like the probability of things being right, this plays an outsized kind of like role, 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 like brand damage or, you know, giving away things for free. There's this, I think there's an outsized perception of kind of like what could happen if things go bad.
And so I think there's a few kind of like UI/UX tricks that people are doing and that successful agents have to kind of like 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 like 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 like what the agent does.
And then the second part is having a human in the loop. So rather than, you know, merging code changes into main directly, open up a PR — that's putting the human in the loop. And so then the effect of the agent is it's not kind of like making changes, there's the human who's kind of like 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 costs 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 like calibrate on what you want to research. That puts kind of like the human in the loop. It also makes sure that it gets a better result, so it increases kind of like the value that you're going to get from the report because it's more aligned with what you actually want.
And then during deep research, it doesn't, you know, take this and publish it as a blog out on the internet, or doesn't take it and email it to your clients. It produces just, you know, 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. So Claude Code also has this ability where it asks questions, it clarifies things. This is to kind of like 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 like directly to master. And so I think these are examples of things in the general industry that kind of like follow some of these patterns.
So okay, so we've figured out a few levers that we can kind of like pull to 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 like has 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 like ambient agents, which is when we think about agents working, you know, this futuristic view of 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 like 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. Like I can only really have one, maybe I can have two chat boxes open at the same time, but now there can be, you know, 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 in chat you have this kind of like 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 like, 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 like a bigger body of work. You can go from kind of like changing one line of code to changing a whole file or making a new kind of like repo or any of that.
And so instead of this agent just responding directly or calling like 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 like 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 like 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 like run wild. And so ambient does not mean fully autonomous.
And so there are a lot of different kind of like human-in-the-loop interaction patterns that you can bring into these kind of like background, these ambient agents. There can be like an approve-reject pattern where for certain tools you want to explicitly say yes, it's okay 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 like ask questions so that you can answer them, you can provide more info if it gets stuck kind of like halfway through. And then time travel is something that we call human-on-the-loop as well. So this is after the agent's run, if it messed up on step like 10 out of 100, you can reverse back to step 10 and say, 'Hey, no, like resume from here but do this other thing like slightly differently.' And so human 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 be right now. Like 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 like sync-to-async agents.
And so Factory is a coding agent, they use a term kind of like async coding agents, and I really like that. But I think this kind of like sync-to-async agents is a natural progression. If you think about it, like right now, or you know, a year ago, everything was a sync agent. We were chatting with it, it's very much in the moment. The future is probably these autonomous agents working in the background and still pinging us when they need help. But there's this intermediate state where the human kicks it off, uses that kind of like 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 like 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 to kind of tie this together and make 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, you know, in theory unlimited. But 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 like 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 this is — 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 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. Yeah.
