Transcription
Raul's at RAMP, and today he's going to talk to you about why agents fail and how not to lose. Raul, tell us about how not to fail, how to win.
Cool. So, first of all, who is this talk for? Then we'll cover how AI agent assistants fail. And then we'll talk about why they fail and how to fix it. And I just have one core idea I want to communicate. So if you follow along, you might catch it.
So this talk is for people with distribution. So people already winning, people that have users and mature software products that have been built over time. Um, and maybe everyone else, or founders here are selling to them or obviously trying to invest in those founders. So everyone really here.
So let's look at some examples of mature companies, uh, and their agents, right? They're not really outlier successes. I'm not going to go into details of why each of them are bad. But here's a very common example like that all of us have, like, experienced. It's like you ask this AI agent assistant, you're like, "Hey, book a flight for me." And it ends up booking it for you. And then you try to do anything else and it immediately fails, resulting in a really frustrating experience. You see this over and over again. So if I ask in Google Slides and you bold all the text on the slide and it's like the slide AI, it says, "Sorry, I can't do that." So what can you do? If you ask Siri how you slabed, it's like, "Sorry, I can't help with that." You just see this, these experiences over and over again, and these are the biggest software companies out there. So maybe we should think about why and maybe not repeat those mistakes.
So the pattern is people are building these feature-incomplete, second-ass experiences that frustrate their users, and it seems like everyone fails in the same way.
So going deeper, this is what their app looks like—what's your app looks like. Usually, there's a front end, there's a back end, and this is probably your mental model of like what's going on behind the scenes. But actually, the bigger you are and the older you are, your app gets really complex and really wide. And so there's tons of API endpoints and features, and it gets really horizontal, uh, and quite messy over time. And so this, what this is what ends up, uh, happening when you build, uh, tools on top. So you're actually stuck on this really long path to feature parity with your existing front end. So you're slowly building more and more tools that the LM can use in order to do stuff for your users.
So what ends up happening here is like maybe you gave the the LM a "book a flight" tool, but "change my seat" is like all the way down in the feature roadmap. It's very hard to communicate to your user that that's not supported and what exactly the, the, uh, feature set is. And what makes this issue worse is like actually you have this like really stacked, like jacked front-end team and PMs and designers, UX people building this great front-end experience for humans, and you have this agent team strapped on to the side and trying to catch up and build the same tools and every feature that comes out. So, you're already starting off like far behind, and you're also much slower or weaker than the people who are building your main product.
So, everyone here probably agrees building an agent for the front end is probably really easy. It's all about what tools you give it. So, and you can also call it an MCP or an ADA or or many other, uh, terms for it. But really, it's like you have these services and they're successful and you're winning and you have all this distribution. You probably want to build a tool-calling interface over all your features, not just some of them, and expose it to as many agents as possible because agents, uh, and Harrison I think we'll be talking about agent economy later, but agents will be calling lots of tools, uh, in their work, and the sooner you just, you have those tools that are, uh, complete over your feature set, the better, better off you might be. So don't mess this up, right? But it's also really hard.
So here's the core insight. So instead of you going through every single feature one by one, every single endpoint and strapping on tools on your back end, you actually want to computer-use yourself, uh, on the front end. So before you let someone computer-use you, you can either computer-use yourself or you can build heuristics and scaffolding on top of your front end to make this really easy.
So let's talk about various other reasons why this is really hard, right? So there's authentication involved. You want to give the agent access to the same features and documents and tools that the user has access to. Typically in enterprise software, there's like user roles and provisioning authentication. That is also really frustrating and really hard to support. If you end up building tools off your front end, you're actually leveraging all the work, not fighting against it, of all your front-end, uh, designers and PMs. So don't reinvent the wheel. And I'll show you how this works in RAMP.
So if you ask the the RAMP assistant to change your card branding, it's actually really like a niche feature that we have in our product. And we probably wouldn't get to adding that as a tool to our agent if we just built the traditional way. We actually ended up building this like computer-use agent that spins up a a browser with that user's credentials in the background, pulls up, and then navigates the front end. The user doesn't see that though. The user, of course, just sees that the the agent did work for it. Um, and in this way you're actually like end up supporting all your tools in one fell swoop as opposed to going one by one and like building a frustrating experience for users.
So not only is, uh, do you have a feature-complete agent, you also end up simplifying the task for the computer-use agent. So maybe it'll work in a few years, maybe in a while, but if you do end up using it today, it's probably not going to be reliable. So if you build it yourself, you end up having your own nav tree. You can simplify with, uh, DOM heuristics, and if you have your component library, you can render that into a CLI. You can scaffold the unreliable parts and focus on what's broken and not the other way where you start off with nothing.
If you want to talk about specifics, um, this is my email. Uh, but yeah, that's how we do it at RAMP. [Applause]