PegaWorld 2026: Beyond RPA, BPA, and Low Code: Gartner’s BOAT Framework for Unified Enterprise Automation

All right. Hi, everybody. My name is Stephanie Hawkins and I am on the market intelligence team at Pega. And I'm joined today by Saikat Ray, our VP analyst from Gartner who wrote the research on boat. So just out of curiosity, can you throw up your hand if you've heard of boat or know what boat is? Okay, about half and half. Great. I was I was really curious about that. Um, in my day to day on the market intelligence team, I'm reading the analyst research constantly. So not always sure who out there knows or doesn't know of which evaluations. Um, so this year, one of the most significant things to have happened in the enterprise Workflow Automation space is the rise of boat as a formal software category. And, you know, we're very excited about this? This past October, Gartner ran its first Magic Quadrant evaluation for both.

Pega was named a leader out of 20 vendors. And this was really meaningful for us because it really very much describes kind of what Pega has been doing all of these years processing workflows, end to end, cross system, enterprise workflows. So we were very happy and excited to see this category kind of come to life. And I'm so happy to have Saikat here with us. Um, maybe you can start off by giving us a little bit of an explanation of how you came to be the lead analyst on boat. Sure. Absolutely. And thanks for having me. And it's so great to see you all. Uh, first, please let me know if my angle is right here because I'm trying maximum coverage. I know many of you are sitting there. I didn't want to leave you out. Um, so, uh, I actually used to be an automation practitioner.

Um, even before I joined Gartner and this is where I actually learned, like many of you. Like, what are the real customer pain points are? And then at Gartner, my journey started with covering RPA. I used to be the lead author for the RPA Magic Quadrant. From time to time I also cover BPA or Bpm's, low code, no code platforms. And then I also participated into our integration platform as a service platforms. And now Agentic is the new trend, so everyone covers that. You will not find a single analyst who would say no to that. So, but the point that I'm trying to make is while doing this, what I found is that it's not just one technology or just one capability. It's a combination of things. And over time, customers have figured out that they wanted to do more. This is where I have these, um, one of my favorite thing is Star Wars.

And I have these Star Wars analogy, I would say back in the days, like maybe ten years ago, there were the age of the empires, like the bpm's of the world, which was so heavy, which was also like the enterprise architects dream. However, it was a lot more IT centric. And what we got as a result of that was that the destruction of the Empire by the Rpas, which started posing them as the new Jedis. Right. But it was the other extreme. It was a Jedi with not a lightsaber, but a lightweight automation. And what we then actually have and technology is a funny world. And what we saw is that there is a pendulum swing in between and in between our client conversations. We figured that it's not about BPA or it's not about RPA. It's about actually orchestrating your work, your business, your processes, your workflows.

And that is where we found that there is a flavor that's coming back towards process orchestration. And everybody wants to talk about process orchestration. That was my light bulb, light bulb moment, where I thought that we could create this market category where business process orchestration would be cool again. This is what we would call the Empire Strikes Back moment. But that's the beginning of the boat. Now, boat, in short, is a consolidation of capabilities from RPA, BPA, low code, and I would say intelligent document processing in part. And now it's basically you're trying to get one general purpose automation platform to kind of do everything. And that's what we call as a boat, right? Okay. And I know you have a story about how you actually came up with the name boat because it probably could have been called a lot of things. So how did you land on boat?

Oh, that's that's also an interesting story. So, you know, in the analyst world, the toughest thing is to create a market definition and create a name because and I know some of my analyst friends are here and they will vouch for it. We always joke that it's much easier to present to the customers, and it's always the toughest job is to present to a bunch of analysts because you'll get dissected. And that is what also happened with this. And we kind of did a lot of brainstorming that what is the right name for that platform or the market? Because at one end, from the customer end, we found that you are all asking for a platform for automation, which is keeping the trend in line with what's happening in the market. And you're basically asking for all these different capabilities, and you had a disparate amount of different vendors or platforms.

So you wanted to consolidate that. And that was the premise. And on the vendor's end, we are saying that nobody is just doing one standalone product anymore. People started combining things into a broader purpose platform. So that was the moment for both. As I said, but then we tried to find out what this market that we what we call it, because we had Bpm's, we had our PPAs, we had Low-code application platforms and whatnot. And then in our discussion, we found that what is the problem? The problem is we are trying to solve for automation. Okay, so the automation should be there. But what's the core challenge here is that we are solving for not only automation, it's via orchestration. And orchestration was a very powerful word. So we said, okay, let's name it enterprise orchestration platform. And then someone said, wait a minute, because this will be misconstrued as an IT or infrastructure automation or infrastructure orchestration tool.

