PegaWorld 2025: Establishing Excellence in Low Code Applications

PegaWorld 2025: Establishing Excellence in Low Code Applications

Hey. Fritz here. Good afternoon and welcome to potentially and I probably it is your last session at PegaWorld. And for that I thank you for coming out here today. So my name is Fritz von Bulow. As I said, I'm a Pega field CTO on a good day, that means Chief Translation Officer, and I have the great privilege of working with many of our largest clients and some forward deployed working with the clients to come up with ideas for how to use Pega in a better, more, more innovative fashion. So that's what I do every day. I have fun doing it. And today's topic is establishing excellence in low code applications.

So if you're here, you might have visited with me two years ago when we gave the earlier version of this talk, which didn't feature anything around Agentic AI. It didn't feature any AI per se. It was a lot more about what could you do from a citizen developer perspective. And you'll notice the word citizen developer is actually not in the title. And I've been told that's because it's a trigger word. And there are a lot of people who as soon as you say citizen developer, they shut down. So we use with some of our clients, the large ones that have these types of solutions and programs in place. We call it low code. And that seems to go over better.

But you know, we can certainly revert to citizen developer at any time. So today we're going to go through a couple of different things. We're going to talk a little bit about the landscape, what things we are seeing out there, what we think is the motivation for doing something like this. And I want to share sort of the accumulated knowledge that I have from a number of engagements with our customers and the driving forces behind them. And at the end of that, we're then going to explore once we sort of put our program in place, you know what's new and exciting in this area? Um, and we're going to talk about that, and then we're going to wrap up with a gentle exploration of what an agentic low code solution might look like. Um, and I have a short demo for that. A video recording, uh, only at this time. But, you know, as we like to say, with Pega, pretty much we can show it to you live.

Um, and if you're interested, we can always come back and visit with you and do just that. So let's talk a little bit about why people are even still today. And even two years ago when we first started these programs with our clients. Um, it came to be right that the automation challenge is one and the same, right? We're talking about the reasoning behind it, which is that there are a couple of things that seem to always have gone wrong. The first of them being that demand for IT services has never, ever slowed down. At the same time, the backlog and the pipeline and the ability for IT teams to actually deliver a project has actually decreased. So if you looked at the studies and surveys that are out there, some from McKinsey Forrester and others, you'll see that what happens is, is that large scale IT projects generally have about a 26% success rate. That doesn't sound very exciting.

You might even get depressed as a former IT person. Certainly the struggle is real, but at the same time we have to find a way forward, right? And so the backlog is increasing. The demands from the business are faster, faster, faster. What I might have been able to do in two years, the expectation is probably that I should be able to now do that in like two weeks or something. That means, though, that we need to strike a balance. And the balance is really this. It's between business and it. I can't wait any longer versus, you know what we kind of need to have some standards.

It's important for us to maintain good order. I don't want to. Developing random applications. I don't want you vibe coding. I want you sort of on the straight and narrow. And then they say, well, wait a minute. Why does everything have to be big? And these are, are, I would say, paraphrased quotes from my own experience. Um, you know that certainly these things happen.

And of course, the last one, uh, on the business side being the most important. Don't look now, we're going to do it anyway. So we know that's going to happen. We have to find a way to meet in the middle and kind of get through some of these other things from an IT perspective and, you know, technical debt, you know, people talk about these things. Um, that's not unique necessarily to any firm, but it is something to consider. And again, you know, that's why people get really scared when when you hear things like citizen developer or, um, the, you know, those kinds of programs and some have actually tried and failed. And the reason for the failure was kind of because they didn't have a real program. They just sort of went and did it. So through a few different engagements with clients, I think there's sort of four things that we want to get around to from a development and citizen developer perspective.

And the first of them is, is I need to pick a platform. We like to think that Pega is an awesome platform. And that was true three years ago when we started working on this with Application Studio, way back when, we were excited about Pega 8.8. These were very possible things to do in the program. The big difference now is that with Blueprint, I can actually make the program even more robust, and we're going to dig into that a little bit more soon here. The second thing you have to have is some sort of strategy for enablement. It's not enough to sort of do random sort of drive by training. Here, have some App Studio, use some Blueprint. You need to get formal about it, and we'll talk a little bit more about that.

