Vinny LaRocca: Thanks for joining, everyone. We’re going to be talking about agentic orchestration today. If you have any questions, just make sure to put them in the chat, and we’ll get to those at the end of the presentation. I have with me Logan Emerson and Jacob Ortega. Jacob is one of our senior engineers with Lydonia, and Logan Emerson is in charge of AI with UiPath.
Jacob Ortega: So, what you guys will see on my screen really serves as the foundation of the agentic experience through UiPath, right? Outside of all the traditional platform components, from robots to orchestrator, we actually need a place where we can orchestrate and really start to, you know, build out the individual capabilities that you will then start to see in Logan’s demo when he gets to it.
What I want to show you guys here is kind of a take on a traditional manufacturing process or system of processes that we would see, which is traditionally called predictive maintenance, right? I have a machine. I get data from that machine. And ultimately, I have to make determinations on when I should do maintenance, or what really constitutes, you know, an event or a need to actually take a look at that machine and make changes, or figure out if something’s wrong.
Now, traditionally, this is called predictive maintenance, right? But I think, with agents, we can kind of reimagine this experience into more of an idea of prescriptive maintenance, where we can actually offer clear and actionable recommendations based on the data that’s coming in.
So, we’ll get to that in a second. But I want to just kind of walk through agent builder for you guys at a high level if you haven’t gotten your hands on it before. What you’ll see here is a simplified kind of building experience, the way that UiPath really likes to build their products. They want to make it as easy and actionable as possible.
And so, what you’ll see here is the input system prompt, which is what is actually going to instruct the agent on how to act? What tools should I use? What sequence of events should I use in my reasoning before I make a decision? And then ultimately, what should that output be, right?
In this case, right, we’re going to be taking a data set, querying all of the different machines on that data set, identifying if they’re at risk or not. And then, if they are, we’re going to cross-reference failure reasons, both historical and things that come from the manufacturer to report on why this might present a failure risk, and then generate, you know, a summary as well as interact with systems like Jira or, say, ServiceNow, right? Ticketing systems to actually notify a technician that, hey, something is wrong, and based on our historical data, this is how we should address that problem. Now let’s go act on it. So, we can see in agent builder here as well, we have the tools that we’re actually going to be using to interact with.
In a traditional manufacturing environment, you might have sensors or IoT devices taking that stream of data and plugging it into a data lake or a database. Maybe it’s in a cloud provider. So, we’re going to actually use robotic process automation to go and grab that data from that data store, right? We have the ability as well to interact here with Jira, which we’ll see in a second.
But the real, you know, the real, you know, kind of weight behind this process and what really makes agents so powerful is the ability to cross-reference that historical context.
So, here we can see that the agent is actually going to be able to go and interact with a context store that has all of the historical failure data, all of the technician reports, the manuals for each of the machines, as well as a list of the team members, their individual skills, and what they’re qualified to do maintenance on.
So that once that agent makes a determination that, hey, this machine is at risk, we need to take action, here’s what we believe the next step or the suggested action should be, we can then assign it to the right person, which takes all of the mess out of the scheduling, right? Ultimately, what this process is going to allow us to do is just speed up the reaction time to anomalies we might find, reduce that downtime of those machines, which should, you know, actually influence and help us on our maintenance process overall, right?
So, what I’ll walk through here real quick is just an output of what this run looks like. So, here we can see when the agent actually triggers itself, it’s going to pull all that machine It’s going to actually use that context, right? It’s going to pull that context where we can see there’s risk reasons as well as descriptions for why these machines might, you know, fail. We can see the parts might be, you know, near end of life, right? We have all that context at our fingers so the agent can pull that data down, cross-reference that context. And then, once it makes a determination that this machine does, in fact, need to be serviced, we can see it interact with the tools for Jira, so that we can connect to Jira and then ultimately create a series of tickets for the machines that are at risk. And you can see this here. In Jira, we can see that the machine fan cooler 900, it’s at risk due to excess vibration.
And what the agent is able to do is create those suggested next steps that pull from that historical data, which tells us to inspect and secure the fasteners. It tells us exactly where that machine is, and then it assigns it to an individual to go and take action on it.
So, ultimately, this is going to increase the consistency and the accuracy of these maintenance decisions. And we can do it all just within this tool. It’s really cool.
Vinny LaRocca: Thanks everyone for joining. Feel free to reach out to us if you want any more additional information or if you want to discuss, use cases. But yeah, thanks again.
