How to Make AI Practical in M&A

This episode is brought to you by Firmroom. Searching for a data room that offers simplicity without compromise? Elevate your data room experience with Firm Room, the world's most intuitive virtual data room. Try it free for 14 days, no strings attached. And when you're ready to power up, sign up for unlimited users and 10 gigs of storage at a flat rate of 4495 bucks a month. Boost your team with Firm Room, a tool built by deal makers for deal makers. Check it out firmroom.com Again, that's firmroom.com I'm Kisam Patel and you're listening to M and A Science where we talk with deal professionals and learn valuable lessons from their experience. This podcast focuses on stories, strategies and what actually happened during M and A deals.

Hello M and A Scientists.

Welcome to the M and A Science Podcast where we learn from the best in M and A to uncover proven techniques for enterprise value creation. If you're interested in learning more about how to optimize your M and A practice, or want to get involved with our community of forward thinking M and a practitioners, visit mascience.com and subscribe to our free weekly newsletter for the latest in industry trends, insightful content and community events. If you want to keep up with us on the go, head over to LinkedIn and follow M and A Science.

I gathered up some of the top AI pros here at Boomy World to break down AI into practical use cases since also is going to give you a sneak peek about the AI M&A teardown series. If you're not familiar with this new series that I'm working on to really get past all the hype out there and just show you real use cases of using AI. Hope you enjoy this mini interview. Joining me is Michael Bachman, Head of Research Architecture and AI Strategy at BOOMI and Chris Cappetta, Principal Solutions Architect, also at boomi. Gentlemen, thanks for taking a little time to chat more of some nitty gritty about all this emerging stuff, all this chatter about AI. I want some real answers because it's too much hype and a lot of talking heads and some of them I really don't think they know what they're talking about. But you guys do became referred as some credible experts.

We hope so. Looking forward to it.

I know it's a little awkward. We got one mic to share since impromptu interview if you want to do just a real brief intro on your.

Background started Boomi in 2017. I actually came into sales engineering. I was working on the BOOMI workflow Product sort of an application development sort of thing. And ventured into the integration area and found myself in product working on skunkworks AI stuff. So it's been a really enjoyable time to be down the rabbit hole.

Yeah. And I came into Boomi in 2018 just a year after Chris did. But I have a background in memory systems, storage and storage engineering, pre sales as well as linguistics.

Great.

Let's talk about making AI practical.

There is a lot of hype. You were talking about that before. And what we want to do is turn the hype into reality. So we have the pleasure of doing that on a daily basis. Especially you, I would say. He calls himself Head button pusher because he's constantly on keyboards trying to make sure that stuff works or tries to break it. Making AI practical really means to understand what goals are and then to also orchestrate how we're gonna make LLMs work for customers in a variety of different ways, such as rag, fine tuning, any type of agent, building, that sort of thing. That's what we do day to day.

Cool. Yeah. I'd add to that that the models are pretty impressive as they are, but they can be made more impressive with the right logic and sequencing and steps and extra data. And so all of that sort of stuff is where BOOMI has really found itself in a phenomenal position, sort of contrasted with AI functionality in the platform. We do a lot of AI designing using the platform. So we have a platform that already does data connectivity and orchestration and logic and data transformation, all of those sorts of things that can help an AI model be better. The AI models are really just another point in a potentially 50 step process for us. So it lets us build out a lot of pretty creative designs quickly that include AI, but that also include connectivity and mapping and all of those sorts of other things. So it's been a really enjoyable thing to explore.

You mentioned three areas to really make this dialed in to be useful. Rag Fine Tuning Agents. Let's break them down.

Sure.

What does RAG even stand for?

So RAG is Retrieval Augmented Generation. It's basically. I like to think of it as a particular use case. If you ask ChatGPT to summarize something in your salesforce. Org, it'll say, I have no access to your salesforce. Org, but you can take that extra step and you can retrieve the right information or relevant information. Even if it's a big ugly 30 page string of notes, you can feed that to one of these models and then ask your question and it'll respond better. So all of that can happen programmatically. That's the concept of retrieval augmented generation. You're basically able to help the models respond better by getting information that maybe it doesn't have access to or is maybe outside its training window, or maybe it just didn't even focus on it when the vendor was creating that model. But by getting the right information, even if it's big and ugly, included in the prompt, the LLM can do what it excels at, which is understanding the user's question and parsing through a massive amount of information and using that, if relevant, to respond to the user's questions. You're kind of letting the large language model understand what the user wants and you're giving it enough info to respond better than the model could by itself.

