Liz Bearce: Thank you for joining our webinar, co-hosted with UiPath and Lydonia, to discuss the future of work, the power of agentic automation.
Logan Emerson: So good to meet you all. Thanks for having me. I want to talk about why AI has led UiPath’s innovation and how it has led our innovation. So really, we’ve had a longstanding focus on AI. Our 1st studio version—sure, most of you are familiar with Studio—is where robots and workflows are developed. Our 1st studio version was built around an AI Lab library about a decade ago. Really, leadership and RPA started with our effective use of machine learning to power computer vision, which you see all the way on the left side. There, it enabled us to automate against UI elements in ways that our fiercest competition at the time, which was Blue Prism, just couldn’t do.
Oh, back to the innovation slide, if you could. Thank you. So, tasks that took days of development for that competition really only took minutes for us, given our investment in using AI in the appropriate places. So we harness the power of AI right at the beginning. This tradition is continued. We apply AI behind the scenes in much of our platform, not because it’s flashy or cool, but because it’s effective. Of course, I have some biases. But our orchestration, governance, and document processing solutions are all top-tier, much because of this tradition of AI leading our innovation. And today, we’re carrying this baton into the agentic AI space.
So now, let’s talk about robots and agents, and maybe what makes them a little bit different from one another. So you’re all familiar with robots. Some of you may already have a good idea of what an agent is, despite every agented company out there maybe defining agent a little differently. But this visual helps with differentiation a little bit. Honestly, I think we have better visuals—or we’re going to have better visuals—both Lydonia and UiPath in the future. But let’s use it as a base to get started.
So, yes, agents are goal-based, you can see on the left side in the teal, while robots are rules-based. That’s to say that robots are given discrete paths to follow. They’re on rails to do exactly what the developer tells them to do, while agents are instead given goals to achieve—really, many goals to achieve in a process—and they’re given tools to complete those processes as well. This relationship between a developer and an agent is more like being given a handbook on how to do a process, and the resources that the agent needs to complete that process, as opposed to every discrete step needing to be given to the robot to complete that process.
Now, here’s the definition that works well for me. We can stay on this slide. An agent is a software program that’s able to use a large language model to interpret a request, come up with a plan, retrieve relevant context from knowledge bases, and then take action. That’s what an agent is. I think that’s really among the better definitions that exist out there, and it’s the one that UiPath is kind of running with, though it’s not fully described on this slide.
So, a key differentiator between an agent and a robot here is that an agent is able to learn and calibrate itself over time based on the feedback it receives from the outcomes of its actions. So it’s a learner as well. It’s not just “go do this on rails and never change the way you do it.” It’s “here’s the goal, go achieve it, how did that work out? Learn from that, go achieve it, how did that work out? Learn from it,” etc.
So as we move on, we’ll look at the agentic features coming to the platform. So agents, robots, people, and models—these are all things that will work together to get automations through. So you see, on the platform here in the studio context, there’s agent builder, agent catalog, and agent apps.
Agent builder: You can just think of this as the place where you’re going to develop, evaluate, and test agents. Pretty simple. Agent catalog: You can think of those as templates for agents. You’re going to have a large catalog of out-of-the-box templates: “Hey, this is a great start to an agent that you might need to solve this problem.” And then, agent apps: These are similar to apps that we’ve had in the past, but more interactive. So, a way for an agent and a human to give handoffs to one another pretty effectively.
And in the orchestrator space, we’ve got the agent service. So that’s for planning context, the learning piece—that’s pretty important to agents, as I just mentioned. And then the AI Trust layer is the way that we govern and monitor the agents’ actions, and even third-party agents that will become part of the play here with us.
So, there’s a concept that we have called controlled agency. Now you’ve got application reliability. Yeah, you’re good. Application reliability: So, the deterministic, on-rails robots, those are very reliable, but they have very little agency (for lack of a better term). There’s really no control that they have over what decisions they end up making. A fully autonomous agent? Not as reliable, but very much able to say, “Hey, I think I need to follow this path, so I’m just going to go for it.” What UiPath is trying to do is offer controlled agency. So, really, this is like bending the curve on reliability while still providing the benefits of agency.
So, these on the right side—these are ways that we do that: prompt auto-tuning, model selection, testing agents online and offline evaluations. These are details that you’ll find once you’re able to get your hands on Agent Builder. But ultimately, what I want to impress upon everybody here is that not all agents are created equal. And certainly, security teams, IT teams, and anybody focused on making sure that a business process isn’t going to run amok, you’re going to want to make sure that you’re orchestrating, monitoring, and understanding why processes are being done the way they’re being done. And that is also the goal of UiPath—not just to let you automate whatever can be automated with limited reliability. We want to make sure that they’re still reliable, even though they are doing things that couldn’t be done with automation ever before.
So, this is a little peek at our Agent Builder. Really, design and evaluation is all we’re doing here. So, similar to how in Studio with robots, you’d be accustomed to developing a workflow. You’d say, “This is the design that I have in mind. I’m going to drag and drop some activities, and I’m going to test this and run it in debug mode to understand what inputs and outputs I’m getting from this particular workflow, and is this going to work in my overall framework?” Well, here with Agent Builder, you’ve got similar tools to accomplish the same goals.
So, on the left side of the screen, within a screen, you’re building a prompt, you’re giving it that role, that goal to achieve, and you’re also giving it tools. Tools, at a high level, are additional—well, they’re tools. They are additional pieces that the agent can use to take action. So without any tools, an agent is just going to be able to think about things and decide what the next best action would be. With tools, you’re giving it, let’s say, an integration service connector to make an API call to Salesforce to do something in Salesforce, which would be part of the goal of this agent. So let’s say update an opportunity or do whatever you might need to do in your Salesforce environment or pick another environment—whatever integration service you need. Use an API to do some work.
Additionally, UiPath automations can be used as tools. So, if you already have an IDP workflow that works quite well, but you want to be able to do something like, I don’t know, dispute resolution or something like that, you can have an agent orchestrate the workflow of, “Let’s receive this invoice. Let’s do the next step, the next step, and then I will always choose the next best action for this particular invoice that came in.” So, on the left side, you’re prompting, you’ve got your tools. On the right side, this is where your evaluations come in. Let’s test this agent and see how it works. What did it decide to do? You could give it test cases to say, “When you receive this, I expect your output to be something like this,” and then you can find out, “Hey, give it a run and see if it actually succeeds in the test that you wrote for it.”
So, design and evaluation for your agents in the Agent Builder. The Agent Catalog, as I mentioned, these are just some of the first ones that we’re coming up with. We’re seeing a lot in our private preview that these are becoming valuable—not just agents themselves, but maybe agents that are called by other agents. You might want to have something like a CEO agent call another agent that does web search, as you see on the top right there, or you might want to just have a web search agent that gets things started for you, and then you can go into your more complex agent workflows in the future. But like any catalog, these are templates to say, “Let’s get started quickly,” and you customize them to your particular needs.
Liz Bearce: Logan, Vinny, thank you both so much for your time, and again, thank you to everyone who joined today.