But a couple of the key things to think about there is really thinking about that. The training program is aimed at somebody who doesn't necessarily have an IT background, right. They may be super familiar with Excel or they may be super familiar with Microsoft SharePoint. In fact, just yesterday, even at the conference here, I talked to some folks who basically shared that SharePoint had, if not gotten them into trouble, it had gotten them stuck. So we think of those as sort of target rich environments where by applying a Pega approach to it, we we might be able to do better. Then I think the other thing that happens here is in order for this to scale out, you have to think carefully about how you're going to deploy these things. Our most successful clients, who have some sort of low code or citizen developer program are on Pega Cloud. The reason for that is because it takes away all of the normal sort of it setup work. It takes away a bunch of things around how I might build a server, if we're still excited about that in 2025.

And most importantly, it gives us fungibility of resource. So once I'm in Pega Cloud, I'm able to really move fast if I want another instance of Pega if I want another application within an instance, I can do all those things and I can do them in minutes and seconds as opposed to waiting in some other queue. The other thing I'm going to get out of that in this is specific to Pega Cloud is also automated testing pipelines and things. And you probably if you've been to any of the innovation hall things, you will have seen what we can do today from a pipeline perspective with things like Pega deployment Manager and also where we're going with automated testing. And actually, I would say that citizen developed applications because they tend not to be large things like, say, swift payment investigations, they're more easily adaptable to our next generation of automated testing. So some things to think about there. And most importantly then finally you can't get away from setting up any kind of program like this without a solid thought around governance and controls, things like that. Ultimately, also governance is thinking about federation. So one of the things we've seen lately is that rather than having one version of citizen development, I may have 2 or 3, all governed by the same team, but where each of them may have their own deployment patterns, they may have their own instances of Pega so that they can own it, but it's still governed centrally.

We sort of think of that as controlling the enthusiasm so that we don't go completely off the rails. So that's kind of the fourth pillars digging in a little bit more. So when I've done this, I need to now think about what it is I'm going to do from an innovation perspective. And here really I want to just mention a few things that when you look at what happens in the output of these things, and we're going to get into some case studies a little bit later here. But ultimately what I want to do is I want to get to a lower application development cost, right? If I can make these things happen fast, I can get to value faster, even if they're smaller automations. So we've seen a number of teams that have started with small things, maybe a few maker checker like things that you might have thought of as an email chain or something where, you know, it was, do you approve? Yes, I approve. Save it, store it in SharePoint, never to be found again.

And then somebody asks you what happened and you look at your email trail and of course that was archived. And all of a sudden I have a mess. And you know, for those of you who are in regulated industries, the thing that comes after that is an audit failure. And that's typically bad anytime the word audit and failure together. You don't want that. And that's also if you were to look um, broadly, the term for that in a regulated industry is out of control. End user computing. That's really code for I wrote it in Excel, I wrote I delivered the workflow in email and and I now have a mess on my hands. So that's another thing for us to sort of think about.

At the same time, the other thing that comes out of this, if you have a large Pega shop, by allowing citizen developers to do the early work, and maybe the less complicated applications, your professional Pega developers who are probably building more sophisticated solutions and are probably thinking about living in App Studio and doing more complex things, you actually free them up so it becomes a force multiplier that can create many little peg applications, a fleet of them, if you will, and then free up more experienced developers for the heavy lifting. They should also, and we'll get to this in a moment. I have another role that we see with professional developers as we go into these things. All right. The next thing to look at here is what does the program itself look like. Right. So one of the things that is super important here is, is that while we talked about governance, we talked about IT control ultimately successful citizen development programs do a couple of things. They focus first and foremost on that citizen developer. The development experience itself needs to be easy, right?

And so everything you do needs to kind of go along that pattern. When we look at it many times, when you sort of look at the journey of what citizen developer. It really starts from an interest perspective. Am I marketing this internally? Are people aware that this is available to them? Many times some of our clients don't have just Pega as a citizen developer or, you know, that level of of tooling. They may have tools around it for data. They may have tools for robotic process automation, even reporting. So that if you looked at it end to end, I have all those.

And then for workflow automation in the middle I have Pega. So that's another important component is to start thinking about that interest level. The next thing from an introduction perspective. And had I talked about this three years ago, I wouldn't have said Blueprint because it didn't exist. But that has completely changed what we can do from a citizen development perspective. And I'm going to show you that in a moment on another page. But when I look at Blueprint, that is the sort of the easiest way to get people to be introduced to what it might be to go from, shall we say, an unstructured approach to Blueprint development and workflows that you might actually be able to wrap your head around. So that's important too. The next thing after that is what we have.