I feel like there's a lot of misconceptions about AI where people just think we do have an A. So the big use case, always the data room. The data room, when you're doing a transaction's got hundreds if not thousands of documents and everybody's like, oh, we'll just slap AI on top of it. And you can wait a minute. There's some challenges with doing that. You can't just stuff thousands of documents that could be hundreds of pages long and expect it to really digest that information. Maybe we can sort of hash that out a little bit more of like why that is the limiter. And then I think there's rag in concept versus rag in reality. And it seems like it's in an evolving state.

Yeah, definitely. So the context window, the amount of sort of words that you can feed into an LLM, it's growing super fast and that's really impressive. It used to be even 10 months or so ago, if I were talking to even the earlier versions of GPT4, I would probably ask it 10 or so questions and then it would lose the plot and I would start a new conversation and pick up where we left off. But now you're really at the point you can have a many hour technical conversation with it and it'll track, it'll maybe get a bit slower, it'll think a bit harder because it's gotta read through a lot of stuff, but it'll still follow and it won't just go off the rails. So it's really handling a lot more context really well. But that's on the scale of one few hour conversation. If you're looking at a whole documentation set or all of Wikipedia or something like that, you're still way outside what it can do. And also it seems like Some of even these top models that can handle massive amounts of context, they can handle them technically, but they can't handle them well. For example, if you look at like a Google Gemini million token context window or what have you, I've seen some people do tests. I haven't done these myself, but I've seen people do tests where they say they've hidden an Easter egg somewhere in this massive amount of context. They ask it about it and it says, oh no, I don't think it's in there. And then they say, no, I'm pretty, it's in there. Look again. It's like, nah, I don't think it's in there. And then the third time, maybe they'll say, I'm certain that it's in there, find it. And they'll say, it'll say, oh yeah, it's totally there. I see it now. You can feed it all of this context, but it might not pay attention all that well to all of the context. That's the sort of limitation of the context windows. I think those will get much bigger and much more reliable in the time to come. But for now it's better to give a smaller amount, a relatively smaller amount of accurate context. I'd rather give it three pages of really good context versus 100 pages of context where a couple paragraphs are useful.

So, yeah, when we're talking about a deal room for M and A, you've got multiple parties in there. You've got the lawyers, you've got the printer, you've got the parties that are buying or selling. They're all going to be looking at contracts as an example. One way that rag could be super useful is summarizing what's in some of those contracts, especially if they're super lengthy, which in M and A they absolutely can be. If you have a small context window, that's not going to help. Also, if you don't have the details that exist in some of these contracts, you're going to need to augment this linguistic model, which is an LLM or a language model of any size or kind. The idea with the deal room, to make that more efficient, just to use your example, in M and A, having RAG in conjunction with an LLM is critical. Now you can get into the business of seeing what's relevant in those particular documents, how those documents are going to be validated along the way, and lots of other information that's only going to be isolated to the deal room itself. If you just let the language model operate in the deal room, first of all, you may not get the outcome that you want, primarily because those models have only been trained on public data at this point and not on specifics of what's going on in your deal room. Although they'll still give an answer. That answer will sound really good, but it's going to be factually inaccurate to a greater degree for much of probably what a deal inside of that deal desk would require or that deal room would require.

I guess like the biggest concern is current state is inaccuracy because that's the last thing you want. An M and A is rely on it and then it's giving you inaccurate information or missing some of those points. You may be trying to dig into 100%.

Two ways that I'm thinking about it. One is summarization. That's going to help all of the parties understand what's in the documents. Two is mapping. So the idea of understanding how one document or one process could map to another even in the deal room itself, that could be critical. I'm no expert on deal rooms and what goes on there. I have dealt with some of that in the past. What I can say is that language models are really good at reading in text and responding to IT rags just make that whole process a lot more efficient.

How do you define this sweet spot? The reference I've heard before is taking unstructured data and structuring it. I don't know if you have other references to give a good perspective on how LLMs are most useful.

