Pegasystems Inc. (PEGA) Earnings Call Transcript & Summary

Good morning. It's Blair Abernethy, software analyst here at Rosenblatt. Thanks for joining us. With us for this session is Pegasystems. We have Don Schuerman, who has been a long time CTO of Pega. Welcome, Don.

Nice to be here.

We've put out some prepared questions that I'll walk us through, but if anyone in the audience has questions, they can feed them to me through their -- the button in the upper right corner of the screen. Let me just start, Don, for 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. So Pega is in the workflow and decision space. So 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, health care, et cetera. So 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're also used across industries as a workflow platform for things like customer servicing, investigations management, claims management, onboarding, KYC, those kinds of things.

All right. And you've been in your role for a while now, right?

Yes. So I've been around Pega for a little over 25 years. My background is in our support and engineering and then deployment organization. So I spent many years doing, what I think the cool kids today are calling being, a forward-deployed engineer. Back then, it was just a consultant who knew enough to actually write software, what it needed to be written and knew enough people back in product management that if we found things you didn't like, you could get it changed. But -- I did that for many years and about -- probably about 10 or 12 years ago took on the CTO role really in a field-facing capacity. So I spend about 50% of my time with CIOs, CTOs, chief architects at our clients and potential clients, really making sure that we understand their road maps, their architecture patterns where they're going with technology and then making sure that they understand what we're going, and we understand the map between those. And then I spend the other half of my time with my team, which is really focused on go-to-market activities. So everything from brand to sales strategy to activation and corporate comms.

Great. That's great because it's really great to get a touch point into the way the customers are doing right now, particularly around AI. So how is AI significantly impacting your customers in your key verticals, banking, insurance, health care, and so forth. What are the pain points they're trying to figure out?

Well, I think there's one pain point that everybody has, 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 CEOs and boards to just demonstrate that we're using AI, right? And 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, right? We went through -- I thought it was a really interesting bit of whiplash in the market in Q1, Q2, where it seems like literally in a couple of weeks, we went from everybody talking about token maxing and putting up leaderboards of who is using the most AI and celebrating the people who are burning through millions of tokens every week or month to a sudden realization of, wait a second, 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. And so what we really need to do is actually how do we ensure that in the concept of like tokenomics, which is 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. And so I'm seeing in our -- 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. And 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 yes, we all have Copilot and we feel more productive, but actual measurable efficiency gains often measured at the process or the workflow level and 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.

All right. Great. And -- if you look at just the 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 Salesforce?

Yes, yes. So this is an interesting report that came out, right? So Forrester created this -- and this is the first time they've done this, this classification of, what they call, AI platforms. And I think Forrester is drawing a pretty clear distinction between AI platforms and the foundation model providers. And I think that's a really important distinction for -- that I see in the market as well because the push -- the thing that I'm hearing from the clients that I talk to is less and less attention being paid to, kind of, like 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 well 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 to 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 will run a business. And 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? And you can check out the report, it's on our website. I think it's probably the first thing you hit these days if you go to pega.com. But the interesting thing, Forrester said two things on 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? So I think there's almost a, sort of, misunderstood story in the market right now that there's going to be one winner of the AI orchestration or one winner of the AI platform layer at the enterprise. And in my experience and in talking to my clients, that's 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 curate their own flexibility. So Forrester is saying, like, look, you may have a platform like a Palantir that's 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's 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. So 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 3 things. I think we are about to embark on a massive process reengineering wave. I think leaders in business and the ones that I talked to, we were talking to a major U.S. bank about how they're rethinking their complaints process. We're talking to another major U.S. bank around how they're rethinking what's called the KYC, the know your customer process, when you onboard new customers. And what that's really resulting in is massive amounts of process reengineering because the organizations are realizing you can't just drop the AI onto a broken process and expect it to fix it. You actually have to rebuild the process. So we've 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 using -- not using it in the places where I don't need it, where the decision can actually be encoded in the business rules that is pretty deterministic and taken repeatable. So Blueprint and that ability to help lead our clients on that process reengineering 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 create a -- take a bunch of documents, we're going to shove it in the agent. The agent will consume the documents and magically, the agents will just run all the work, right? Well, it turns out that's not going to happen for 2 big reasons: One, agents just have an inherent lack of predictability to them. They're probabilistic being, right? And much of the work, not all, but much of the work in 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 the bank can audit it, so the bank can get economies of scale, so that the bank can actually tell the regulators, they're doing the right thing. So 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 repeatedly 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 make 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'm going 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. So 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. So how many new clients do you onboard? How many complaints do you process? We're able to do that because of how our architecture allows us to execute predictably.

