Hi. Good morning. It's Blair Abernethy, a software analyst here at Rosenblatt. Thanks for joining us. With us for this session is Pegasystems. We have Don Schuerman, who has been the longtime Chief Technology Officer of Pega. Welcome, Don.
Nice to be here.
We've got some prepared questions that I'll walk us through, but if anyone in the audience has questions, they can feed them to me through the button in the upper right corner of their screen. Let me just start, Don, just to set some context for the discussion. For some people on the call that might not be as familiar with Pegasystems, maybe just give a brief overview of your business, sort of the core end markets that Pega addresses. Just a little bit about your role.
Certainly. Pega is in the workflow and decision space. We drive what I would call mission-critical workflows and decisions for pretty global firms across industries like financial services, federal and regional governments, insurance, healthcare, et cetera. An example of some of this would be Verizon uses Pega's AI technology, which is sort of a decisioning statistical AI technology, to figure out what the right conversation to have with every client is when they interact with a client. We do similar things for folks like Wells Fargo and Commonwealth Bank of Australia and others. We are also used across industries as a workflow platform for things like customer servicing, investigations management, claims management, onboarding, KYC, those kinds of things.
Great. You have been in your role for a while now, right?
Yeah. I have been around Pega for a little over 25 years. My background is in our support and engineering and then deployment organization. I spent many years doing what I think the cool kids today are calling being a forward deployed engineer. Back then
I was just a consultant who knew enough to actually write software when it needed to be written and knew enough people back in product management that if he found things he did not like, he could get it changed. But I did that for many years. Probably about 10 years or 12 years ago, took on the Chief Technology Officer role really in a field-facing capacity. I spend about 50% of my time with Chief Information Officers, Chief Technology Officers, chief architects at our clients and potential clients, really making sure that we understand their roadmaps, their architectural patterns, where they are going with technology, and then making sure that they understand what we are going and we understand the map between those.
Then I spend the other half of my time with my team, which is really focused on go-to-market activities. Everything from brand to sales strategy to activation and corporate comps.
Great. That's great because it's really great to get a touchpoint into the way the customers are doing right now, and particularly around AI. How is AI significantly impacting your customers in your key verticals, banking, insurance, healthcare, and so forth? What are the pain points they're trying to figure out?
Well, I think there's one pain point that everybody's kind of been dealing with, and frankly, we've all been dealing with for, I would argue, since GPT popped up, which is pressure from Chief Executive Officers and boards to just demonstrate that we're using AI. I think that pain point hasn't gone away. I think there's that continual sort of pressure of are we being AI first? Are we becoming AI-led organizations? Where I think the shift that I'm starting to see in client conversations is shifting that conversation towards value. So it's not just are we using AI?
I thought it was a really interesting bit of whiplash in the market in Q1, Q2, where it seemed like literally in a couple of weeks, we went from everybody talking about token maxing and putting up leaderboards of who was using the most AI and celebrating the people who are burning through millions of tokens every week or month, to a sudden realization that, wait a sec, those people are spending lots and lots of money using those tokens. That stuff is not free, and it's not going to be free. So what we really need to do is actually how do we ensure that in the concept of tokenomics, which has now kind of taken over the conversation, how do we make sure that we're governing our use of AI so that it's attached to where the actual value is?
I am seeing in the client conversations I have a shift back to not just let's do a lot of AI, but where can I use this to drive meaningful value in my business? Ultimately that comes down to where can I use it to drive better customer experiences that help me drive increased revenue. Where can I use it to drive measurable efficiency gains? Not just sort of that generic sense of, yeah, we all have Microsoft Copilot and we feel more productive, but actual measurable efficiency gains, often measured at the process or the workflow level. Things like regulatory adherence, right? The kinds of consistency that, especially in a regulated industry, is absolutely essential when you deploy any technology at scale.
Right. Great. If you look at just a recent Forrester Wave report, and you guys were cited in here ranked very highly as an AI platform category, maybe talk a little bit about how you sort of view what Forrester is saying and how do you differentiate yourselves out there from some of these bigger, broader companies like a Microsoft or a Salesforce?
Yeah. I think this was an interesting report that came out, right? Forrester created this, and this is the first time they've done this classification of what they call AI platforms. I think Forrester is drawing a pretty clear distinction between AI platforms and the foundation model providers. I think that's a really important distinction that I see in the market as well. Because the thing that I'm hearing from the clients that I talk to is less and less attention being paid to the horse race of which model is faster this week. Right? Obviously, there are concerns, especially in the InfoSec area, about the implications of things like Fable and what that means in terms of making sure that you are staying ahead of detecting any holes in your security wall before a model finds it. So there are obviously implications there.
But for the vast majority of enterprise use cases, the problem isn't that the model is good enough. Right? For the things that enterprises need to be able to do, which is drive in more automation, handle and accelerate intake of work, handle things like research, document management, generation of outputs, the versions of models that we had access to a year ago are perfectly fine. The challenge and the unlock is how do you connect those models to the actual decisions and processes and workflows that are really what will run a business. So Forrester's new report about AI platforms is really looking at that layer, that kind of platform layer that connects what the models can do back down into the data and the workflow and the governance structures of the enterprise itself. So it's an interesting kind of slice, right?
You can check out the report. It is on our website. I think it is probably the first thing you hit these days if you go to pega.com. The interesting thing, Forrester said two things in that that I think are really interesting. One is, they said, "Keep in mind, this is going to be a federation, not a monolith." Right? I think there is almost a sort of misunderstood story in the market right now that there is going to be one winner of the AI orchestration or one winner of the AI platform layer at the enterprise. In my experience and in talking to my clients, that is just not how enterprises work. They have different technologies that they use for different things, and in many cases, they purposely are looking to distribute investment across technology platforms to minimize their own risk and create their own flexibility.
Forrester is saying, "Look, you may have a platform like a Palantir that is really good at data ontologies and actually helping you map and understand how your data might feed up into a model, but you also are going to have a platform like Pega that is really, really good at helping you reimagine your workflows and then deploy and run those workflows in a way that orchestrate and use AI agents to maximize the amount of automation while maintaining a high degree of predictability and consistency." So that was one thing. The second thing that Forrester said, and of course we really like this, was that Forrester said that models, not insights, are actually the unlock of value for agentic AI.
The second part of your question was about Pega's differentiation, and I think it kind of hinges on that, and it comes down to what I think are three things. I think we are about to embark on a massive process re-engineering wave. I think leaders in business and the ones that I talk to. We were talking to a major U.S. bank about how they are rethinking their complaints process. We are talking to another major U.S. bank around how they are rethinking what is called KYC, the Know Your Customer process when you onboard new customers. What that is really resulting in is massive amounts of process re-engineering because the organization is realizing you cannot just drop the AI onto a broken process and expect it to fix it. You actually have to rebuild the process.
We have built something pretty unique in Pega Blueprint, which basically takes and harnesses the AI from folks like Claude and Gemini and GPT. Blueprint actually uses all those models under the covers. But it directs it at the very specific and important problem of, how do I redesign my business processes so that I maximize efficiency and I use AI in the right places where it really adds value, as opposed to not using it in the places where I do not need it, where the decision can actually be encoded into business rules, and it is pretty deterministic and repeatable. So Blueprint and that ability to help lead our clients on that process re-engineering and redesign work is one key differentiator. The other key differentiator is this need that I think clients have to be able to continue to run stuff with a high degree of predictability.
I think there was this, when AI first kind of popped up and agents first started to come up, there was this sort of idea of like, "Well, we're just going to take a bunch of documents, we're going to shove it in an agent. The agent will consume the documents, and magically, the agents will just run all the work." It turns out that's not going to happen for two big reasons. One, agents just have an inherent lack of predictability to them. They're probabilistic beings, right? And much of the work, not all, but much of the work an enterprise does is actually deterministic.
The way a bank processes a complaint or the way a bank onboards a new customer should and must follow a repeatable set of steps so that the bank can audit it, so that the bank can get economies of scale, so that the bank can actually tell their regulators they're doing the right thing. What we've done is we use Blueprint to actually build that recipe out once, so I know what those steps are, and then I can run it repeatably and consistently. That doesn't mean I can't use agents. I can use agents throughout that process. I might have an agent at the beginning that actually intakes the complaint from the customer and makes sure we capture all the information right the first time, so we don't have to go back and get additional information.
But that agent is actually being informed by the workflow, so it knows exactly the data that it needs. I might have an agent that I call in the middle of the workflow to find out whether or not this particular request is fraudulent. But I don't want that agent to reimagine the whole workflow. That would be risky and frankly, really expensive from a tokenomics perspective. I want to have that agent do something really small, which is like, "Take this, check it for fraud, come back with a fraud score risk," so then a human can make a decision or a rule can make a decision of whether or not we escalate that.
That ability to run the work predictably and do it with a predictable cost. In fact, we just announced it at our user conference that we actually aren't going to charge any of our clients a per-token fee. We're just going to charge them the case fee. How many new clients do you onboard? How many complaints do you process? We are able to do that because of how our architecture allows us to execute predictably.
Don, just on that point, if a bank's running a process, like your example you just gave, and you are in the middle of the process, and you have to kick off and use an LLM somewhere. Where is that charge coming from? Where is the cost of that going to show up for the end customer?
What we've built into our model is an uplift to our case price that allows our clients to use agents across the life cycle of, say, that new complaint. Because the way we use the models and because we are using the agents to do very surgical, specific things, when we look at kind of our math of what it takes to use agents, even if we were using 40%-50% of the steps in the process, we can actually manage that margin pretty effectively and ensure that you don't get runaway token costs. The place where things get really expensive is if you ask the agent to reconceive the entire process every time. That is pretty expensive. We want to do that once with Blueprint and then just repeat it again and again and again, consistently.
That's how we are able to sort of offer this as a per-case uplift rather than a running token meter for our clients.
Got it. I think, as we said in an earlier conversation today, you and I, you can go out and use AI to code the process. Why would I not do that?
Well, we have competed since as long as I've been with Pega against the idea of some of this stuff I want to build myself. I think there are two big reasons why we are seeing clients continue to look at Pega as a workflow engine, even as they can build this. One is, down in that engine itself is a lot of code that is non-differentiating to the client. We get used, for example, Google uses Pega to run a lot of its operational workflows. I once asked an engineer at Google, "Well, why didn't you just build this workflow layer yourself?" His point was, that's not Google's unique capability in market. Building a workflow engine is not what we are good at. We are good at networks, at search, at ads.
I want to focus my engineers on the stuff that actually adds value and differentiates us, not the core componentry. One, we get that. The other thing that I think is also really important is the stuff that we end up doing for our clients has to stay transparent and has to stay changeable. I need to be able to see where my business rules for how I handle a client complaint, or how I process a claim, or how I onboard a client, or why I made this offer to one customer and didn't make it to another. That has to be visible. If it is buried in code, the effort to extract it, the effort to change it is dramatically increased. The cost, the total cost of ownership goes up, the risk to the business goes up.
That risk compounds when that code is actually being generated by a bunch of agents who are not particularly good at writing human-readable code, and they actually tend to write a lot more of it. What we are starting to see is clients who are coming back and telling us, "Well, look, I used my agents to code something, and then I want to do something really simple, like change the label on a field." The problem is, nobody knows where that is. I've got to either send a human being searching through the code, or I have to go ask the agent to do it, and the agent sometimes will find it in the right place and sometimes won't. We want to make sure that those business rules that are essential to how these organizations run sit in a layer that is visual.
That is where I can actually see the process. I can see the rules. Business people can look at the process model and literally drag it and change it in real time. Now with Infinity '26, they can sit and literally ask an AI, but the AI will visually change the process. They'll actually be able to see and validate the change that the AI made. That transparency and that changeability that you get from our kind of visual approach to doing this that has built up over the last 30 years, that is hugely important for the kinds of work we do for our clients.
Along the same lines, you and I chatted a little earlier about this, but I think it's really important to understand. If you are a customer and you are looking at Pega, do I use my LLMs to access this? Is this my interface to my workflows now, and I just do that? Or am I steeped deeply, directly in Pega, like I've always been, and build my workflows that way?
I actually think the answer is going to be a little bit of both. Maybe the best analogy I can use with this was, up until about 10 years ago, if you wanted to go travel someplace, your only option was to go stay in a hotel. Or maybe if you were in Germany, you could find a Ferienwohnung, which is like a little traveler's house or something. But mostly you stayed in hotels. Then Airbnb and Vrbo and some of these other things popped up, and we had this idea of being able to get home shares, being able to actually share, take somebody's property over.
For some use cases, when I'm traveling with my family and we're going on a ski trip and I want to actually be able to put the whole family in a house and have a kitchen and cook meals, doing an Airbnb is great. But I'm going on a business trip down to see some clients in São Paulo, Brazil, for a big event tomorrow. I don't want to show up and try to track down an Airbnb after my flight lands at 9:00 P.M. I want to go to a hotel. I want my room to be ready. I want to get my loyalty points. I want to have a bar and a restaurant that I can order food from.
I think it's important to understand that just because a new way of interfacing with technology, in this case agents, has showed up, doesn't mean that it actually replaces everything else. I think it becomes additive. That's a long way of saying, what we've added to Pega, and we had the advantage of about 10 years ago, we made the choice to make the architecture headless. We made the entire architecture of Pega API-driven, and that was because we were noticing that clients had all these mission-critical processes in Pega, and they wanted to connect them up to a bunch of different front ends. Some of which were built for Pega users to use, a lot of back office and middle office workers. Some of which were customer facing, like their front-end websites.
Some of them were other tools that they had already given to a certain population of users. There are a lot of our clients who, like Salesforce is their user front end, but Pega is the workflow engine behind it. We built an architecture that worked across all of that. That made it really easy for us to start implementing things like MCP, which stands for Model Context Protocol, which is basically a way to let other agents and AIs know what services and tools you have available for that agent to use. In the latest version of Pega, every workflow you build or every workflow you have in that Pega instance is available as an MCP skill. Any agent anywhere can call that workflow. We've actually made the entire development environment of Pega MCP.
We have this new concept called Infinity Studio, where we took all that design time power of Pega Blueprint, and we pointed it at build time. I can literally open up Claude inside of Infinity Studio and ask it to change my workflows for me or redraw my Pega UIs or add validation rules. I'm increasing the speed at which people can build Pega. I'm actually reducing the amount of specific Pega expertise you need to deploy this stuff, which is all great. But I'm keeping that visual layer so that everybody can see what these processes are doing. I think both at design time for builders like that, but also at runtime for end users, there will be a mix. Take the complaint process we're working on for one of our banks.
Customers may actually interact with an agent where they're just chatting either via voice or text, and they don't have to fill out a form. The agent just asks them what they need to know to get the complaint started. But eventually, that complaint might get reviewed by a human being whose job it is to sit all day and make sure that the complaints flow through, right, and validate any exceptions and double-check the work of agents. Well, it's probably best for that user to sit in a more traditional kind of forms-based workflow where they can click on a work list, open up the next thing, quickly look at the data, click approve, move on. I think you're going to need to build for both, and that's the architecture that we've inherently had in Pega and that we're exploiting going forward.
Has your MCP access, are you seeing customers start to use this, or is it still too early?
No, we've already seen customers start to play with and actually deploy Pega as a workflow with another agent as the front end that they use to, say, intake into the workflow. We introduced, back in Infinity '25, the ability of Pega as a workflow to call any other agent via MCP. We've seen clients embed agents that they've built outside of Pega into their Pega workflow so that the workflow can orchestrate them and use them at the right point in time and really connect them to a business process. We're seeing, and that adoption I think has been accelerating because I think clients are becoming increasingly savvy about how they begin to piece these things together.
What's the revenue model impact for you guys if somebody starts putting a whole bunch of front ends in or embeds a whole bunch of agents along the way?
Well, like we said, many years ago, we moved away from charging per seat, per user. We ultimately charge by the number of cases. So how many complaints do you process? How many customers do you onboard? How many claims do you deal with? How many exceptions do you resolve? That's the number we care about. Customers connecting this stuff up to more channels and different channels outside of Pega generally just leads to more volume, which is ultimately where we think the customer gets value, and then that's also where our licensing model drives value.
That's great. I want to shift over a little bit to Agentic Process Fabric, which has been out there for a little bit. Maybe just to help us understand what you're doing there and why that's important.
As Forrester kind of said, and as I believe, there is not going to be one monolithic architecture inside of our clients. Our clients, these organizations are pretty sizable. What that means is they are going to have agents, and they are going to have workflows in a bunch of different places. Just take my example when I log in as an employee. There are things that I want to do that are workflows that live in Pega environments. We run all of our own sales automation. If I want to update an opportunity or create a new lead, that is a process that runs in Pega on our sales automation. But there are other things that I want to do that are workflows that do not live in Pega.
I might want to, I need to update my profile in HR, or I need to approve a time-off request for one of my employees. Today, right now, the way I do that is I swivel chair between a whole bunch of different applications. I log into a sales app. But where I think the world is going to move is applications become less about being different front ends that you log into, and more about collections of business functionality that I need to be able to reference.
It makes perfectly sense that I would have an HR app that is separate from my sales app, because the team that is going to inform that HR app is going to be different than the team that is going to inform the sales app. Makes perfect sense. But as an end user, I do not want to have to go hunting between those two. What we have done with Agentic Process Fabric is build a directory, a registry, that allows us to capture where those workflow capabilities live. They may live in different Pega apps. They might be workflows that live even, again, in apps outside of Pega. But I can build that registry in one place.
What that then allows me as a user to come in and do is instead of worrying about where a particular workflow process outcome I need lives, I can just go to the fabric and say, "Hey, I want to do this." And the fabric can say, "Great, I know where that workflow is. Let me go kick it off for you. Here is the information I need. It is off and running." The goal is to help simplify the end experience for our end users and accept the fact that architectures are going to remain pretty federated, but I need some way to bringing that federation together.
Very interesting. Blueprint itself, maybe talk a little bit about what kind of advantages Blueprint brings to your customers. Of course, you have now extended that into Infinity Studio. What is that doing for you with new potential prospects?
Yeah, I mean, Blueprint has, in a lot of ways, changed the conversation for us from a selling and prospecting perspective. What I mean by that is, Pega ultimately is a platform. Sometimes our experience in the sales process is the process can sometimes feel a little conceptual. Like, "Well, we have a platform." "What does your platform do?" "It does workflow." "What is a workflow?" You can have this kind of theoretical conversation with a client. With Blueprint, because I can literally take any client use case in really just a couple of seconds, by the way, I encourage anybody who wants to try this out, go to pega.com/blueprint, give us your email address, then start typing in the name of a process. You can literally in a couple of seconds see what the workflow looks like.
See the steps, see where the automations would be, see where Blueprint recommends you have agents do things, then you can literally hit a play button and try it out. You can actually see what the experience would look like. We have now added things like you can literally take that blueprint and plug it via MCP into Claude or some other front end, and you can literally have Claude talking to your blueprint. It is really, really powerful. So what it does is it allows us to jump in and instantly focus with the client on the use case that is going to drive the business value for them. So we shift from a technology conversation to a value conversation. It allows the client to sort of visualize and experience what that could look like right away in the first meeting.
We do not need to send a team off to build a demo or do anything. We are literally in the first meeting showing them what they could look like. It dramatically accelerates that. That is all sort of focused on getting the design right, getting the process right. With Infinity Studio, which is a part of the Pega Infinity '26 release we GA-ed last month, we have taken that AI capability that was in Blueprint to design your workflows, and now we have pulled it into how you do the build. If you think about it, you got to get the workflows laid out. You have got to get all the stages and steps. That is 40%, 50% of the work.
I have to do things like wire it into my existing systems and make sure my data model is aligned and make sure my security definitions about who is allowed to do what in the workflow are all appropriately defined. Make sure that the validation rules I want to have on every screen match up with what the business wants. That is sort of the build stage. Well, now with Infinity Studio, I can do all that build with an AI assistant as well. I can literally ask it to go update this or change that or add a step here or fix a validation. Without having to know nearly as much about Pega, I can actually have the AI do a lot of the Pega configuration build for me.
Does ultimately this mean your customers will need less resources tied to running your systems?
I think, look, the number one goal for us is to get the client to the value faster, right? Because the value of Pega is we are going to give them a workflow and a process for whatever use case they are running that is better than what they are currently doing, more efficient, more responsive, better adherence to their regulatory, more auditing, more control. There is a whole bunch of business value tied to that better, right? One of the banks that we are working with are on some of this agentic stuff. They are looking at six-figure to nine-figure use cases, like business cases in terms of the better they get. The faster I can get you to that better, the faster that you start claiming credit for that is ultimately better for the client.
What Blueprint does is Blueprint allows us to compress the design phase. Now Infinity Studio allows us to compress the build phase. I need fewer time. Hopefully, I also need fewer people, and I need fewer deep technical Pega expertise. I can get to that value picture faster. Then by putting agents into that workflow, I am actually getting even more value. I have also increased the value side of the equation as well. I am getting there faster, and the value that I am getting at the end is more.
Interesting. Along the same lines, I wanted to ask you a little bit about on a legacy application modernization, moving it to your platform or others. What is happening in that area? Are you seeing a speed up with AI?
Yeah. I think AI has done two things for legacy transformation when I have talked to clients about it. One, it has increased the urgency. Like I say, the problem is not the models. The problem, they are connecting the models into your existing data, your business logic, your workflows, et cetera. If that business logic and data and workflows are buried inside of legacy systems that were written on COBOL 30 years ago, that I have very little ability to change and very little confidence in my ability to change it, I am not going to be able to get any of the agentic value I want. There is an urgency to do legacy modernization.
At the same time that AI and agents have created urgency, they have also actually reduced the barrier, because it turns out agents are actually pretty good at going through and understanding what is inside of a legacy app, at analyzing code, at analyzing old documentation. We have now worked both on some of our side, but also with partners. We are very tightly partnered with AWS with a product that they have called Transform, which is sort of the interpreter of this stuff. There is actually a direct plugin using MCP again, so that Transform, if it has got something that is a workflow, it calls Blueprint to then redesign that workflow.
The other big thing that we've seen from clients is the desire of, "I don't just want to lift and shift these legacy systems." Yes, there's benefit of getting stuff out of the code, but the process that I engineered into a COBOL system 30 years ago is probably not the right process for my business. As I go through that modernization, I also want to be reinventing the process itself to make it more efficient, to make it more customer-facing, to make it better work with what AI can do, and now automate more and more of the process. The power of Blueprint is not only do I get the technology shift of I've moved from an old legacy technology to modern cloud-based technology, which is what Pega is, but I also can do that business re-imagination of how the work gets done.
I'm adding more efficiency and more productivity to the process in a really measurable way.
Good thing. Earlier today on another call, you and I talked about your view on LLMs. The choice of different LLMs, and open source versus proprietary and so forth. Maybe just how do you guys see it? How do you see it, and where do you think this goes?
Well, look, I think the market loves the horse race, right? The market loves the horse race of who's got the fastest LLM today, and I think there's lots of interesting debate going on right now around open-source models and the costs of those. There's obviously a bunch of geopolitical security questions around some of the source of some of those open source models, which I'm not going to dive into. What I think, to me, is far more interesting is how do we plug the power of the models that we already have into solving the real business problem needs that our business has today, right? I talk to a lot of clients, and what they tell me is, "Look, I don't need most of what Fable does.
Yeah, my InfoSec team needs Fable because they need to be constantly checking and making sure there are no holes in our security layer." Great. But to automate how I do complaints, I don't need Fable. What I need is I need Sonnet, I need Opus, I need GPT-5. I need some of the stable models that are out there. More importantly, I need them actually integrated into my processes to do the things the models are uniquely capable of doing, not to replicate the deterministic decisions that I can do in far more cheaper and far more dependable technology and consistent technology than the models. So what we're really focused on is what the world is increasingly referring to as a harness. How do I harness, how do I pull the power of the model in?
But for us, that's how do I direct it at solving the problems of the workflows in the business. That's designing them with Blueprint, building them with our new Infinity Studio capability, and then running them so that I'm deploying agents in the places where the agents add value, and I'm doing the deterministic things, the repeatable things, the predictable things when I can, which we find is 80%, 90% of the work anyway.
Interesting. Of course, the deterministic side of things is much cheaper for the customer.
Well, it's much cheaper, and I think there's been this shift. I hear clients using the word deterministic more and more often because I think there's this realization that when agents first popped up, like I said, it was, we're going to throw agents at everything. Then what clients are realizing is, well, that's far too expensive. The stuff that's deterministic, keep deterministic because I know how to do it. I know how to run it cheaply. I don't need to pay for a lot of tokens. Surgically use the AI to do the stuff in the context of that deterministic process that I couldn't otherwise do deterministically. That's things like mapping and handling unstructured data, researching across vast scopes of automation, doing deeper level of analysis, and putting scoring around things.
There are things that the AI will do uniquely that I couldn't automate before, but it's at very specific points in the process. It doesn't work when you try to have it do the whole process, because then it becomes both very expensive and very unpredictable.
Interesting. One of the things you guys have talked about in the past at some of your user conferences really is sort of moving towards an age of autonomous enterprise.
Yeah.
Just give me your perspective on that and sort of where are we on that path.
I think most organizations are starting to build the architecture for it. I think we see I was reading somewhere, some report someplace, that some organizations are saying, "Well, we have thousands of agents deployed." Well, yeah, I probably have, in the team that reports to me, a couple of hundred agents running. Most of them are little individual agents that people have built to monitor their email in the morning or like. That's all great. That's fine. I heard a presentation from the head of the Federal Reserve Bank of San Francisco, and she was basically saying that the problem with this kind of productivity stuff is it shows up everywhere except in the numbers. I have no way of actually knowing from my team's perspective, does that agent that's handling your email in the morning, is that making us as a team more effective?
I don't know, maybe. Where I think the autonomous enterprise is moving towards is, let me look at the things that the actual business needs to do. I need to process 10 million customer service requests every year. I need to do them following our rules, I need to do them in a way that keeps my customer really happy, and I want to reduce the cost that it takes me to do it. Now I focus on a workflow, a process, a thing that has an outcome associated with it, and I start applying the AI to add the autonomy where I need in parts. I use the AI again at the beginning to be that autonomous design agent that actually helps me get the workflow right to begin with.
That's where we really focus, and I think that's where a lot of our clients are on that journey. It's like I'm starting to move from, "Yeah, I got a bunch of agents everywhere, great," to, "Well, what are the ones that I can actually really measure the value of what they're doing?
Are customers looking at this then from a system level for their organization, like abstracting up a little higher?
I think it depends on who you talk to in the organization, right? Architects got to architect, right? Every architect I talk to, they've got their boxes and their layers of what they want to build inside the system. I think they are, and I think that's why organizations have architects and architect disciplines, right? That's where I come from, frankly, in my background. You've got to get that system architecture right. Then the next step is you actually then have to take that system architecture and you have to apply it to real use cases. Right? There's no ROI in an architecture. There's only ROI when I apply an architecture to an actual process that is how my business runs, where I can drive actual efficiency gains or actual customer satisfaction increases.
Yes, you've got to get the systems, and there are people that are actively doing that, and we're having a lot of those conversations. But we're also trying to have conversations around what are the real use cases that are going to drive value.
Okay. Yeah. Great. I wanted to touch on, before we finish up here, a couple of areas that we haven't talked about. One is the area of process mining, which you guys bought into a few years ago with an acquisition. It seems like that has probably become more important of an area now with AI.
I think so. I think it is an interesting input, but it's not the only input. Right? I think process mining and process mining technology, what it does is it looks at the logs of systems that are running and tries to deduce the processes of what people are actually doing. I think that's useful. Again, I think that's a very useful input. But I also think our clients also struggle a little bit, and I think this happens across the board, which is most of our clients actually don't want to re-implement what the users are currently doing. They want to implement something different, something better, something that's more efficient. The important thing for us is, yes, that process mining is an interesting input, but we view it as a feed into Blueprint.
Keep in mind that Blueprint is also, not only does it have all these powerful models, it has our own AI database of industry best practices and ways in which we've done this. We've actually opened Blueprint up so that our partners like EY and Cognizant, they've actually injected their own industry expertise now into some proprietary versions of Blueprint that they run. To me, the interesting thing is not the process mining data. It's great that we know what we're currently doing, but how do I intersect that with the best practices so that I can actually push my client up and away from the as is and towards a better version of that process that's really ready for agents?
Yeah. I have two more questions for you. One is a sort of a legacy question, if you will, and the other one is sort of the future. On the legacy side, you've had a small business in robotic process automation, screen scraping driving desktops, all those kinds of things. What's happening there? Is that going away or is AI helping that?
I think like many things, AI is actually helping us deploy those bots faster. But we've always felt that RPA was a band-aid. To me, RPA is a quick way to go and patch a pothole on a really messy street. You can get away with that for a while, but ultimately, sometimes you just need to come down and repave the thing, right? Or sometimes you need to actually say, "That road was not the right road to begin with. We need to put in a superhighway." So, we've always felt RPA as sort of a shortcut to either interface out to systems that we didn't have an API to so we could pull in some data when we needed it or to create some quick wins and value for the business so that we actually could fund the deeper process redesign work that needs to happen.
That's going to continue to be there, but my hope is that as we continue to accelerate and make it faster to actually redesign the whole process with Blueprint and then build it with Infinity Studio, we don't even need those stopgap measures anymore. That would be an ideal world for me.
Right. Another future-looking question is, I mean, you talk to a lot of customers, you see it inside a lot of very large institutions of all sizes or a variety of sectors. What's your view on AGI, and are we getting there. Are we a long way off. We've had so much advancement in the capabilities of the LLMs in the last 24 months or 36 months. What's this going to look like in two years.
I am a skeptic. We may get to some form of. One, I don't think anybody actually can define what AGI is. Two, I actually don't know whether LLMs, which are essentially text and pixel prediction machines, whether that's the architecture that ever gets us to AGI or whether it's that architectures plus a whole bunch of other AI architectures we haven't built yet. I try to draw a separation between what I think are the big questions, and it's really interesting to talk about AGI and the future of human intelligence, et cetera. I actually don't think that's what my clients are dealing with. My clients aren't asking me about AGI.
What they're asking me is, "Man, how do I use this stuff today in a way that actually is meaningful to my customers and meaningful to my employees, and actually changes the trajectory and the profitability of my business." As fun as it is to debate the big questions, I try to focus a little bit more, because my clients, I think, want us to, on the pragmatic questions.
Excellent. All right, we're going to wrap it up here. Thanks very much, Don. Great chatting with you, as always. I love your insights and thanks for participating today.
No, thanks for having me. Bye, everybody.