Yeah, so they're useful in a lot of ways. The nice thing about LLMs to your point is they are dealing with unstructured data. And the unstructured data represents 80 to 90% of all data that's created. Yet it also represents a problem that's been largely unsolved heretofore. If I can rely on an LLM to provide some sort of structured feedback based on unstructured data, that's really cool. And so what I often say is the nice thing about LLM technology is this. Before LLMs and with structured data, traditional machine learning or discriminative machine learning could be applied. But it forced the human to sort of think like a logical computation system. For instance, a SQL statement is not a natural language thing that we would do in communication. You don't say select star from this table where this condition is met, do these things and return these things. That is very much a structured data return. Instead, I want to ask in plain human language of any kind to the LLM to go and Provide that retrieval for me. What the LLM is doing is it's offloading the thinking in air quotes to the actual model itself. Now I as the human don't need to think like a computer. The computation system is emulating human like thinking for me.

And I think yours is well said. LLMs really excel at handling the grunt work. I think you still generally want a human in the loop, but if an LLM can make a human's process 80% faster and better, that's a huge win. So I think LLMs can handle the grunt work and I think that can be both from the perspective of summarization and aggregation. It can also be sort of a companion, a conversation to help you work through an idea. So often at this point, if I want to learn something, I no longer go to Google. I fundamentally have changed the way I interact with information. I'll start a conversation with an LLM, I'll get some info from it, then we can have back and forth dialogue. I can get to the idea or the end result that I was looking for more effectively than just throwing Google searches up against the wall and hoping someone has both done what I'm trying to understand and happened to write it somewhere that I'll stub my toe on it. It's a different way to engage with information. And in that way I'm able to have some, I find pretty productive dialogues with LLMs to work through different ideas and concepts and designs and all of that sort of stuff.

So true. I got a flower to meet our engineers next week and they want me to do a workshop on just teaching them sourcing through value realization. M and A. I'm like, whoa, that's a lot. I threw it in chat, got an outline, gave it some feedback, like we need to expand this area. And it's just. That's all I needed was just to have that little conversation. Totally agree. Now, we referenced discriminative versus generative and it sounds like discriminative was the prior iteration of AI. That's still pretty quantitative in nature that you're getting some technical components, you know, some rules that you got to really define for it to get value versus generative is more qualitative. We reference the conversation and it's. I think that's what's bringing it to being more of a breakthrough thing that everybody's referencing.

You're definitely on it. No, discriminative is probably the better way to call classical or traditional machine learning. A lot of our colleagues, especially in this very incipient phase of generative AI being launched wholesale through ChatGPT, coming into the zeitgeist, all of that stuff. It's like we referred to traditional ML as what I now call discriminative, or what the industry or what data scientists have called discriminative forever. So the idea is one is basically very quantitative and focused on structured or semi structured types of data, and the other one is generative, which is not only filtering out information, but it's also generating new information as well. So mathematically one is just taking from a set of data a subset of potential responses. The other one is doing that and also generating new responses as a result. And that is great for unstructured data. So you're right on the money there.

So I'm actually going to say some things and I'm interested in your take on whether I'm understanding discriminative AI correctly. I would think of discriminative AI as often used in classification. So you would train a model specifically to do something like recognize the sentiment of an Amazon review or something like that. I would think of that as saying this is a positive or it's a negative. It's an either or it falls into these buckets. And I would think of that as how most traditional machine learning models functioned. The large language models are doing a lot more. They're trained on so much information that they can in really interesting ways do a lot of those things quite well without sort of purpose specific training for that. So I can, with a large language model, give really good instructions to say, I don't want you to answer this question, I want you to classify the sentiment of this. So in that way, the large language models are kind of a fascinating leap up in that they can do a lot of the things that a discriminative model could have done, but they didn't require purpose built training for that. They just know so much that they're able to handle it.