Then we said, okay, let's do orchestration and automation. Platform. It didn't sound very good as an acronym, so we kind of stopped that. Then we said, well, maybe we should do, we should add business to it because end of the day, it's all about solving the problems for our business. And it's not an IT centric tool. The very basic premise of both was that not to repeat the mistakes of the past bpm's and bring in this whole modern outlook to it. And that's where we said, okay, let's add B to it. And we got a boa Platform it still didn't sound right. So by accident, we got the technology into it and this is how we got both. It was all by accident, not by design. So it was almost boa. Yeah. I think boat is great. Boa with Python would have got it right.

Boat is good though because we have all kinds of, you know, marketing spin offs we can do from that get in the boat and all of these types of things. So it's perfect. We love it. Okay. So can you give us a little bit of a timeline for what was happening prior to boat and then why now? Why is this the moment when consolidation is is really important? So I would say one in the past, one in the present, and more. So I think what is very important for all of you is that what's in the future, right? So I think in the past I said that this is all about consolidation, right? It's not about just replacing any single technology. It's not about replacing RPA or BPA or whatnot. But the point is, what is the center of gravity within your enterprise where you are doing most of your automation?

I think that's where the point started, because the conversation I had in many of our customers, especially after publishing this boat Magic Quadrant, is that how do I consolidate under a platform? Is it feasible? And I think that's what made me think is the real problem here is it's about that all the low value work I'm doing in my organizations, and I'm paying a premium for that because I have disparate vendors or disparate solutions. Can I optimize that within a single platform? It's not possible to just have one universal platform or just one platform, because then that means you're creating vendor lock in, right? Or that means, again, it's going back to this old BPM world. However, what we expected to see is that a common purpose, a general purpose platform where you do most of your automation, which started with low code.

By the way, some of these low code workflow tools did that a little bit of RPA, because if you do not have a whole need of those last mile of integration or screen scraping, you might find the value maybe in a common purpose platform where you do bulk of that RPA instead of buying a standalone RPA tool, then you do some of these intelligent document processing, and then you do some of these low code development, workflow building and whatnot, and all in one platform with the promise that you have a higher degree or superior process orchestration. And that's how I would say that boat has become something different from all these other platforms, by the way. What doesn't kill any of these markets, these markets could still be as a standalone. Although I must be honest, what actually is having an impact on these markets because more and more so the conversations are within our clients is like, I use platform XYZ for my process automation, and I have so many different RPA tools.

I have so many different tools. Now. This is where the future is important. Hear me out. I'll just keep it for the last. And I have so many intelligent document processing tools or some of the other functions which I can perhaps 80% of that, maybe not all consolidate under one platform. Should I do it? And I'm like, yeah, by all means, if that makes sense, if that makes economic sense and architectural sense, um, go for it. And that is the start of the boat. your boat strategy right now. Here's the agentic part of late over the last six months. What I'm saying is very interesting. The conversation has changed. It has changed from these all these traditional orchestration and automation and even RPA to a more modern platform. And this is where I was actually presenting at the summit yesterday, the partner summit. And what I was telling is that boat is continuously and very rapidly becoming the enterprise control plane for AI agents.

And that's really important because we seriously believe that the orchestration and the governance of AI agents, especially multi-vendor AI agents, is a golden opportunity. It's not $1 billion market. It's $1 trillion market, right? It's a huge space. All these concerns around agent proliferation, all these concerns around agent dependencies, or like the mix of deterministic versus non-deterministic processes and how much these agents can hallucinate. Like some of these was highlighted in today's keynote. Um, I think if you have a regulatory mission critical process, would you really allow your agents to hallucinate there? Right. So I think that those are the concerns and primarily both becomes a conduit for that because this is where you would no longer just do one thing. You basically have a greater degree of deterministic process orchestration and workflow management. But you also have all these agent parts where you could subscribe to these patterns, like the reasoning, adaptive reasoning pattern or multi-agent patterns, or all these things that you hear from newer vendors like OpenAI or anthropic or Microsoft or AWS or others.