Um, and we have, you know, there's a whole set of manuals and things that we put out around what we call a low code workshop, where I take the first step, I take those blueprints that may have been created, and I load them in, and I start actually getting people to do the next mile in application development. Because if you know, with Blueprint, I'm going to get the workflows, I'm going to get the orchestration, I'm going to get all those things. What I'm not going to get are necessarily the integrations, and I'm not necessarily going to get deeper rule or decision tables or other things that are common Pega objects. So I want to make sure that people understand how to get to that as well. So that's our introductory thing activation. Again we're going to do Blueprint a thons. We're going to start now. I've been trained a little bit. I'm going to use Blueprint in anger.

So first think of it as a way to learn. Second, think about as a way to actually workshop and make sure that you're actually building an application. The second thing to think about there from an activation perspective is data use. So the data model, and also looking at it from a governance perspective, that when people are allowed to build these applications, that they follow your firm's particular regulations and thoughts and policies around data use. Maybe you don't want PII in there to begin with. Maybe credit card information is not a good thing to put in a low code app developed by people whose full time job isn't necessarily application development. So I want to put some thought around that. I also want to have coaches available. These are people from our professional Pega development teams that may exist with you that I can use as coaches.

They are not there to full time develop the application. They're there to tack and tune it and make sure that what it actually does works. So that's important as well. As we go through the rest of it, you'll see eventually I'm going to get off to my second or second application. I've built confidence. Right. So this sort of I guess it is a little bit of a waterfall. But the notion here, and I could have maybe drawn this as an infinite loop. But the thing the second application really is the next most important thing.

One of the things we found as we surveyed people who started the programs is that when you get to that second application or the refinement of the first that was built, that's when the value really takes off, because there's a natural learning curve to build that first one. And if you've never been exposed to how Pega develops things or you've ever used Application Studio, it's going to be a little tough, right? You're not going to get everything. We have ways to solve for that, but you are going to then on that second application, see velocity and value increase dramatically. So those are some thoughts here just on the framework for your citizen development. Um, that then is backed up by something that's super important for the program. And that's what I call the service palette. There are a number of things that from an IT perspective, you want to do. And these are foundational, right.

So you want to make sure that you have a reuse layer that goes across everything within the low code program. A second thing that we've seen, and this has evolved over time, is the notion of a bootstrap application. I like to think of it as every essential component that you might need, that you can then layer your Blueprint application on top of. Right. So here's how I have objects for UI objects. For example, in Constellation I have one for email internal address lookups. I have integrations to corporate directories. I have, you know, state data and things like that that I want to look up and manage. And those are sort of the lookup authentication components.

I may also have and this has been, you know, a qualification journey for some. But the notion of having things like email services, is it allowed to send email? Is it allowed to use an email bot? So exposing both email bots and things like that as common services in that service palette? Super important because that means the low code developer doesn't have to go and do that itself, right? They don't have to do it themselves. Again, their day job is really not developing things. It's to get things done faster and automate the heck out of it. The next most important thing here is Application Studio.

When we started this 2 or 3 years ago with our clients, there was a lot of what I'd call sort of feature leakage. There were things that I just couldn't do in Application Studio in 8.8 that I can do now that I'm here in Pega 25 or 24. And so keeping the rule that says low code applications, citizen developed applications, start live and end in application studio is a viable strategy today. And that again starts with Blueprint import. We'd like to see everybody use Constellation. We know that doesn't always happen. I think the excuses are fewer now than it might have been two years ago or three. And really then, any complex function is delivered and surfaced as a tile in application studio, even though it may have come from Dev Studio. So that's another technique to use to sort of enable our, our citizen developers.

And then if I think about scaling out, that's all about Pega deployment manager. We talked about Pega Cloud, and this is how I create automated pipelines and solutions that I can actually work on. So that kind of that service palette, that's the job of professionals. But by doing the hard work, once I can get a force multiplier for all the citizen developers to come write some of our clients, they don't have 1 or 2 citizen developers. They have hundreds. So in order to do that, they needed the palette. They needed all those things built for them up front. All right. If I've done all that now, how do I develop and what is development in a low code environment look like in 2025.