And again, like I said before, it's like you filter out data and then you generate new data. So classification techniques would definitely use that and be useful even in generative models. I'll also say you talked about classifiers or classification in general. Clustering, classification, regression, prediction, prescription. Those are the elements that I would say are really in the domain of discriminative AI. Those can still be used by generative models and indeed are because you are predicting the next token that's going to appear. So there are these embodiments of discriminative modeling inside of generative models, but really generative models are Using different types of technology, like transformers are completely different than even classifiers were and that sort of thing. But the idea between these things used in tandem is really where I think the value is going to be. You use quantitative and qualitative methods, you use structured and unstructured data together, and you bring these models together in such a way that they can be used as ensembles. And with that you create pipelines of better and better outcomes. And this is why it's important to fine tune, to have rag, to have agents that are purpose built to fetch certain data or perform certain functions and then feed that back into what these models will ultimately do to lead to an outcome. But I agree with exactly what you said too.

Let's talk about fine tuning. What the hell is fine tuning?

Yeah, so fine tuning, it could be differentiated from pre training. Pre training is when you give it basically the Internet and you tell it. Here's how you predict the next word. Fine tuning is when, in the sense of a big model, they're making it so that it responds to questions instead of thinking it needs to generate a follow on question, that sort of thing. From the perspective of me as a builder, I find that the fine tuning I'm able to do generally happens. I don't have the compute to do pre training myself. So I'm able to basically take a model and I could do fine tuning to turn it into a discriminative piece of functionality. I could do some fine tuning to say I want to have the Llama 3 model do some classification or some routing or something like that. But for the most part, in my experience, fine tuning is best today at modifying the tone of how a model responds, not overriding the facts of the underlying model. So I would also actually add prompting into this. I would think of using good prompting and instructions to have the model do what I want it to do. I would think of good retrieval as having the model know what I want it to know. And I would think of fine tuning as having the model sound how I want it to sound. And I kind of use those in different ways. I would say fine tuning for me today, not actually that useful. There are definitely really impressive fine tuning things that are going on on the scale of like an OpenAI or an anthropic or something like that. They're doing probably, I would imagine, hundreds of sequences of different types of fine tuning for security and for answering and for reasoning and for all sorts of things. But on the scale of what I can do to just take an open model, fine tune it myself, Yeah, I think fine tuning can modify the tone, but I think if I want the model to know different things, I'm going to retrieval 100% of the time. And I'm just having the vanilla model be given much more information and context in the prompt rather than trying to override the underlying facts of the model by fine tuning it.

I love that answer on so many levels. The only thing I would add to that is I think there's a trade off at some point where you're going to do retrieval and then fine tuning. And one of those areas could be very domain specific responses like you were saying before, you take a fine tuned model and that's going to be what you say on the tone. If you want your tone to sound a lot like an auditor, then maybe you have a model that you're fine tuning on auditing type of language in nomenclature, basically giving it a corpus of data that is commensurate with the type of actor who would do the performance of an auditor. As an example, you may come out with a way where you use both. Maybe you don't want to use the LLM, the big linguistic model to answer routine questions that only an auditor would repeatedly ask. Under certain circumstances, maybe that's a good time for a fine tuned model to come in and retrieve the right data in the process.

So it sounds like you're like pre prompting. I'll use an example using Deal Room here again because it's the one I'm most familiar with. But we have our AI platform that we build on top of whatever learning large language module they're using. But we'll have instructions in there that basically says only provide responses to information that you can reference in a document. You gotta be able to reference where the source was. Don't give me anything outside that document. Just give me responses of things that you can actually reference. That example of fine tuning, I would.

Say that's an example of probably prompting and retrieval. The instructions you're giving it are good prompting, you're telling it what you want it to do and the documents you're showing it are the retrieval. That's where you've just fetched the relevant documents. I would say that's probably not fine tuning. I think of fine tuning as modifying a copy of the model. So instead of calling the Llama 7 billion model, I'm calling the Chris Capeta May 8th copy of the Llama 7 billion model. So. So it's actually fundamentally changing and getting a different copy of the large language model. And I don't know to what degree this conversation is like a boomy sort of relevant thing versus just general technology thing. But I will say I think fine tuning will become stronger in the years to come. And from what I've seen using BOOMI to pipe the data in and format it and prepare it from wherever it may sit in whatever format it might sit. As fine tuning becomes more useful, BOOMI will continue to be a good sort of pipeline for that data.

We definitely use BOOMY example because we are working on doing. If some of you listening aren't familiar, but we have a new series called AI M&A teardown and so we're going to have probably both of you as guests to actually do some deeper dive and use like actual booming examples for demo. So yeah, happy to talk through those. Anything else on fine tuning? Because I do want to touch on agents.