Right? So that's where I think both is becoming important in a single platform. You get to manage your agents, you get to orchestrate your agents and this becomes the future for your AI agents. So it's kind of a natural evolution of everybody started out with BPM and then added on these tools, added on RPA and all of these other tools, and all of a sudden they have tools all over the place and nothing to orchestrate. So now here we are with this need for this enterprise control plane. Okay. Is there kind of a minimum set of of software applications? You need to be called a boat platform. What do you need to have to qualify and what are kind of some of the nice to haves? That's, that's a great question. I would say that the minimum thing is the oh in the boat and which is orchestration.

Now, of course, orchestration means a number of things to a number of people. What does orchestration really mean? Right. And in this context, I would say it's very much process orchestration. But of late we are bringing the topic of agent orchestration. And these two are kind of relatively different things. So in essence, like the bare minimum functions that we want to see in both is absolutely process orchestration. The breadth and also to some extent, the depth in process orchestration where you could be reliable, a platform which is for durable execution, where when you start a process, you finish it, right. You can manage the state. You can manage long running processes such as case management or complex processes straight through processing. You can also orchestrate your endpoints. And you might say, well, that sounds like microservices orchestrator. Well not really. This is where we are now talking about the endpoints, as in your tools and agents, right within a part of a process.

And so event driven, I think is very important. So orchestration is just a big part of it. Here comes the second part. And this is something that we kind of deprioritized last year, but this has actually gone up in the charts this year. Is that whole agent management. Now, you would have noticed that I have not talked about agent building because we believe agent building is becoming table stakes in many software platforms. So what's so special about that? In a boat, you might land up in agent building by purchasing any software platform in the world right now ERP, CRM, your ITSM, or others everywhere, you will find these agent building things or agent testing, but where both takes a front seat. Among all these is that both would actually put a lot of focus on orchestrating your deterministic processes, or even some of these could be non-deterministic.

And underneath that, you would have a special capability to manage all these agents that could be a part of that process, which means you are defining the goals of your agent under the boundaries of that process design, right? So that's very important. Some of these things you have seen with Blueprint or Other Other area. Now, you would have heard a lot of names like Control Tower, agent 365 or some of these other products, um, which are very much into this realm of agent governance. We think that is becoming a capability or mandatory capability within any board platform. So if I consider Pega as a boat or ServiceNow as a boat or Microsoft as a boat, the bare minimum or mandatory thing, would that need to be that ability to manage all these multi-vendor agents, ability to manage agent states, ability to manage agent registries, and of course, the tokens, right.

We talked about that in the morning today. So I think that's, um, some of the capabilities and then of course enterprise connectivity. Now, enterprise connectivity also is a conflated word. It embeds so many different things. I think APIs are in the mix of things. API connectivity. I do not mean ipus by any means, because Ipus is much more deep than a boat. Many people do mistake boat as a convergence of all these technologies. I would say boat is a consolidation of these technologies a little bit different. So it is API connectivity just within the context of your automation. Nothing else. I'm not talking about eddies. I'm not talking about ftps. I'm not talking about all these other things that are ipus Platform could do. And of course, RPA, the legacy last mile automation, but that is getting significantly displaced by computer use agents, especially after Cloud and open AI operator and whatnot.

And then last but not least, the general platform operations, which makes for the enterprise grade or enterprise worthiness within any software platform that you purchase. So I think that combination, it's actually a lot of ask, but that is a bare minimum for a boat. And that's why you see this market is very competitive. But at the end of the day, the list is very selective, right? Because you, you looked at the wide list of vendors and you narrowed it down to 20. You actually met this criteria. Yeah. Um, okay. So on the topic of orchestration, I am curious, where did the vendors that you looked at for this evaluation? What were their kind of struggles or where were their strengths with orchestration? Because it's a hard thing to do. Well, right? Yeah. So this is where I'll tell you two stories, right? One, um, so we evaluated a whole bunch of vendors, right?

And we got almost more than 100 plus vendors in this board market. And everybody wanted to be a board when we announced it, which was what we were so proud of. But at the same time, the challenging task that I cannot write about 100 plus vendors. I have to write only about 20 vendors. And how do we create that list? What we found is, as in the orchestration, as we. I was emphasizing that what we find is that, yes, let's focus on real quality of orchestration in a sense that orchestration is not only just about managing your processes, it's also about. There are two components to it design time and execution time. What we found is that when we brought all these different types of vendors within both, because there are a few Ipaas vendors like Boomi and there are a few RPA vendors, there are a few local vendors.

