A New Standard for Agentic AI in R&D

Hi, everybody. Good morning, and thank you for attending this in the first of a series of webinars about the Dotmatics AI capabilities and platform. I'm Phil Mountaine, VP of science and technology here at Dotmatics. And today's webinar is really gonna be talking about the foundations of the DocMatix AI capabilities. If we move to the next slide, Ben, we have a packed agenda. So we first want to talk about our philosophy around AI and why we think it's different to, other players in the market and why we believe it is, better than other players in the market. We'll talk a little bit about the Luma platform, AgenTek Orchestration, and then I'll come back and show you four demo scenarios. So we'll talk about interpreting data using AI to build. We'll talk about generative AI, and then Ben and I will wrap up with a really nice demo that helps prove the point around our philosophy using our MCP server. So with that, I'm gonna push you over to Ben to introduce himself and to lay the foundations of the webinar. You're on mute, Ben. There we go. Classic. Classic. Classic. Alright. Thanks, Bill. So I'm Ben Morse. I'm the product manager of Agenetic AI at Dotmatics. Overall, large language models have generated an explosion of capabilities beyond what deep learning has provided to the industry over the last couple of decades. Generative AI has enabled intelligent agents that are no longer just chatbots that are operating without guardrails, but there's a full ecosystem of capabilities that's coming online around, managing agentic AI. At its core, agentic AI is taking a generative language model, like a large language model or a small language model, and allowing it to interact with systems. They take plain language as input, and they can read data, take actions, and ultimately produce results. The underlying model of any of these generative AI systems works by feeding it source material and then training it to accurately predict what comes next. At runtime, what it will do is it'll actually run thousands of those probabilistic predictions to generate a response based on what the user has provided, and what data it's taken in and what actions it can perform. This approach is incredibly powerful, but it does have its limits. Hallucinations can occur because this is a probabilistic operation, and the results are also not traceable when you're just using a large language model to generate your results. Our approach is not to shy away from this. Rather, it's to reframe the problem. Our approach is to try to build robust agents with as little generative AI as possible. We see the power of the agents as being able to orchestrate the functions rather than requiring these models to have to do the functions themselves. We'll we'll take a basic example here. Let's take arithmetic. The approach on the left, if you wanted to just use LLMs to perform this operation, would be to train a model or to take an off the shelf foundation model and perform operations directly in order to predict the outcome. In this case, the model would try to extract the numbers and predict the right response based on its training data. The model itself will only be as good at doing this problem as the problems were in its training dataset. It but it'll still be probabilistically creating a response. We actually don't have a problem with this approach on the left in complex spaces where nothing else works. And in fact, we'll have a example later on using our protein discovery functionality in BIOCLIFF where we're doing very much this approach. But when there's a deterministic methodology that exists, we think that the agents should orchestrate using these functions and chain them together to get their results. Based on the example on the right, the agent itself isn't predicting the math. Instead, it's building a process on how to get to the right answer and then invoking the functions or, in the world of agentic AI, the tools to get to the right response. The functions or the tools are the things that are doing the math. It's deterministically applying operations. The agent just chooses when to invoke them. In order for the approach on the right to work, though, you need a foundation where the datas and the functions are available as tools to the agent, and this is where LUMA then comes in. LUMA itself was built to be AI ready. LUMA connects your instrument data, and it connects it with purpose built scientific software as part of the overall Docmatics ecosystem, and it harmonizes all of it together. Luma maintains a continuous contextualized scientific record that has been normalized and importantly for agentic AI queryable. Our agent is built on top of this foundation. The data exists in Luma. The tools exist within Luma. These are exposed out to the agent to use the tools to navigate through Luma to get that response. Importantly, though, with anytime that we're talking about data, the data protections are incredibly important to bear in mind as your data basically is the keys to the kingdom. You can't just put it out into the world and have any agent reason over it. Luma itself was built with these data protections in mind to keep your data isolated. We have a partnership, with Databricks, and all the data flowing into Luma is stored and governed within the Databricks data perimeter. The Luma agent and the LLM calls within our agents also occur within this same data perimeter. They operate within the tenant space, and the data doesn't have to flow out to Anthropic or OpenAI or any other foundation model provider. Databricks themselves, in our case, is our data provider and our agentic provider as well. So here here's an example where we chain them together, where the agent needs to choose the right tool for the right job and not have the agent ingest the dataset along the way. So in in this example and we'll walk through some some detailed, real world example of this in a minute. When we're doing an r group analysis, the agent will query Luma to get the data and create a curated dataset. The agent is capable of taking a peek at that data, making sure that the shape of the data looks and makes sense, but it's ultimately generating, queries to get that dataset into the right shape. From there, it can pass that dataset to a tool designed to answer a question. In this case, we have r group analysis tools, and we'll pass that query into our r group analysis tool itself to perform the analysis. The LLM itself would only process through that final result to generate the summary. It's not performing the r group analysis. It's choosing the right tools in sequence to get to that end result. LUMA itself is built on our family of apps, but it also has access to specific scientific toolkits such as our Genius molecular biology toolkits or or Dotmatics chemistry toolkits. These toolkits allow the agents to invoke specific functions to calculate a result without relying on the model's probabilistic, properties to generate a response. In addition, within the world of agentic AI, MCPs continue to be the gold standard that we have to share information across agents. We are offering a Luma MCP where we are taking the tools available to our Luma agent and exposing them over our MCP server, which means that the tool calls that the Luma agent uses for configurations, querying data, executing function calls, etcetera, can then be invoked by your agents. This is incredibly helpful if you already have an AI strategy or if you have a partnership with Anthropic or Google or OpenAI or if you are building your own in house models and you want to continue to use that as part of your analysis pipeline. The Luma MCP extends that strategy by giving you access and your agents, importantly, access to the Luma platform and the collection of tools that we have available. With that, Phil, I'll pass it back over to you to talk a little bit more about Luma. Thanks, Ben. Let's, do one more click, and we'll build out this slide. So as you may or may not be aware, Docmatics has acquired many best in breed apps on the right hand side there. One of the challenges that we've found, and it's very similar to a lot of you guys in the industry, is that connecting the data from these apps is hard. Connecting workflows across these apps is hard, and actually using some of the deep scientific knowledge across these apps is hard. And that's why we developed Luma. So Luma sits in the middle of all these apps, and we can share data. We can share workflow. And really importantly, as Ben mentioned previously, we can share the scientific tool kits, make them available in dashboards and interfaces as I'll show you shortly, but really importantly, make them available to our agents so that we can do those more deterministic approaches to AI querying and and working with AI on your data. Now as I said, this is the the the start of what we hope is many webinars on AI around AppMatics. You can imagine that as we work and bring these applications closer to Luma, we just what we end up doing is extending the tool kits available to our agent, which helps you agentically build workflows, do data analysis, etcetera. So what I'm gonna do next is, Ben, if you'd let me grab the screen, I'm gonna show you some demonstrations, and then Ben and I will come back, and we'll actually test the hypothesis that Ben talked about at the start, which is use the language model as little as possible, really, and use agentic calls to tools that have specialized scientific knowledge to to run the kind of queries that you need. So first, let's, let's take a look, at how an end user might interact with an agent in in Luma. So this is Luma. This is my, chemistry dashboard that I've built. The data in this dashboard could come from the Docmatic CLN or a third party. Luma is an open ecosystem. And this is an example of using one of our tool kits in the front end. So wherever you see a structure here, this is actually using the DocMatics ELN chemistry tool kit to render that structure, and I can even click on a structure and load up the DocMatics elemental sketch if I wanna do substructure searches in here. So it's important that you get the same results no matter where you're where you're working here. So this has registration data in in the table here. We've got some high level charts to look at compounds and assays and design ideas per project. We've used our chemistry toolkit here to to calculate chem physical properties. We have batch data. We have biochemical data in this dashboard as well that could come from Prism or Screening Ultra. If it's characterization data, it could come from, Proteimetrics or Visidian. We have inventory information in here as well, and we even have PK data. Now these dashboards are nice. They're really interactive. I can move columns around. I can go into explore mode and add calculations. I can drill down into the data underneath any chart by clicking on the little table icon here. But when it comes to making a decision on this data, humans still struggle with this. Right? There's there's a lot of data in here. There's a lot of charts. How can I make a holistic determination of what I want to do next? And that's where agent Luma comes in. So agent Luma is trained sorry. Is uses all of the data in this dashboard as context when I write a query. And here we are. I I've just stashed this example prompt here. I'm gonna set it running. One of the things that Ben touched upon at the start was how we want deterministic and traceable, work when we're when we're using an AI agent. And the way that we've implemented this, really like because you'll see as it runs through the query here, we'll start getting little table icons in the output window. Let's move this to full screen so we can see. Each of those table icons actually is clickable, and I'll be able to see the data that the agent is using to reason over this. So that means that if I don't agree with the data or I think I'm missing some data, I can quickly stop this, and I can go and reconfigure things. So while this reasons, it's gonna use a tool call out to look at the data in the, in this dashboard, and then it's gonna use reasoning in between those tool calls out to the data to go and, perform my query. So here we can see I've got some biochemical data coming in here. It's now looking at some of the best performing compounds in my project. I'm gonna turn on do not disturb again. And it is basically helping me start to prepare a report here. So here we can see the report coming through where we have different compounds, different projects. It's giving me a table. It's giving me key insights into the some of the projects, and it's it's conversational. Right? So it's asking me what would I like to do next with this data. Now other things that we can do with the agent in these dashboards is we can actually use the agent to help me filter the dashboard. So you could land on the agent first, write some natural language queries, have it pre filter a dashboard. That's really useful if you've got lots of data. So, obviously, the the the quality of the output here is kinda determined by the quality of the input. So you have to know how to prompt engineer properly to get the most out of these language models. But how can we take that problem away as well? So let's move to a different app. This app is based on some ELN data. Let's go into our experience. And, basically, what I'm doing here is not run prompts while I'm in the dashboard. I've actually prerun some prompts as data lands. So in this dashboard, I have some write up data from a notebook. I have a table of materials, and I have some really unstructured document data in here. So the document data is kind of interesting. Let's let's go and have a look at what this document looks like. So this is a PDF. It's a paper. And, traditionally, this sort of unstructured data is kind of inaccessible to to data science and therefore to you know, for for for good insights from an agent because, you know, it's unstructured. It's a big, long paper. The idea of, this dashboard is actually to help me summarize all of the documents in this experiment, some of the tabular data, and the write up data, and help me review this and draw conclusions. But wouldn't it be cool if I could actually just look at a summary of that document in that process? So when I click on here, I'm actually running a preloaded query here, a preloaded prompt, and asking an agent to summarize the PDF for me, and we do that as part of our ingestion pipelines. Finally, I can actually use another prompt that's preloaded here to go and review this experiment as a whole. So look at the key results, look at the documents, and, critically, you know, if I'm reviewing this experiment, look at any mismatches. And we do all of this in our, what we call raw data flows here. The raw data flow happens every time new data lands in here. And in this raw data flow, you'll see I've actually hard coded a prompt that gets run each time this data flows through. So this is using the you know, getting somebody that's great at writing prompts to preload this so that the your end users can make use of an AI without having to worry about engineering their own prompts. So this is kind of a look at how you can interact with data once you've had it loaded. It's where an end user might, use AI. But how can we help people that have to build these apps? And that's where I want to move into the next section. So in this, in this app and you can see here I've folded out the left hand side. This is the anatomy of what an app is. So I've I've set up a connection to LabConnect because I want to load some flat file data in here, and I need to create tables. I need to write those raw data flows to transform the source data into my table, and then I can build my experience for the end user. You'll notice, though, that there are no tables in this app yet, and there are no raw data flows. So the data that I'm operating on is some assay results from a collaborator. Whenever we load data into our LabConnect system, and we can do that for things like GraphPad Prism or other software, we can do that from direct instrument connections, We store the raw file, but then we also create a parsed version of that file so that our agent and other systems can operate on it. So what I want to do is ask an agent to go and look at this, build me a table, and write me a raw data flow without me having to really think too much about it. So I can go into our agent Luma here. This is available from our menu at the top. Let me just jump to my other screen and grab my prompt. And what I'm gonna do is I'm gonna ask agent Luma to perform two tasks. I first want it to go and look at that Excel sheet, and I want it to look at the the structure, and I want it to build a table for me. And then I want it to look at that same data sheet and actually write some SQL or some Python, write a raw data flow to push that data into, into my app. So I'm in autopilot mode here. All I have to do is look at the plan and approve it, and the agent will start working. Now there are several modes to the agent here. I'm in autopilot, and in autopilot, I give it a prompt. It tells me the plan. I review the plan, and then the agent does the rest from there. In collaborate mode, I do the same thing apart from each of the sub steps that the agent is working on in the background there. I also approve. And this is great if it's the first time that you're building an app or the first time you're working with a new instrument data source or raw data. I can also move into explore mode. Explore mode basically doesn't make any changes in the system. It just allows me to write queries or ask the agent about skills that it has. So these modes will be tied to up to user user's roles and responsibilities, obviously. So let's have a look what the agent's doing underneath it. So, basically, the agent is breaking down and using tool calling. In in this case, we're using a data specialist to go and find that Excel sheet, look at the columns. It's then gonna find the data type for these columns, and, ultimately, it's gonna go and build a table in my app so that I'm ready to then write a raw data flow. So here we can see it's building the table for me. And once this is finished, then I will go and show you the table that's built. So this is saving me a lot of time. I don't have to go and inspect the file. I don't have to look at the data types. All I have to do is write a prompt, the agent takes care of the rest for me. Over in Luma, if I move to my tables now, I have my table built. When I click on the table, I can see all the columns. It's settled the data types. And really importantly, it's added a description. Now thinking back to that first example where I was an end user and I was using natural language to make sense of my data, these descriptions really help the agent understand where to find the data, and what data is in a given column. So this is quite a simple example. We're just taking data from an Excel sheet, and we're building it into a table. But I wanted to give you a sense of how much time that saves. Even if I've gone through and understand my Excel sheet completely, I have to go over here. And if I'm doing this manually, create a table, give it a description to help train that agent. I add columns in here. I create a new column. Let's call this one. The first number, I I set my data type, I add a description, and so on and so forth. Now you can imagine this would take some time with a twenty column table, for example. But in a real world example, you're probably gonna have ten, twenty, thirty tables of data that you need to import. Asking the agent to do that is gonna save you an awful lot of time. Now this is moving data around, but what if I want to invoke some of those tool kits? What if I wanted to import chemistry data and then calculate some properties? The agent also understands those tool kits. So if I go to my agent here, I'm gonna go to explore mode, and I'm gonna ask it to tell me about the chemistry toolkit functions. And it would help if I could type properly. So we're in explore mode here. It's not gonna make any changes. This is just me asking the agent what skills what what, scientific skills does it have, and maybe how could I invoke those for use in another workflow. Now in the agent's list of skills, we obviously have our chemistry tool kits. We have our biology tool kits. I'll show you those later. We have the the actual app building tool kits as well. We have some others, though. We have a registration system in Luma. So the agent is trained on the registration system. Imagine being able to get a a sample of data loaded in, ask the agent to go and build you an equivalent entity in the registration system with all of the the different metadata from from your source data. Let's I'll I'll show you the the the response in a minute. Let's ask about Genius. Let that reason why we go back up here. So here we have the a summary of the tool kits, the the chemistry tool kit that our agent has access to. So structure depiction, structure searching. Notice this two inchy. This is really important in a registration system, for example. Fingerprint generation, property calculation. Again, import my chemistry data and build me a table of calculated properties. And then right down to the bottom, we'll see we have fragmentation, our group fragmentation, and and Ben and I are gonna use that a little bit later, in this demo. It will even give you examples of how to use this. So if you wanted to build one of those raw data flows by hand, you can ask it, how do I invoke this, this sort of function in SQL, and it will go and build that for you. Okay. So it's now, it's now told me about my Genius toolkit. So this is our bioinformatics toolkit in here as well. We have things like back and reverse translation, sequence import and export, even cloning in here as well. So I can ask my agent, you know, I've got my two different files, my insert, and my backbone. Can you go and do some cloning for me, for example? So you can invoke all of these deep scientific tool kits when you're chatting with an agent and asking it to build an app for you. Let's go back over here. So now we have both tasks completed. The first task created my table for me, and the second task inspected that table and that source data and wrote a raw data flow for me. So if I go back into my app, let's go to our raw data flows. Now we see a new raw data flow in there. We can see the steps. It's taking care of writing all of the SQL for me. Then all I have to do is preview the SQL, check that it's giving me the right response. If it's not, I can go back to the agent and, carry on my chat. In this case, though, it's got the data right for me. I'm ready to publish this app and build my dashboard. So this saves this saves our administrator users tons and tons and tons of time, and, you know, it's only the start of what we'll be able to do in here. So so far, what I've showed you is how to manipulate existing data. From an end user, how to reason over that data and find trends. From a administration perspective, how to use data and build it into an app that your end users can use. How can we use agents and and AI to actually make net new materials or net new hypotheses? And in this section, I'm gonna talk to you about de novo protein design in our Bioglyph application. So in Bioglyph let's go back home here. I can go to my engineer proteins. And in this case, what I want to do is design a de novo protein that interacts with a target in in the human body. So I load up the three d structure of my target, and what I have to do next is I have to define, here, where is my binding region? Where do I want my de novo protein to interact with? So I can either do that on the three d view, and, of course, I can change how this three d view is represented. But down here, I can also look at the individual residues in the sequence map. So I'm gonna just choose this as my binding region. Down here, it's captured that binding region. I can tell the system what kind of, what kind of protein I want to design, how many how many net new de novo design sequences do I want in here, and then submit the job. Once that job comes back, we end up with a table of the de novo designed sequences. I can click on any of those sequences. I can see annotations that have been added in here. I can zoom down into the individual residues. And then because this is baked into a a broader antibody discovery workflow, it's even doing things like calculating liabilities for me. So I can actually choose several of these de novo designed proteins, and I can go into my engineering round here, and I can say, well, I want to I want to do some mutations to engineer away from these deamidation liabilities. It will show me hot spots on the three d view. It will show me hot spots on the sequence view, and then I can go and make mutations in here and generate a new panel of of potential sequences that are de novo designed and also optimized around some of the liabilities that we found. So so far, we've showed you how to a user can interact with data. We've showed you how you can an administrator can use AI to build apps. We've showed you how you can use de novo protein design to generate net new compounds. What I wanted to do next was come right back to the hypothesis that Ben talked about right at the start, and that is to get much more deterministic results from an agent by actually using the language model as little as possible, but call out to specialized tools, to to get the results. So remember when I was showing you some of the the capabilities in our scientific tool kits, I showed you that we have a chem informatics tool kit, and we have our group analysis in here. So what I've done is I've loaded up into Claude desktop my Luma MCP server. I've asked it to go and find data from one of my data apps. Maybe I'd use AI to build that app. And I've asked it using this input smile string to go and do an r group decomposition. Now, of course, if you're in an experience in Luma, you could use a Skecher to to sketch out this this smile string instead. And what you can see is it's loaded our MCP server. It's gone and run some of those tool calls to go and filter for the Alzheimer's dataset. It's found those two and a half thousand compounds. It's then gone and discovered because we've not trained Claude explicitly on our MCP model. It's discovered that it we have a chem informatics toolkit, and we have this r group fragmentation function in there. And then it's gonna run that for me. And if I scroll down to the bottom here, it's found two thousand three hundred and thirty three compounds. Now the important part about this demonstration is if you've ever used a large language model before, you can ask the same model, the same question on two different days, and you'll get two different results. Never mind if you ask a Claude and a chat GPT the same question. You will get different results because they are probabilistic. What Ben's gonna show you next is using exactly the same prompt and different models, how using the Docmatics philosophy, the Docmatics approach to agentic research, we get the same results, and that's really important for how you guys adopt and use AI. So I will share my screen. In this case, I've loaded up that same prompt into three different models, in this case, into Codex five three, GPT five dot five, and Composer two five. Because the agents are running, nondeterministically, they're going to approach the the problem slightly differently each time, but you'll see that they'll come out with the same response. We also did not structure how exactly we wanted them to shape the response, so you'll see the response shapes come out differently. But the base data that's there is going to be the same. In this case, it probably came up with, two thousand five hundred compounds evaluated, two thousand three hundred thirty three that were nonempty, and a hundred sixty seven with empty fragments. The way that it got there was by, evaluating the chem informatics, and then it ran a series of Luma queries in order to get that result. Similarly, GPT five five, was a little bit more verbose in the responses that it gave, but it also came up with the same response in here of two thousand five hundred, two thousand three hundred thirty three, and one sixty seven. In this case, by running the Luma query. You can see some slight differences between them where codex five three, was less verbose in explaining why it's going to be choosing to make these tool calls. GPT, yeah, five five was more verbose in how to get there. But at the end of the day, it's still constructing together how to perform these Luma queries and to do that tool call invocation. And then, additionally, I have Composer two five. Composer is, one of the in house models that are provided by Cursor specifically for coding. So it doesn't know anything further than what we provided here beyond the the Luma MCP. But because part of the MCP, we provide in instructions on how the agent should use our tools and under what context, it was also able to identify, hit the app appropriately, work through the registration data, identify the compounds, and then send it in for our group analysis, in order to get, the results in here of two thousand five hundred compounds Brand, two thousand three hundred thirty three matched, a hundred and sixty seven, with no match. And in this case, because it's a programming based language, it wanted to give more information about the underlying language, so it actually came up with here's the SQL statement that it was able to on how to do this execution between the tool calls and marry all the data together. Excellent. So we we've come to the stage now where we've got lots of questions. Ben, I think you've you've got a few that that we wanted to go over, and we'll look over the chat and answer any of those. But we'd really like to thank everybody for spending the time today. As as I said at the start, this is the first of of many. AI in Docmatics is an area of really intense active research and development, and it's great to have Ben on board to help drive that. So we we really look forward to doing more webinars as we as we produce more skills, more tools, and have more cool demos to show you. So, Ben, did did we have a few questions from the chat? We did have a couple questions. There there was a question that was asked earlier that's worth repeating, and it's a question about billing. How how is this billed? I'm happy to take that one or fill it. Go for it. Yeah. Okay. As far as billing within the AI agent goes, so we are operating on a pass through model for token utilization. And for those of you who are not familiar, tokens are kind of the the base chunk that gets processed by an LLM, and there's a couple factors that go into the amount of tokens that are used. One part of it is the amount of context that's given into the agent. If you have an agent that's consuming, say, a hundred word documents and performing reasoning over that, you're paying for a hundred word documents to be chunked, tokenized, and then processed over time. And on top of that, then, you're also paying for the additional questions that you feed into with the prompts that are fed in. The tokens that are used in our, within the Luma agent is billed through to our customers directly. However, because we are using tools, we're seeing that a lot of the the token utilization is actually offset in this case because the agent isn't consuming the raw data sources. That's already being processed through the the deterministic processes within Luma. So we're we're actually seeing that that's a cost benefit of going in this direction. As far as the MCP goes, the way that the MCPs operate is you're running your own agent through whatever format that you wanted to see. So we we just demonstrated, me running in cursor. Phil was running in cloud desktop. Those get billed through whatever current process you have, for that. There's no additional cost to interact with our MCP itself. One additional call out that I I will make with MCPs, There's been questions around, well, that's great that you're providing all of these tools, but how do how does my instance know how to interact with Luma? One of the things that, is happening with MCPs increasingly is publication of skills and baking those skills into the the tools themselves, so that the agents can receive instructions not just on what's the right format that the data should be in when invoking a tool call, but also when you should make it and under what conditions and what's the workflows look like. So that's that's an area that, we're we're pleased to extend in as part of this as well. Our goal here, of course, being to try to keep the cost down for our customers by trying to leverage as many deterministic tools as possible so that then you can spend those tokens on the deep learning paradigm that that is more interesting. Ben, I saw another one in chat that I think you're probably best suited to answer, and that is, are are you using my data to train models? Yes. We are not. So yes. Good question. No. We're not. So, right, we we're not using any of your data to train the models directly. What we will end up doing is the agent will make a call to the tools to access the data and to receive it back, and all of this operates within the Databricks security perimeter. When we're when we're making any calls to a a model provider, all of those that are actually hosted within Databricks themselves, which is also where the data is hosted within the Luma platform through our partnership with Databricks. What that means is everything stays within this closed ecosystem itself. With that being said, we are not training models on your data. The models themselves that we're using have been trained generally on understanding how to use Luma. It is not trained on your specific context. Now this being said, this is an area where we are interested in further partnerships where it may make sense. If you wanna explore a conversation with us, we're happy to have that conversation. But we have, up until now, taken a very strict stance that none of the data is used for training. Thanks, Ben. There's a question that I can take is, the the question essentially was, we have a hosted dotmatics environment. Does Luma have access to all of that data from day one? So we have integration frameworks on both the platform and the Luma side where we can shuttle data back and forth where appropriate. We're also working on some more automated systems to move data across so that you've got all of your Dotmatics data, in Luma and available to the agent. So that is, something that we're working on. And then there was a question about whether there are options to try Luma and try some of the AI tools. Absolutely. If you just get in contact with us either via our website or via your existing account manager, then we can we can absolutely set you up with some data and a Luma platform where you can go and try some of these agentic capabilities out for yourself. With that, I think we have answered most of the questions in here. Ben and I really like, once again, to thank you guys for your attention. Look out for more of these webinars from us. This is just the start, but I'm really excited by our approach. I think the testing and demonstration that Ben and I have done has kind of proven that there's real value to not just strapping on a large language model, not just strapping on another database to your existing system, but really thinking carefully about how to use these agents, how to get the best answers out of these agents. And as Ben mentioned, how to actually, you know, win in this new token based economy that we're all entering by, by really using less using less of the the LLMs and and using, specialized tools to help you get your answers. So thanks again, everybody, and we look forward to speaking to you again soon. .