I think we've covered a lot of ground on fine tuning.

I do. There's only one thing I would like to say. I often think of fine tune. I think you just said it. There's the llama 7B variant or some smaller model and then there's the Chris Cappetta variant on that as well. I could see fine tuning as we multiply ourselves and our agency. I can see fine tuned models for each one of us as humans to sort of interact with the world as if it were in our voice in various contexts. Again, it's probably going to involve a combination between retrieval and fine tuning. But that fine tuning component with that linguistic model, again, that's the key. Language models are essentially taking syntax and converting that to semantics. The idea is if you're going to construct a sentence and you're going to derive meaning out of it, language models are really good for that sort of thing. And if you can put it in your voice, that I think is going to be a really good frontier for where fine tuning is going to be helpful.

Very cool. Let's talk about agents. Because you talked a lot about agents earlier today, let's define what those things are.

Yeah, it's sort of a nebulous world right now. I think you might have a couple of slightly different answers here, but let's see where we go. I think of agents as functions in Amazon aws. They're lambda functions, they're task based types of fetchers and putters and getters and those sorts of things. They're there. These functions are ephemeral and they perform a particular purpose and then either go away or are somehow latent. Fundamentally as an infrastructure person, I think of agents as just that they're basically task executioners.

It's a term that has really spanned and grown in the last year or so. I would say probably the technical definition of an agent I could think of as anything with generative AI using tools. And to that degree I think there are a lot of agents out there that are doing really cool things. For me, I think the most exciting element of agents is when you can start to get into higher level goals and have it make decisions as to how to achieve those goals. And then even beyond that, you could imagine a scenario where you could give an agent or an agent swarm a bunch of agents interacting, some goal like, or some sort of high level, just general directive, say hey, we would like you to work on food shortage in this nation state or something like that, and then have it be able to have both the autonomy, the access, the decision making and the tool set to go out and decide what goals go into that initiative or objective, and then decide what tools go into those goals. There's a varying degree of agents at this point, and I think they can span from low level decision making AIs that have access to external tools of some degree, all the way up to HAL 9000. But a nice version of HAL 9000 hopefully is what we would go for.

But so basically have it actually do things. So for me to prompt it to go change my flight, that would be an example. You've got tasks it can actually do.

And tools to go actually make the change and send the emails and call the APIs and all those things. So yeah, 100% I'd call that an agent.

Yeah, and the other thing too, we talk about this all the time, but making sure that results are presented in the right sequence, or if it's unnecessary to do that, it doesn't matter. If you do tasks or perform tasks in parallel, that's fine too. It just depends on what the overarching goal is. And the cool thing about this too is the layers of abstraction on top of that could be constructivist. In other words, these agents could figure out that you said agent swarm before, so I'm going to just go with that for a second. A coordination of different levels of agent at different levels of abstraction could present some really interesting outcomes, like specific tasks for booking the flight, how many steps go into that. You could have an orchestration agent of some kind, figure out what agent class is going to be able to go out and fetch the kind of data necessary to be able to determine how you're going to book your flight. Then you're going to need to know what sequence everything comes in. You can't pay for it now and then get the flight later without knowing the price. So you have to know what sequence to go in. You have to know your particular parameters that you want to put in. That could be from a prompt, or it could be because the model just knows who you are inherently, which would probably come from a series of prompts, if not a fine tuned model of some kind. To know who your Persona is, what type of class affair you would like to book, for instance, where you're going to travel to what countries you can and cannot travel to, those sorts of things. All of that needs to be orchestrated at different levels. The cool thing is if you can present a goal and allow these agents to actually do the planning and the logic behind it, you're stepping into a world where you're making the LLM more self aware at that particular point. I don't want to get necessarily too philosophical here, but I'll quote or I'll paraphrase Yann Lecun, who is one of AI's top researchers. He works at Meta and he's the chief data scientist or chief AI scientist at Meta as well as professor at NYU. He basically says that LLMs are dumb and I don't know if I necessarily agree with that, but I'll go with that. He says they're dumb because LLMs don't plan and they don't reason. Today agents in my view, allow for a step closer towards planning and reasoning at this particular point and then maybe one day the LLMs will be sophisticated enough to have all types of orchestrated agents where the machine intelligence can determine for itself what kind of agency is necessary to achieve a goal. Right now I don't think we're there and so we need to set up the pipelines for the LLM to be able to have different levels of agent.