We found there is some degree of difference in the orchestration capabilities, so you could run workflows very well if you're on Ipus, but you may not design it that well. On the other hand, if you are coming from an rpy and low code heritage, you are very good at designing things because you already would have figured that out. You have all these visual interfaces, but not very good at execution. And this is where durable execution of long running processes was one of our benchmarks that actually helped us to narrow down the field even more. So, um, we actually had some conversations with OpenAI and anthropic and whether they could be a boat. And I would not have imagined that like a year ago or two years ago that I would consider them as a boat. But both of them told me that they would not meet those criteria, like the criteria of long running process flows or actually managing workflows to that extent.

Um, so I think that that was an interesting aspect for me. That is really interesting. So it's really about the sort of long running processes, the ability to hold state over time. Um. Now, I'm sorry to interrupt, but it's just one aspect of it. Our inclusion criteria are much broader than that. There are of course, there are like a lot of vendor performance criteria like you need to be within certain revenue threshold, growth, market momentum and stuff like that. So that also kind of influenced our discussion. But I would say that capability wise, this was one of our primary point. Okay. And this for this particular evaluation, you were looking at the ability to orchestrate processes and agents. And I know we talked earlier and you said in the future it's going to lean more heavily into multi-agent orchestration and abilities to do that. Like one question that we asked where we really see a difference in answers is, can you manage third party agent registries?

And this is where things get very interesting. Many known platforms that say no. And of course, there are also a few startups who said yes. So that's why we find it very. I'm not at the liberty to expose that because right now I'm in the part of another evaluation that would be a complete violation of policy. But. So I won't get you in trouble. Um, okay, so for those Gartner customers who are saying I want a boat Platform, I think I need a boat. Platform. First of all, what percentage would you say of. Gartner. Customers are kind of, you know, looking at a boat. Platform. Yeah. So I think the conversation with Gartner customers are driven from a couple of aspects. First of all, I was glad to see that a lot of large enterprise customers that we have, like very strategic customers, they kind of recognize boats.

So that was a great name recognition for boat. There was like one big Healthcare customer on one top banking customers, both of them, they're almost like among top five. And they both have their boat strategy and name strategy, which is so glad to see that. I think the primary conversations is not around how do I buy new products? The primary conversation, I'd be very honest with both is how do I rationalize my existing landscape? This is where I found that customers already would have owned at least more than 3 to 5 boats within their application landscape, or maybe more by virtue of having an ERP, a CRM, an ITSM and office product, or many other things. And what they are trying to figure out is what's going to be the next vendor neutral enterprise control plane for AI agents. That is the primary discussion that is driving that boat selection criteria, because that's where they also want to do some of their workflow management and process automation and whatnot.

And my advice to them is if that vendor is not coming from an automation heritage, they might struggle in that boat area, right? So I think that is where it's very important to have an automation heritage, because automation vendors over time actually have built these capabilities and the depth and breadth into it. But one thing I would say both at the end of the day is still not a depth Platform it's a breadth Platform so you're using it to minimize your applications and vendor footprint. But if you really need the depth of solutions, you will still go for those standalone things, right? So that makes sense. So if you need a extremely deep, for example, process intelligence platform, you may use a standalone for. That or RPA for that matter, or IDP for that matter. But if you think 80% of your ERP or IDP problem could be solved by your boat, that you are where you are doing your workflow management, then why not, right?

Okay. And what, what are the kind of the core use cases for both? What, what processes do these clients want to automate with a boat platform? Right. Right before that, I just want to make a comment that I hope I'm not killing the RPA market right here. So I would say that one of the primary use cases is, um, and this is where boat really differentiates from any low code tool or RPA tool, or even Ipaas tool is the long running process flows, right? This is where typical case management things, right. Underwriting loan originations. Um, so this is where we are extremely proud to actually host a bake off session last week. We did it with three major vendors on stage who are showing their capabilities. So we kind of added a little bit of twist to it. We said, okay, show your boat, but for the Atlantic world.

And we gave them a scenario, this is like Bank X, Y, Z, who wants to do their loan origination process. And the vendors were Pega and Appian and UiPath on stage, side by side. And then we asked audience to pull it. Right. So so it was really interesting. I was the game show host there. So but but end of the day, I think the point is underwriting all these long running process flows. There could be shorter tasks. As I said, you are automating or otherwise you are automating using an RPA. You could do it using both. Um, and then there are like newer agentic tasks like knowledge agents and all these different things. Now you could use both to do that, right? What you would see is that boat is actually graduating into something that it was not there a year ago, which is really, really impressive.