Don, just on that point, if you're -- if I'm running a -- if a bank is running a process like you're -- example you just gave, and you're in the middle of the process and you have to kick off and use an LLM somewhere. So where is that charge coming? Where is the cost of that going to show up for the end customer?

So 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 to say that new complaint. But because the way we use the models and because we're 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're using a 40% to 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's pretty expensive. We want to do that once with Blueprint and then just repeat it again and again and again consistently. So that's how we're able to, sort of, offer this as a per case uplift rather than a running token meter for our clients.

Got it. 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. But 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 the stuff I want to build myself, right? And I think there are 2 big reasons why we're seeing clients continue to look at Pega as a workflow engine even as they can build this. And 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. And I once asked an engineer at Google. "well, why didn't you just build this workflow there yourself?" And his point was, well, that's not Google's unique capability in the market. Building a workflow engine is not we're good at. We're good at network, that search, that ads -- at like -- so I want to focus my engineers on the stuff that actually adds value and differentiates us, not the core componentry. So one, we get that. But 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. And if it's 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 of the business goes up. And 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. So what we're starting to see is clients are coming back and telling us like, 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. So I 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. And so we want to make sure that those business rules that are essential to how these organizations run, sit in a layer that is visual, right? 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 or now with Infinity 26, they can sit and literally ask an AI, but the AI will visually change the process. So they'll actually be able to see and validate the change that the AI made and 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, like that is hugely important for the kinds of work we do for our clients.

Along the same lines, and again, you and I chatted a little earlier about this, but I think it's really important to understand, if you're a customer and you're 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 do I -- am I steeped deeply directly in Pega like I've always been and build my workflows that way.

So I actually think the answer is going to be a little bit of both, right? And 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, right? Or like maybe you're in Germany, you could find a Ferienwohnung, which is like a little traveler's house or something, but mostly stayed in hotels. And then Airbnb and Vrbo and some of these other things popped up. And we had this idea of like being able to get home shares, being able to actually share or take somebody's property over, right? For some use cases, like 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 house and have a kitchen and cook meals. It's like doing an Airbnb is great, right? But I've gone on a business trip down to see some clients in Sao 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 09:00 PM. I want to go to a hotel, 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. Like -- so 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. So that's a long way of saying, in the -- we've added to Pega. And we have the advantage of about 10 years ago, we made the choice to make the architecture headless. So 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 off to a bunch of different front ends, some of which were built for Pega users to use, a lot of like 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 are already given to a certain population of users. So there are a lot of our clients who -- like Salesforce is their user front end, but Pega is the workflow engine behind it. And 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. So 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. So any agent, anywhere can call that workflow. We've actually made the entire development environment of Pega MCP. So 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. So 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, so I'm increasing the speed at which people can build Pega and 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. And I think both at design time for builders like that, but also at run time for end users, there will be a mix. Take like 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 ask them what they need to know to get the complaint started. But eventually, that complaint might be 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 Approved, move on. right? So 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.

As 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 into Infinity 25, the ability of Pega as a workflow to call any other agent via MCP. And 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. So 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.

Is there -- 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?

Like we said, we -- 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, like that's the number we care about. And so 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 value.

That's great. Just want to shift over a little bit to Agentic Process Fabric, which has been out there for a little bit. Maybe just help us understand what you're doing there and why that's important?

So as Forrester, kind of said and as I believe, there is not going to be sort of 1 monolithic architecture inside of our clients. Our clients -- these organizations are pretty sizable. But what that means is they're going to have agents and they're going to have workflows in a bunch of different places, right? So just take my example, when I log in as an employee, there are things that I want to do, there are workflows that live in Pega environments like we run all of our own sales automation. So if I want to update an opportunity or create a new lead, that's a process that runs in Pega on our sales automation, but there are other things that I want to do that are workflows that don't live in Pega, like I might want to -- I need to update my profile in HR or I need to approve time-off request for one of my employees, right? And today, right now, the way I do that is I swiveled chair between a whole bunch of different applications. I walk into a sales app, right, 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. So it makes perfectly sense that I would have an HR app that is separate from my sales app because the team that's going to inform that HR app is going to be different than the team that's going to inform the sales app. It makes perfect sense. But as an end user, I don't want to have to go hunting between those two. So what we've done with the 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 1 place. And 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 is going to say, "Great. I know where that workflow is. Let me go kick it off for you, here's the information I need, it's off and running." So 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.