I'd add to that as well. From a tactical peeling back the onions layer, there are definitely a number of big AI models that are starting to build in the sort of functionality of tools. OpenAI has a function call and they also have their assistance API. Anthropic just rolled out tools on Claude and those are super nifty for what they can do. What I find though is that it seems like the versions of the model that are built to use the tools are almost too focused on that. I seem to find that I would rather split out just the mechanism that needs a tool, just the mechanism that needs this LLM to turn unstructured Natural language into like a structured payload. I like to have that very distilled and I don't want it to be doing anything insightful. As part of that, I would rather prompt regular chat completions to make a plan and then prompt a tool use of version of the model to turn that into structured JSON rather than say make a plan and give it to me as structured JSON because it just seems to trip over itself. I think that will become much stronger in the years to come. I'll say that the model vendors are starting to build in a concept of tools that I find interesting but limited. And then the other aspect as well is they seem to be thinking of a tool as a specific call, a specific API call to an external system. A more interesting use of a tool is really a full on process that could do many things. It just has to have a predictable input, a predictable output. I think of a tool as it'll resolve to either success or a failure and then the sort of higher level model can react from there. But I think of a tool as a more significant potential. Sequence, process, orchestration, integration, automation, all of those things could fold into a tool in a way that I don't know that a lot of the model vendors are thinking of it today, which is pretty interesting to me. Yeah, I think that would be how I would think of agents tactically today in early 2024, because the date probably should be on anything we're talking about here.

All right, you guys are definitely stretching out my technical competency. To round things off, let's talk about practical use cases we can actually do today.

Retrieval augmented generation is one that keeps coming up because it keeps being practical. The models are really good, but they just don't have the data that one's been discussed. I think at length. Retrieval augmented generation is probably the very top one. It's a familiar use case. People know chatbots and chatbots can be made to be better. Summarization is another really fascinating one. If you've got a ton of big mega technical documents to go through, it can be really valuable to say large language model. Would you please summarize this for me? You read the summary, you skim the document that you read the summary again, I think you'll get much more out of that document than just like pouring through something that is kind of meaningless. I think there are some really intriguing areas of classification and keyword generation and using the large language models in creative, almost discriminative ways to say your goal is not to answer this question, your goal is to generate synthetic questions or generate keywords or pull out part IDs or something like that. All of those things are pretty intriguing. There's a whole area of multi channel kind of. I think voice is a fascinating angle where you can have these verbal conversations with fascinating entities that can help you work through ideas. They can. I think we will see a scenario, especially in the years to come where people are really relating closely to as almost companions to these models. And I think we're starting to see some interesting capabilities there. Even just the voice conversation in the ChatGPT tool is a very cool angle of that. I think we're going to see a continuation of that. Oh, one other area that I wouldn't say we're really that focused on at boomi, but that has just been tickling my brain lately is this concept of sim to real training where you can basically train a robot in a simulation, then you just ship that knowledge into the actual robot in the real world. And it does pretty well. And it's a fascinating thing because I just saw one. I forget the name is Dr. Something. It was an abbreviation. But basically they had it so that they were taking this sim 2 real concept where they were able to train a robot thought process in the simulator, ship it into the real world and have it work pretty well. But they were having an LLM run the simulator training. So it was basically that they could do that at a scale that a human couldn't do. An LLM can run through tens of thousands of parameters and they can do it while we sleep. So the LLM can run all of the training parameters in a probably more objective way than a human. I think we'd get stuck into like, oh, gravity is 1.1 or whatever. Whereas an LLM's like, let's try gravity at 2. Let's try gravity at half that sort of thing. So it can turn the dials, it can turn the parameters, it can do it at scale and it can train robots without ever touching the robot. And then you just ship it into the robot and it runs. So that's not really any area that we're focused on or able to touch from a BOOMY perspective. Maybe we could, but that's been one that's wrinkling my brain lately just to.