And that's what I have seen in that Bake Off where I think you Pega was showing like a lot of AI enabled capabilities within that, or even leveraging an agent to do that, or natural language interfaces, I think Clis are becoming very important. So for example, all these wipe coding or CLI interfaces like Cloud code open Cloud or whatsoever that you're hearing, they are becoming a common part of any automation platforms. There is no differentiation, by the way. I would say the differentiation would be in how you use that to build your workflow or how you're contextualizing that to make decisions within your cases or other places, right? So I think all these use cases would be valid and I would say banking, finance, insurance, healthcare, any automation use cases in general that you could think of would be applicable for both. But ever more so the long running use cases and the reasoning pattern use cases that I'm talking about the agent and whatnot.

Okay. What about highly regulated? Did that. Of course. Yeah. So. Um, so let me also tell you another story. This is like when I was trying to do this board market, I had several conversations with some of our clients, Goldman Sachs, fidelity, Bank of America, all of them are highly regulated industries. And the conversations we had is it's not only just about process orchestration or the fancy with the really sophisticated technology, it's about really establishing that where your regulatory points and guardrails are. And that is where the design time capabilities are so important, but along with the runtime, you cannot just discount one versus another. And that is when also I asked them, so this is where we also did a survey with our clients that would you like in a Platform the perfect combination of the design, time and runtime. And now with some things working and they say, yes, absolutely.

And I'm like, okay, so we have an idea about both. And I just did some really early a B testing with our clients and they said, no, yes, this is a great idea. Let's go with that. Right. So that's really interesting. So when you were evaluating all these vendors, was there a way in which you judged or graded them on the ability to actually execute, on being able to manage long running processes, highly regulated processes? How did you determine that they could do it? It's about the benchmark. So we all ask the questions to all these vendors, like how many number of steps can you execute in a truly enterprise process? Define the scale. Like how big is this? Or, um, what level of load that you can handle, right? So all these different things kind of determine that. What's the quality of orchestration that's there?

We also see the quality in terms of like what in terms of complexity that you can handle the Uber complex versus like moderate. You will find most of the products land in that moderate complexity. Although at boat, we never tried to solve for those Uber complex things, but it's nice to see if a platform can do it right. So okay, interesting. And what I know you talked a little bit about Agentic, but clearly that's going to play a much bigger role in boat moving forward. Do you want to talk any more about kind of how that's going to play out? Yeah. So right now, um, just what when you look into the Atlantic, you'll see there are so many different patterns that are floating in. Right. So supervisory, hierarchical reasoning, planning, all those different types of patterns and la lack of standardized patterns. What I did is I kind of highlighted that there are three patterns that might be useful for all of our customers in the Atlantic world.

The first one is our deterministic workflow pattern where your agents are participating. The second one is a reasoning pattern where you have these loops or iterative loops, where you have a plan, reason, act, then kind of validate, decide, and again, kind of refine those types of loops until you get your perfect response. It's no longer just a prompt driven approach. It's a context driven approach, right? So so that's the type of pattern that we see. And the third pattern, which is a little bit futuristic yet is the multi-agent pattern, right? So we see all these three patterns. And going back with this, I think that both will kind of subscribe to all three. And both will kind of support by and large both comes from the deterministic world. Most of these both players, but they would be able to support the reasoning pattern and the multi-agent pattern.

And hence they that's, that's exactly where I say they have a front seat. And this whole agent management and agent orchestration discussion, right? So, so whenever you're thinking of how do I manage all my multi-vendor agents into a platform, think of a bot platform first, because this is where your process realities are. And you cannot just execute agents in silo. You have to anchor or chain them as part of a common business processes. And that's where you get your values right now, of course, you could do a little bit of governance somewhere else because that's where your maybe your, you have a distributed or fractured ecosystem. But by and large, for your enterprise processes, your enterprise workflows, or even when there is a bigger context or an automation, um, especially with these agents, you need to kind of define that within that control plane. So both by and large becomes the control plane.

Again, I'm coming back to this discussions because I believe we are defining both more to be a control plane for our agent for the future. Um, and becoming that whole universal orchestrator where it can orchestrate anything within a platform. So in your eyes, I know you can't, you don't have a crystal ball, but how do you think this will play out with real companies? Well, they have one boat platform for over the entire company. Will they have multiple boat platforms in different areas of the business? Um, so this is like any software market. I think it would be absolutely impossible, especially if you are such a large complex enterprise to land in one boat. So you could probably would land up in at least 2 or 3 boats, strategic boats, depending on your enterprise application proximity. This is where we at Gartner, we call something as a base layer.