And as we talked about this and as I developed this presentation, I went and talked to a number of our existing clients and sort of started to test if this life cycle and this is new, right? It's sort of reimagined with Blueprint first. Would it work? And so there are a couple of things that are different here from where we were before. And it of course starts with that zero friction. The ideate, iterate and preview, ideate, iterate and preview stay sort of set of work, if you will. Um, that is meant to be high velocity, zero friction. Um, one of the things we've done is we've done different Blueprint a thons and things, as we talked about and showed you before, is that when you do this and get a group together, you want to make this super fast, right? So that means I'm not at this stage necessarily using every feature of Blueprint that I could.

So if you're if you hacked at it or played with Blueprint to any great extent, you'll know that I can introduce a YAML file. Well, most business people don't talk YAML, so we try to keep it very. Net and focus on the workflow. First. We may add things around the data model later, but really that iteration what I'm trying to get to is multiple ideas, multiple generations of set of workflows. I could do a couple of things in Blueprint if you're not haven't seen it lately, I can clone a Blueprint, right? So that means I can have version one that will look like this. The Tuesday meeting, we changed a bunch of stuff that was version two and so on, and then the final version. I'm going to then go over into my review area and start getting more IT professionals involved.

So I might have had ten different ideas for how this should be Blueprinted we deleted, we iterated, we deleted the other nine, and we kept that 10th one and passed it into where we're now going to get ready to import it. And here the review step is really where I'm going to start talking about the data model. I'm going to start talking about my integrations. That may be necessary. I'm going to do a sanity check. Um, one of the things that I was talking to one of our team clients about was that at this step, I'm going to sanity check it to make sure that I understand any integration requirements. They may be new because if I have to deliver this thing, but there's an integration missing, I can't get to value until that's done. So I need to sort of do that review step. That is also a good time to sort of think about breaking it apart.

Is this necessarily the full app, or could I do maybe two thirds of it fast and then do a third later? And actually I can map that out and Blueprint I can actually tell you which, you know, which cycle it should go into. And I can tag different workflows for different release cycles within my application. So I could do all of those things. Then I'm going to go in, I'm going to import it, I'm going to go ahead and then launch it for the first time into Application Studio. What's interesting to me is, is that as we've talked to people and we've run Blueprint workshops, is that first thing saves weeks, months, even of work, right? I can do this in a workshop. We've done them both virtually and in person. It saves so much time to get that spec right, so that when I get to that import stage and I'm ready to really run the application, I now have saved a lot of time.

And so now really, my work is not to do what I might have done three years ago, which is I'm going to hack at it in Application Studio quickly. Maybe that's 3 or 4 days and then all of a sudden I can stand it up. I do a review, I do a preview, but then I have to go back and do it again, right? So. So that's really where Blueprint saves us time from a deployment perspective. Once I've launched and built it, I'm really now into Pega Cloud. I'm going to use Deployment Manager. We talked about that. I'm going to look at the testing cycle.

I'm going to start running it. And that's how I get to value right now. Um, we saw this on mainstage yesterday. Right. We're talking about people building a blueprint. and even small applications can be done in a few weeks at most right now. Why do I say weeks when it should be days? Because there is a natural test and release cycle at the end of this. Because from a governance and control perspective, um, we still have to acknowledge reality.

And this is especially true in a regulated industry that I need to make sure that it sort of has that final deployment authority. Um, one of the things that we've learned the hard way, um, and again, this is going to get a lot better with automated testing, uh, is that if I have a cloud instance, um, and one of our clients has a cloud instance with, um, a little over a thousand, uh, application developers and subsequently over 200 live medium sized workflow applications at that level. Um, you have to look a little bit at noisy neighbor kinds of questions. Are these folks doing the right thing with their data, even though I'm every every low code application has private data extents. There is the possibility that somebody writes something that just kind of blows the whole thing up, and we don't want that. So there needs to be some level of performance and quality control at the end of it. And again, we, you know, sort of the quote here with great power comes great responsibility. The thing about that is, um, there are some folks that we've talked to about this who have told me I'm not really comfortable, Fritz, to actually allow people to develop. I'll let them do the Blueprint, but I'm going to then put it in a queue for professional developers.