Throw it out there, which is really cool. We have fun playing with stuff too. I want to get a variety of different use cases that we're actually going to market with now. But one thing I do want to toot Chris's horn here a little bit. He built Just a conversational way to talk to Claude. Really any large language model to where we're both interviewing the LLM directly, providing it with voice transcription services, all of these other things so that we can have interactive communication with our chatbot. I would say our chat entity more than anything else. Not really a bot, but we can have existential conversations with it, which is really fun. At an AI conference last week, we showed to the entire world you've been online with this sort of thing. So I want to give a shout out to you for that. In terms of some practical in BOOMY use cases that we're actually going to market with chatbots that are servicing, basically replacing keyword search and looking at ways that customers could have an interactive experience to offload the time that humans spend on servicing requests from customers that could be serviced from automation. Another one is writing copy. So from a marketing standpoint, the ability to write new copy and to also have the formatting templates to go along with it vis a vis prompting, those are real and useful right now. Sales interaction with potential customers and having very targeted messaging, knowing what their end user customer is going to look like and what type of email or communication to send to them. That's going to create open rates that are a lot higher than they are today. Those are other examples as well, summarization, which you've already talked about. Those types of copy generation use cases are going to be prolific. Summarization is prolific. And chatbots that are using methods that no longer require keyword search lookup to get real information back, those are real things that are happening. In fact, we just had a presentation today by a customer that did exactly that with BOOMI as an example.

These are awesome examples.

One other thought from the practical perspective, that kind of occurred to me as you were saying those good things. Often the practical stuff is multi step. The large language models are really powerful for what they're powerful at, as are vector databases and all of these sorts of things. But within that boundary you could have five steps of doing very interesting things and come up with something that is even more interesting than any of the five steps. So maybe you have an initial step that's using a large language model to decide what route should we take. And then you're using a step to say, okay, let's summarize the issue and then you're using a step to say let's retrieve the info. Then maybe you use a step to say which of this info is useful and then you actually ask it the question or have it generate the Audio or something like that. So from a practical perspective, I think you can extend the current capabilities of these technologies by stringing together multiple uses that are within their boundaries to do something that they wouldn't be able to do in a single sort of attempt right now.

One other thing too, now that we're riffing, this is getting really cool. It's been cool the whole time. But the other thing too is our partners, our third party partners, our agent framework that we have. When you can expose the value of their in C2AI, that's powerful. Give you a couple of examples. Imagine if you could have a risk score that you could apply to your supply chain as different environmental changes happen, government problems, breakdowns in supply chain, changes in weather patterns, cargo ships that go sideways in the Suez Canal. These are things that happen and have happened before. But imagine if you had up to date ways to risk score your raw material supply chain or finished product sent to next stage of your supply chain. Those are things we do today with some of our partners in our agent framework. Another one is being able to route to different types of LLM models. These are important too. You've got data pipelines that we can provide routing to, but hey, maybe you want to, for each prompt, get the right sort of model for the right question at the right time, with the right performance. Those are all things that are possible today. Another one is, hey, I want to predict how many students are actually going to be sitting in their seats in the fall who agreed that they were going to the university in the spring? Or are you going to be able to determine with relatively good confidence the payment schedules of accounts receivable? These are all things we can do today for practical AI purposes, not only with our framework, but also our wider partner ecosystem that we have in our agent framework itself.

My mind is blown with the possibilities in the current state. Gentlemen, this has been an awesome conversation. You've opened up my mind about all these AI possibilities. Thank you so much for the time. Those of you still with us, this is just a preview into the new AIM and A Teardown series which we'll be collaborating on, so you'll hear more from our friends here at boomi. Till next time, here's to the deal.

Thank you for taking the time to explore the world of M and A with our podcast. We love hearing feedback. Tag us on a LinkedIn post, add a review on Apple Podcasts. We'd love to hear from you. If you need help standing up an M and A function or optimizing one that you already have. We're here to help, and if we can't help you, we probably know someone that can. You can reach out to me by email Kisan K I S o n a science.com or you can text me directly at 312-857-3711. If you just want to keep learning at your own pace, visit mascience.com for a lot more content and resources. That's where you can also subscribe to our newsletter. Again, that's mascience.com here's to the deal. Views and opinions expressed on M and A Science reflect only those individuals and do not reflect the views of any company or entity mentioned or affiliated with any individual. This podcast is purely educational and is not intended to serve as a basis for any investment or financial decisions.