And now we are calling it as an AR framework. So the AR, the A stands for the system of action. I stand for the system of intelligence, and the R stands for the system of record. And if you think all your processes are originating in system of record, let's say it's an ERP or CRM, then you're going for an ERP or CRM centric boat. But if you think that your actions or your intelligence layer is more important, maybe you have a boat at each one of these layers, or you could have just one universal board covering everything. This is a client choice, by the way. Um, so I definitely see there could be multiple boats playing in, but also for midsize or smaller customers, there could be just a single boat because they want to consolidate things. And then so these boats will have to talk to each other.

Will there be one orchestrator above all the boats, or will there be multiple. No, I think MCP or A to A or whatever, like interoperability standards that we're establishing moving forward and APIs that are going to be the common de facto standard for that. So definitely you don't need an orchestrator or orchestrator. In fact, that would be heavily discouraged because again, you are kind of creating some lock in there, right? Or monolith. Okay. So among the vendors, maybe not even among the vendors you looked at, but in general in the market, what kind of what's the hardest thing to do? Well, when it comes to a boat platform? And what kind of separates the leaders from the rest? You mean from a vendor standpoint? Mhm. Um, so, so many different things, right. Um, I think from a, so if you are talking about any market report, the market report is made with a vendor's performance and the product performance.

Let me focus on the product performance. Now I think product wise. It depends on that, how resilient your platform is. How do you handle errors or alerts? Now, it might sound very trivial to many of you, but trust me, that is where you will also see some difference in quality, especially when you are dealing with enterprise grade projects. I have heard so many places where, oh, it's so easy to build an agent. Yes it does. But then when you try to deploy that agent, there is this whole token implications. And when you try to scale it, it breaks in production, right? So that is where the big thing is, right? So so in order to be a very good boat, you have to have a very robust, scalable product, a product that doesn't break often. Every product breaks at certain times, but here it doesn't break that often.

And number two is the breadth of capabilities. So I think the breadth of capabilities is very important because this is where you are just good at one thing, but maybe you are okay at other things, but you are not best in class in other things, which is possible. But by and large, who has most of these functions as native capabilities and not like fractured? So I think that's also very important, right? And that reminds me of the third point, which is like how integrated that board platform is. Because if I asked you to. I am the single vendor. But if I asked you to build your agents here, manage your agents here, run the security here, then do your process orchestration here, and then basically your design here. It's no fun because now you're assembling all these different tools from the same vendor. It seems like 4 or 5 different products if it is integrated well together.

Yes. You run the risk of a monolith. Yes, you run the risk of a lock in, but that's a lower risk compared to many of these things you are doing if this is economically viable. Again, it's not a one size fits all model, you might see that different customers might have different strategy. And that's where I would say both may not be for everybody. But is there is a span where there are certain sweet spots for both. Also, that's really interesting. Yeah, I can definitely see the difference between a company that's had a lot of acquisitions. And so everything's not as tightly integrated versus a company that's built a lot of things natively. Yeah. Um. Also there is a build versus buy, um, angle to it, right? So if you're so much into building an open source, you might not favor a boat. But if you're more into packaged software platform, that's where you'd like a boat.

Okay. Right. That makes perfect sense. Well, I think this has been a really helpful conversation. Um, I'm very excited about the, the next boat evaluation and where it's going. And I really appreciate you being here with us today. I'm happy to open it up for questions if anybody has anything they'd like to ask. I cat You can feel free to just go up to the mics. Sure. When did this framework came into the picture? When did you start? Yeah. Um, so the question is that when did I start this bot framework? I would say I started it almost like three, four years ago. But then my first research that I published was two years ago, which is when I started with this whole concept of boat. When we saw that we got some market traction and we did a couple of survey vendor survey and customer survey, because we didn't want to just throw a term into all the customers and say, oh, you have to take this.

Um, we wanted to understand that what is the resonance in the market with that? And then we found some good results. In fact, 82% of our customers said that we want some consolidation within that sample that we did. I think it was a fair sized sample. We did that with our peer inside group, and that's when we decided to do a market or a market report or a magic quadrant for our boat, which was published last year, and we are doing one this year. Which client is the largest adopter for boat? Yeah. I cannot publicly name the client, but I would say it's primarily from banking industries. Healthcare. Insurance. Yeah. If there are no other questions, we can give you all a little time back before your next session. Thank you very much, everyone. Yes. Thank you all.