That anxiety, I think, can be overcome by starting with smaller applications and then building into complexity over time. So that's sort of what we're thinking about from, from the perspective of, of that development lifecycle. So what does this look like in reality? These are blinded. But we've seen a couple of different ways that our clients today are getting value. The first is simple automations. Think of maker checker and these actually predate Blueprint. I think if we were using Blueprint to these, we might not have as many applications because it would be easier to sort of stitch together multiple workflows into one slightly larger app. But we've seen people do 500 plus single automations, single workflows, and they're getting those out and their maker checker, which means somebody made something, somebody reviewed something and we approve it and pass it on.

The business value here is a lot around risk and control, right. Because I need and they're there because somebody found something that was bad. And what I really need to do is just put process around it and get it done fast so I can pass my audit. Almost instant request processing. The tooling here uses a version of the bootstrap application we talked about earlier, which gives you because the the foundation for that is maker checker. So you can enhance it, add a few fields, do a few things, deploy essentially the most beautiful thing in the world, right. Save as if you will a clone that, and then I can deploy it and give it to the folks that are needed. It gives us high levels of consistency, right? Because they all kind of come from that same solution.

And we also able to better manage risk at the more complicated level. And these are developed at one of our other clients. What we're seeing here is beyond maker Checker. These are places where I have, you know, automated a function within a department end to end. So it's more than just, hey, I'm going to send you a thing. I'm going to save an attachment. You're going to review it. We're talking about complicated workflows where more than one person has to be involved. And I'm going to integrate with data sources.

So for example, um, one of the things that we see a lot is exception handling, where somebody, you know, the as is before I automated was there was an Excel spreadsheet with a thousand things and then they were reviewed, filtered, and then they were there was three red check marks out of the thousand, and those were the ones I had to focus on and do something to. I might be repairing a transaction or some other thing like that. Now when we move that to Pega, we asked two hard questions. Well, where did that Excel spreadsheet come from? And it turns out it was actually a database query that somebody saved and was stored in Excel, because you can use the database extension to do that. And so we transform that to a proper data research tool or data integration tool in this case Alteryx. And then we gave Alteryx the power to call that low code application automatically. And so all of a sudden I've actually done a few things right. I've removed Excel.

Like Excel, it's good for things, but we removed Excel as a staging and data device and put it in a more robust data solution that could feed that Pega application. So that's what I mean by more complicated things. That also gets you into multiple data source integration. We've talked about easily 10 to 30 x ROI. So think about this. People are building things in six weeks that could support an entire service line in a business to get out of of manual work. Even bigger division wide automation. So this is probably our shining example from this sort of thing. They started here a department within a firm that manages multiple things.

So think about a service department that manages things. So a very diverse palette right. Things like core HR onboarding, offboarding, real estate security, uh, you know, for real estate, all of these things. Now, you could have or maybe would have thought, well, that should be just a packaged solution. What they found is, is that the incremental benefit of just building this on a foundation of Pega, even though the use cases were diverse, actually accelerated their journey. Um, and that has delivered lots of applications. Some of them were really, really complicated. They're in use by ten, 20, 30, 40,000 people a day, which is remarkable for a citizen developed application. But that's what they've done.

And the result of that has been productivity across that firm. And then ultimately being a force multiplier that the citizen developer, I would say has evolved here in that they've also added, for a whole division's worth, a few expert Pega developers to help essentially 30, 40 other people who are the core, you know, ideators because they're so close to the business. And again, huge ROI here, you know, not quite the same as the other one because those were smaller, more instant automation. This is a little bit less ROI, but still 5 to 10 x of of effort and time to just build something is pretty remarkable. So that leads us to the next frontier. So we talked about all this. And um, as I've talked to our clients about Agentic, you can't escape it. It's probably the next frontier. Um, there's a couple of things that I think we've seen so far.

The first is, is that the prompt is the answer to every question when it comes to agentic. And it's also the thing that carries the greatest risk in terms of what people might actually do with a prompt. And it's okay. Personally, my Friday afternoon prompt is what should a seasonal cocktail be given the weather in Philadelphia. And you know, that's I could make a mistake. Maybe not enough gin or something, but we don't want that in enterprise applications. And we certainly don't want that when we're letting folks kind of make their own path. Right. So there I think the initial N is if you've built a successful Low-code program with citizen developers, the next logical step is to think about how I'm going to build prompts and manage them, and who's going to deliver them.

The way I like to think of this very simply, and you will have seen this if you look at any of our agent Displays even Don's presentation earlier today. I can do a lot with agents. Right. I can have it do ad hoc workflows. Sounds good, and I think we'll probably get there. But the interim step is to look at existing applications. And this is how we're going to start this at one of the firms is we're going to look at existing applications and see where and how in these low code, low code things we could identify them. What that means is we're going to declare an agent to essentially have what I call a job description. If you're a prompt developer, you'd call that the system prompt for the agent.

Then behind that or sort of layer on top of it will be what we would call a task prompt. Do this thing, but do it in the context of the system prompt. It turns out, because we played with this, to see if we could make this work is that the system prompts can be locked down and accessible only by it. So that gives me a good guardrail for how I could actually manage the agents, and then let my citizen developers create the task prompts. Assemble these three sources of data. Do some summations. Declare victory. Or decide to open a case and then kind of work it that way. So what I thought we'd do next here is actually we're going to run a short video here.

So direct from our Pega Agentic labs. Um, here is a my favorite use case. Um, and I'd actually invite all of you as we, we wrap this session up here. Let's talk about what you might think are good agentic use cases. So we're going to hit play here. But this basically here's a low code application. Um, in this case the job of this low code application is to do reconciliation. So this is kind of one of the more common patterns that we see, right. Which is I'm going to get two sources of data.

In this case I have a reference system that I did on the pull down. And I grab the document that was faxed to me or emailed, and I'm going to go ahead and have an agent run here. In this case, what this agent is going to do, the first thing is it's going to get to those two sources of data, extract and find common fact. So I built a prompt to do just that. So there's our facts there between both that PDF you saw attached which had some mortgage data in it. And then also in this case the mortgage data from the system of reference. The next agent, and this is where it gets more interesting is what we call a comparison agent. So here I'm sorry we kind of choked that didn't we. Um, so the comparison agent, let's see if we can get it to play again here.

Um, let me go back one. Let's try it. So the comparison agent allows me with a prompt to say, take these two sets of facts and find the differences. Right. And I did that with a prompt. Is it playing? Here we go. Thanks, Chris. Yeah.

And again so we're just going to replay this piece. But so the idea of the comparison agent is by prompt. I'm simply going to say take these two disparate data sources, compare them, find the differences, and if I know what the differences are, suggest an action. Right. And so I can do that with prompt development. But I'm doing it contained inside my case management solution here. So this if I had thought about it pre agent was probably somebody then taking those different things, putting them on maybe 2 or 3 monitors looking at them left to right, there was a yellow pad in the middle. If you've ever done an operational walkthrough, you'll have seen this, that those things happen. And then suddenly right now, well, here's what I think the difference is.

And I'm going to now continue my case. Right. So here I've replaced that with the agent doing that work. And you'll see at the bottom here as we roll through this it's going to be a little slow right here. It's going to go in and say okay hey the differences I found were there was a difference in the decimal place for the mortgage rate that resulted in a difference in the payment. Do you want me to open a payment fix case? And this is a little hokey, right? Because we we've sort of built this out, and this is why we invite a lot of participation with our clients on this. And you'll see here it's going to ask, do you want to open a case?

And here are the things I think I'm going to forward to the next stage in my workflow. So that's an agentic use. Very, very simple but super powerful. And I could do all of that inside of Application Studio, which is pretty handy. Um, there we go in Application Studio. You'll see here, we're just going to show you a few things. Um, you'll see here, uh, within here is my agents, right within this. I'm now going to go see here in a moment. There's the actual prompt.

Right. So I wrote the prompt. Off it went. This is the first prompt. This is actually the the first gather prompt. Um, and then here is on the right hand side is how I map my fields from what I find. So within my case data, I now have the ability using the intelligent document processing component to map that data in and get get that into the case right So that when I've done that and this is kind of the end of our story here with this, um, but when I've done that first data extraction, it's actually if you're a Pega aficionado, you'll know that that can be put on a data page. That database page is then what I put and give to the compare agent as it's known, source of fact. Right.

And so that again, was a good way for us to sort of step into a genetic processing and then knowing what the prompt was doing, because they're very granular. So it's not one giant prompt that said, hey, let me do ten different things. I'm going to do exactly one. So that we think from a code perspective is is a good level of ambition without going completely out of control. So that sort of concludes today's talk. Um, so what have we talked about. Right. So conclusion for me, low code programs are super essential. The way we can approach them now versus a few years ago has significantly Definitely increased.

You will get to value faster. You certainly have to look at, you know how you're going to use Blueprint in it. Like I said, there's a couple different motions. There's that rapid ideation motion. Then there's the notion of making it a preview that I hand to it. An interesting thing I forgot to mention here is, is that some of our clients have actually said, you know, Blueprint and this isn't about selling it, but it was it was their observation, not mine, that it gave them an artifact that they could use to evidence the development chain, which was way easier and way nicer than a 50 page requirements document or heaven forbid, you know, a Don soapbox is not actually here, but it was BPMN. And so those things from an artifact perspective, have given us a lot more confidence than what's going to get developed by the citizen developer than what would have been done previously might actually succeed. So that's kind of my conclusion on this from the agentic perspective. You can see the elegance of that, I that.

I think, um, very simple use cases constrained upfront. Um, you know, I was talking to, to one of our clients earlier today about this, uh, we think that the, her team that basically does the, the service palette, their next new job is going to be making the system prompts for all of the agents to come. And we think that, again, is is a good sort of distribution of work. And then leave the not so creative but still highly useful agents in the power of the citizen developer. So with that, I'm going to pause here. Um, we've got like seven minutes between us and Alan playing chess. If there are questions, we can talk now. Um, and with that, I thank you for for hanging in here. And, um, questions are the floor is open.

On the left or on the right? Thanks, Fritz. Uh, earlier on in your. Presentation, you had, uh, sort of the differentiation between simple and more complex use cases between generative AI's ability to write reasonably good code and agentic automation now is taking more of a center stage. Do you see that eating into the need for low code and citizen developers? Um. Good question. Uh, um, yeah. Okay.

So so a couple of things on that. Um, so, so I think the if you've played and maybe you have, maybe you haven't if you've seen have you, if anybody's vibe coded here, you can, you can raise your hand. Now I did um so I used lovable. Right. And if you've used something like lovable, you'll know that you can write things really fast. I mean, I created an entire Java app in, I don't know, ten minutes that had a mortgage application front end. I had it at a decision table. Um, it got stuck in. It had a sort of resequence itself at some point.

Um, so it sounds like you could do that, right? Okay, so so let's compare that to what I might do in Application Studio. Well, even with lovable, there isn't really. Unless I have it in the prompt, I'm still just writing more code. I'm not getting to the business model. Right. And so one of the things we think is important is, is that we find a way to model the work first. And I think that's a differentiator for why I might pick Pega as my low code platform. As to saying, well, lovable is now how we do all these things.

The second thing is, is I think I can get into a lot of trouble with lovable really fast, because I'm essentially going to write a bunch of code that I may or may not actually know what does. And so that's going to be a little tricky. On the other hand, it's a good learning experience. I learned a new technique for how to build a decision table in HTML and put an editor on it. That's nice. That actually led me to a different question. It's like, is that copyrighted? Not really sure, but it looked cool, so that was nice. Um, the second question on Agentic I think is equally important, um, that was asked here and that that I think the jury's out on where an agent should start, how they should coordinate, um, and where they might live.

Um, and so our modest proposal here is that they should live inside of workflow. Um, and they're kind of constrained to the things that are, that are non-deterministic, slightly vague. So stare and compare as you saw is an example of that. I could probably model that with in Application Studio, but I might have a much longer chain of decisions. Um, and so it was a good shortcut to develop that as a prompt as opposed to a more elaborate, maybe a case and a sub case and three other things. I was able to do it just in App Studio in a very flat model. So I think that's the advantage there. I think you certainly are going to have agents that are going to run on their own. Um, there will be protocols for that.

Today is not a Process Fabric or a genetic fabric discussion here, but I think that probably is how I do the more complicated things. But that isn't really aimed at a citizen developer doing the work. So thank you. Other questions? If not, here's what I'm going to say. There's three minutes and 42 seconds. If you have no questions, thank you for coming. Thank you for coming to PegaWorld. We hope to see you next year and I'd love to hear your stories.

You can find me on LinkedIn. Um, fairly easy name. There's only one Fritz von Bulow on LinkedIn, I checked. Um, but you can absolutely always ask us a question while I work here in the States. I focus across the world, globally on these things, and so we're always happy to help anybody, uh, on, on this journey. And together, we'll, we'll get success. Thank you.