JMP and AI: Where LLM Integration Meets the Analytic Workflow (2026-US-30MP-2955)

All right, this is JMP and AI: Where LLM Integration Meets the Analytic Workflow. I'm Dan Valente, the Director of Product Management at JMP, and I'm joined today by Scott Allen, Senior Product Manager for AI and the JMP Marketplace. Our goal by the end of this presentation is to continue to talk about why JMP remains vital in an increasingly AI-focused world.

We know that there's a lot happening right now around AI. We hear it from users and their organizations regularly. There's concerns about falling behind, questions about cost and security, and a genuine desire to find real practical value in these technologies. Before we can get into how AI can be applied to the JMP workflow, it's important to talk about some disclaimers. At JMP, we're staying grounded, and we're not necessarily just bolting AI onto products just to check a box. Instead, we're focusing on customer outcomes, understanding where AI and large language models genuinely help scientists and engineers do better work and where they don't. The surge of AI does not change JMP's core values, and that's really why problem solvers use JMP and why it remains vital to their organizations. That's really because JMP is interactive first.

You drag a column into the Graph Builder and you see your data instantly, and there's no code or syntax or prompt. Everything is linked. You click a point on the graph, and it highlights in your data table and every other graph across your workspace. It's an end-to-end workflow, and you don't necessarily need to stitch together five different tools. You stay in JMP, and most of our users haven't written code, and for daily tasks, we don't think they should.

How do AI and large language models plug into JMP's value chain? This is the conceptual model of how our users create value for their organizations, really left to right in this diagram. It starts with a person and a problem, applying their statistical expertise to solving a certain business problem. With JMP, it helps you translate your business questions into analytical ones, guiding you to provide the right methods and providing an interactive visual environment where insight happens quickly. JMP Live helps to extend that value across the organization, helping to make work visible, making and sharing proven methods, and moving analysis from individual laptops to enterprise-wide collaboration.

It's natural to ask, where do these LLMs actually add value in this existing JMP ecosystem? We think of them as accelerators and connectors. LLMs plug into specific points, enabling users to connect business problems to analytical methods faster and scaling those solutions into broader applications through extensions. By integrating LLMs into this workflow, we see several key areas of impact. For new users, we can really focus on decreasing time to value. For a new user who is a scientist or engineer that has domain expertise, maybe they're a chemist or a semiconductor engineer, but not necessarily a statistician, LLMs can help new users get productive in JMP faster for all JMP users, making it easier to find the right capability to solve the right problem.

JMP is a general-purpose analytic tool that's been around for 36-plus years, full of lots of hidden gems. LLMs can really help with that capability discovery. For non-coders who may want to script and automate, they know the value of JSL and coding. LLMs can help accelerate the development of custom scripts and add-ins without necessarily that deep programming knowledge. For data science groups who are expert programmers, awareness of JMP's vast out-of-the-box functionality with no code required can help those data science groups help JMP users across the organizations. For organizations, it's linking those business problems to JMP analytical methods faster and more powerfully using custom automation via JSL. While JSL remains available for JMP, LLMs can help build those custom business solutions quicker.

You might also ask about, will LLMs and prompting a chatbot replace JMP's analytic workflow in the future? We don't think so. We wonder why, right? Why won't LLMs or AI replace a user solving problems in JMP? This chart helps to make the argument visually. The x-axis goes from common problems on the left, to rare, high-value problems on the right. The purple line is the amount of large language model training data that's available in the world, and you can see that it drops off fast. The blue line is LLM effectiveness. It drops with it. The teal line is JMP effectiveness. It goes in the complete other direction. JMP gets more valuable as problems get harder and rarer. The left side is the LLM territory, things like how to make a plot in Python, something that's a Stack Overflow answer. The responses here are great because there's lots of training data. The effectiveness breaks down when you try to do something like exploratory data analysis, exactly where JMP is valuable.

Training data abundance does not necessarily equal business value. LLMs are trained on what's common, not what's valuable. What are we actually building to be able to use this great technology, but then also serve the JMP analytic workflow in the same way? Like all of our strategy for extensions in JMP, we're building for flexibility. We're not betting on any single one vendor or one technology. We're not assuming that a single LLM provider will win. Our focus is on building the infrastructure and interfaces that allows our user base to connect to the models that they want and the services that are aligned with the organizational standards that they have.

Here's how it comes together: First, the knowledge base—that's jsl.jmp.com. It's a rich and robust library of examples on how to control JMP through JSL. Second, the translation layer. This is the LLM/RAG—Retrieval-Augmented Generation layer. What this will do is allow that knowledge base to produce responses and minimize hallucinations, so when people ask questions to these LLMs, they get accurate, grounded answers. Third is the endpoint connector framework, which is coming in the next version of JMP—JMP 2027. This is the plumbing. We're making it easier to connect JMP with the LLM of your choice through these endpoint connectors, so you won't be locked into a single provider. Finally, a set of robust extensions through the JMP Marketplace and delivery of those extensions through the JMP Marketplace.

You'll see in Scott's demo, we're making all of these AI tools optional through the JMP Marketplace, which means we're not forcing any of those in the JMP analytic workflow. You can use them as you desire, but you're not forced to them. Here's a deeper dive into some of these areas. This is the knowledge base at jsl.jmp.com. We've got about 30,000 or so—and growing—JSL scripts within that, and those are really optimized for LLM interpretation and consumption so that all of the models, as they're training and releasing new versions, get better at responding to natural language inquiries of how to do a certain thing at JMP, and then be able to generate that JSL so that it can be a smarter output for both JSL scripters and non-JSL scripters. Then we have the translator, that LLM/RAG framework that I talked about; it tailors general LLM responses, and it ensures high-quality, accurate, and relevant results happen by default to minimize the hallucinations that are often plaguing a lot of these large language models. Then, as I mentioned, the plumbing, which is similar to the data connectors framework that we've had in JMP for the last several versions.

Coming in March 2027, we've got an endpoint connector framework, which aims to allow users in their organizations to connect to the LLM of their choice and ultimately adapt JMP to existing enterprise LLM workflows that already exist. Critically here, because we're not shipping an LLM in JMP, it keeps your data and API keys inside your organization's own protected environment, and it gives users and their organizations flexibility to switch LLM providers without rewriting scripts. This framework, we hope to get feedback on. If you're part of the early adopter program, this is coming very soon. If you're not and want to provide feedback, you can register at jmp.com/earlyadopter. We'd love to get that feedback from you.

We have a number of tools already available. You'll see a demo of several of them from Scott after this part of the presentation. These are AI and generative AI extensions that are available on the JMP Marketplace to do valuable tasks in JMP without affecting the overall JMP analytic workflow. These tools are a continuously evolving library of high-value, optional extensions that are available on the JMP Marketplace, and our users can easily install and modify those extensions based on their needs. Critically, AI remains optional, not mandatory, within the JMP analytic workflow.

Finally, as I mentioned, the JMP Marketplace is our delivery mechanism for all of these extensions. It's one location. It's easy to search, find updates, and see all of those available extensions. The generative AI extensions that are on the Marketplace is just some of the 125-plus extensions that are available. They're easy, one-click install; you can get them in JMP and then modify them as needed. You can see all of the different extensions that are available there for download.

Finally, before I hand it over to Scott for some of the demos, we want to just highlight some of the privacy, security, and compliance resources that are available to ensure that you can use these AI extensions on your own terms. We know for organizations, privacy, security, and compliance are increasingly top of mind, especially when generative AI is involved, so we've made it easy to help you find the answers that you need if your infosec or IT departments are asking for these things. Our trust center at jmp.com covers exactly what JMP does with your data and prompts, how we ensure data privacy, what security assurances we provide, and how we address things like the EU Compliance Act and requirements.

The generative AI terms detail specifically what happens when you're using LLM-powered extensions on the JMP Marketplace. Each extension that does take advantage of generative AI has a model info sheet. That model info sheet tells you exactly which model is being used, if any, and then also what information is sent to the LLM. Finally, our JMP responsible use policy outlines our commitment to ethical AI practices and guides you through both permitted and unacceptable use cases. All of these resources are available publicly and available to share with your security and compliance teams. All right, so with that, I will hand it over to Scott to get into some of the demos and additional information on the extensions that we have available.

Thanks, Dan. I want to start my portion by reiterating what Dan said: our approach to AI integration is infrastructure-first, and we really want to provide the infrastructure that will allow our customers to implement AI capabilities on their own terms. I'm not going to go back through all of these, but we've got five areas, and I want to do a little bit of a demo that touches on each of these concepts or infrastructure items and talk a little bit about where we're headed. I plan to show how we can use each of these approaches to help users build out their own JMP AI integrations. We have a number of different applications and examples, and my goal is to show how you can start using these today.

First, I want to talk about the knowledge base. Dan had already talked about the knowledge base. Before we go into the efforts in this area, I just want to give a little bit of background when we say this term: what is a knowledge base? Dan talked about jsl.jmp.com as a key knowledge base when it comes to JSL, but there's a lot more information out there.

In general, that knowledge base is really a collection of trusted information that an AI agent or AI system can reference when generating a response. Without these knowledge bases, agents can only rely on their training data. Many of the base models are frozen in time, and training data is typically unknown, so the knowledge base in an agent or AI system is really there to reduce hallucinations and keep agents updated with current information. The goal is to provide users with accurate information that's grounded in facts. In addition to jsl.jmp.com, you can consider many of the documents that are available, part of the knowledge base that you can use: documentation, how-to guides—these are all things that are going to keep responses in the LLM grounded into what's relevant to JMP. We're aiming to release more. There's training course materials, transcripts. We're continuously building out our collection of new scripts and script snippets to keep building out those knowledge bases to make any JMP expert system provide relevant responses to those questions.

The goal of that knowledge base, it's the foundation for that translator layer. Dan had mentioned RAG, or Retrieval-Augmented Generation. That's where we started when we started thinking about different tools that might be helpful to users. One of the first demonstrations there is the JMP LearnBot. The LearnBot is a simple add-in that calls an agent that uses a very large JMP knowledge base to create responses that are customized to those JMP users. When you ask LearnBot a question, you're more likely to get a response that's relevant and grounded in JMP documentation. The knowledge base has documentation, training materials, the scripting index, JMP YouTube channel information, and other JMP-specific content. All these materials are updated as needed; you don't have to worry about the information getting stale. As JMP versions change, documentation can be updated.

Before I go into an example of the LearnBot, I want to show a little bit about how this really works. I think it's important to understand this if you do decide to implement knowledge-based material into your own systems: when you ask that question to a system that's using RAG, what happens to that information? In general, if you just query a base model—if you ask an LLM chat provider—that response is going to be based on those training materials. In some cases, that chat service may invoke some tool to go out and visit a website to get updated information, but the user has very little control over that process and the information that it's going to get. A better approach for referencing critical information is through this RAG process. For the LearnBot, we use RAG to provide high-quality responses that are grounded in JMP documentation.

I want to walk through the RAG process. I don't want to spend too much time here, but it's going to touch on some information that we'll talk about later—or some topics later—so I think it's important to talk through. This is going to be an oversimplification of the process, but I think it'll help understand what's going on. In a RAG system, the query is not directly sent to the LLM. Instead, there's a knowledge base that's added. That knowledge base gets converted into some embeddings that are stored in a vector database, and it's a retrieval system for that information. That knowledge base can be all sorts of documents—PDFs, or Markdown files, or HTML, or tables—and those are all converted into a common format that can be easily retrieved.

Now, when you send a query into the system, it's not going right to the LLM. It first goes to this database. It tries to find some matches. It looks at some of the words—the key terms that are in the query—and it matches those against some key terms in that database and pulls out relevant context. That context can be things like an HTML document, or a page from a PDF, or a script snippet. Then what it does is—and that's the retrieval step, the R in RAG—that context is then appended to that query. You've asked a question, the question has pulled in some additional context, so those are packaged together, and that's the augmentation or augmented steps. You're augmenting your query with some additional context. Now that's packaged and sent to the LLM and your response is generated. That's the workflow, and this is a critical workflow for getting responses that are grounded in the trusted documents that you have in your knowledge base. That's what the LearnBot is. The LearnBot takes your prompt, it attaches relevant context from all the possible resources, repackages those into the LLM, and then provides those higher-quality responses.

All right, so I just want to give one quick example. This is a simple add-in. In this case, I'm going to ask the LearnBot to help me understand a DOE learning path in JMP. What I can do is I can just enter that prompt and click go. I'm going to get a nice response. The response has been configured to be very helpful. We provide those links in line with the text. The nice thing about this framework is that if you see a link that you want to learn more about—in this case, I see that there's a link to the statistics knowledge portal—I can click on that, and that opens up right in the same JMP window. I can scroll through, maybe click on some other links. We're staying in the JMP workflow. Maybe we had a question, or we had some friction point in our analysis, and we've gone to the LearnBot. We've gotten a response. We've dug into the resources; then, when we're all done, we can navigate right back and continue our chat. Maybe we need to have follow-up questions, or we have another topic that comes to mind. We want to keep folks in that JMP workflow by using the LearnBot when they have questions that come up in their analysis. When can you use the LearnBot? You can imagine there's lots of topics that you can ask. If you have any questions about JMP, I would suggest giving the LearnBot a try. Reference materials are continuously being updated to make sure its answers are relevant.

We understand, though, that not all organizations can use the LearnBot. Like Dan said, there's different information security policies or different generative AI policies that companies have; that's why we really want to focus on the infrastructure side as well—not just the LearnBot, but all the knowledge base materials that go into the LearnBot. We can provide those knowledge base materials, and users can deploy those in their own environment. We want to make sure that we meet those JMP users wherever they are in both their JMP use and their AI integration policies. This is just the example of the LearnBot as it is today. A JMP user is in a JMP session, and they've got a question, so they have to send a prompt outside their environment to the LearnBot, who then provides a response back to them. We really set this up as a convenience to our users to make it easy to have their JMP questions answered. This might not be for everyone. I want to talk about two other deployment options that you can use so that you can still get grounded materials or grounded responses using the JMP knowledge base.

The first is enterprise deployment. Many organizations are setting up agents and experts in their organization, and there's no reason that enterprises cannot create or set up a JMP expert. That JMP expert could be their own internal LearnBot. What we can do is provide that LearnBot knowledge base that we have into their own agent system or their own LLM infrastructure, and their JMP user now stays in their own environment. They don't have to go external. Now they can comply with all their internal security policy when it comes to generative AI.

Another alternative LearnBot deployment is just a local LLM. In this case, I've got a really big monitor now that the JMP user is working on, but now they've got JMP, they've got an LLM, and they've got a LearnBot knowledge base all on their system locally. In this case, the LearnBot is right on your computer. There's no external connections. You're not using any tokens. You can customize your knowledge base. For a lot of questions that come in to LearnBot, these are well set up for a local system; there's not a lot of deep reasoning that you might need.

The lightweight open-source LLMs are sufficient for a lot of questions that come in. Also, as hardware and open-source models improve, this is going to be even more effective. All we want to do is show a quick demo of what that might look like. The requirements for this is really just a computer with a GPU, AnythingLLM or another local host with RAG support, an open-source model, and the knowledge base materials. As I was putting this demo together, I was really surprised at how well these open-source models perform on my own computer, which is over 4 years old, and they still perform quite well.

In this example, I've installed AnythingLLM, and I created a LearnBot agent. In AnythingLLM, those agents are called workspaces, so I've created my own LearnBot. You can see I've got a few chats going. I loaded the knowledge base, I selected a model for the embedding side to create that RAG pipeline, and then I selected the reasoning model for the LLM. I can now send a prompt directly to this local LearnBot. They're all local. They're not going outside in my environment, and they don't cost any tokens.

In this case, I asked it a test question about how I can set up a g control chart. What's nice about this is, when we submit that, I don't have to tell this local LearnBot that I'm in JMP to respond as if it's a JMP expert. That's all in a system configuration file, just like any agent might have. I get the response, I get the click paths, and I get some additional information about what I need to make sure I'm aware of, just like you would expect from the LearnBot that we've provided externally. No external models, no API calls to external resources—everything is local. It also gives me those resources just like we had. I can click on those. I get a nice list of the documents that were retrieved. If I wanted to dig in further, I can take a look at those reference documents as well. That, I think, wraps up what I wanted to talk about when it came to knowledge base and the translation layers, and just emphasize that we've got a few ways to deploy the LearnBot in the knowledge base, and we're looking into some other ways to do these sorts of things still.

Let's switch gears and talk about a simple tool. Like Dan said, all of the tools that have AI capabilities are going to be optional and available through the JMP Marketplace. I want to talk about one tool in particular that helps keep you in the JMP workflow when you have questions that come up during an analysis, and that's the report chat. What the report chat does is like having a LearnBot, but instead of sending just a text prompt, it's going to package your text prompt with a report context layer so you can ask specific information about a result. Maybe you want to know what some next steps are, what assumptions went into that analysis, or maybe there's some statistical terms that you've never seen before, and you want a plain-language explanation. All of those things you can do in this tool.

For example, maybe you've done a distribution analysis—you've fit a normal distribution—but you see some statistics here that you don't understand. What you can do is you can go up to these little sparkles now that are on the page. When you click that, you're going to open up a new chat window to help you out. You can put in your prompt—in this case, "Just help me understand this report." Then you go and click Send. Now, when you click Send, it's going to send not just that prompt, but it's going to take the window context, send it to the LLM, come up with a response, and then send it back. You can, of course, scroll through and start to understand different concepts. You can keep the conversation going. It packages all the changes to the report windows. If you run different analyses over time, it'll keep track of everything that's going on and continue your conversation. Once you close this window, it's all gone, but there's a little button here where you can package this up as a journal. If you wanted to record the conversation that you had with the report, you can go ahead and just save a journal.

I've got the example here: in this case, we've got our distribution window that we just had, and on the left side, I've got the log of all of my questions and the responses. It's a nice way to then document that conversation in case you need to remind yourself of what you've learned previously, save it off, or share it with others.

I just want to touch a little bit about what's going on in the back end here. That report window and the prompt are packaged together, but if you don't know anything about these report windows, they're complex objects. We need to distill that information into something a little simpler that LLMs understand. There's a way to convert that report window into something that's called a Markdown file. Markdown is a very efficient way to get structured information; LLMs really like that format. When you have this tool, you get access to the function, so you could use this function itself to convert any report window outside of the add-in if you wanted to do that. Those are then combined together into a single prompt that's then sent to the tool. Once again, this is a new tool that's out; I encourage you to give it a try. Just like the other extensions that are available, you can configure this to work with your own LLM. If you had an enterprise model or a local model, you can point it at those models; you don't have to use the one that's provided by JMP as a convenience.

I want to wrap up and talk a little bit about endpoint connectors. Dan had mentioned this is the plumbing that we're working on for the next version of JMP. I just want to go through what the current state is and then where we envision the next step. When it comes to the plumbing side, each extension today that interacts with an endpoint—in particular LLM endpoints—each extension has to create its own configuration or management interface. JSL, Python, data table schemas, hardcoding—these are all things that you can do to connect that extension to an endpoint, but there's a lot of duplicate work here. Multiple extension developers can create different solutions to connect to the same resource. There's a lot of complexity going on behind the scenes, especially if you want an extension to connect to many different sources. Maybe you want sometimes to send it to one model, or you change models, or you want to send it to your local model. All of these have to be configured separately.

The current state here is that, like I was saying, each extension is configured for each resource, resulting in duplicate effort for both the extension developer and the extension user, and it looks a little something like this: We've got our JMP user. They've installed a number of different extensions. Each of those different extensions has a different configuration schema. Even if two extensions connect to the same endpoint, the configuration has to occur multiple times, even if they're using the same credentials, the same endpoint location, things like that. What we want to do with the endpoint manager is provide a common framework for connecting JMP extensions with different resources. We'll have a two-part system. We'll have the connector packages, so you can think of those like the data connectors. The connector packages are loaded into an endpoint manager, and then extension users can connect to various resources through that endpoint manager. It'll look something like this: you've loaded Connector A into Endpoint Manager, and it connects with Resource A, and you have B and C. Now all of the extensions connect directly to those connectors. It just keeps everything clean—less duplicated effort for both the user and the extension developer.

All right, wrapping up with the delivery: like Dan said, all of our extensions or anythingLLM integration or AI-integrated is going to be in the JMP Marketplace. If you want to keep up to date with any LLM-integrated extension, you can go to the Browse All Marketplace Extensions link and click the LLM Integration tab. Currently, there's a few here. We've got more in the pipeline, so keep checking back to see how we're thinking about how we can connect users with those LLMs and ways to enhance their workflows.

I just want to summarize and say that infrastructure approach to AI integration is driving our roadmap. We want to enable our customers to drive AI integration on their own terms in whatever implementations they want through the knowledge base, that translation layer, plumbing tools in the JMP Marketplace. We also want to hear from you—the JMP Marketplace Q&A and review sections, great way to provide feedback on the direction that we're going with the LLM-connected extensions that we're publishing. The EA program is a great place to go if you want to test out the Endpoint Manager or the endpoint connectors. Then, of course, the JMP wishlist: if there's something that you want to see in a future version of JMP, please submit to the JMP wishlist.

I also want to give one plug to another talk that's coming up in this Discovery Summit: it's from Chris Pillsbury at IDEXX, who's going to talk about going from natural language prompts all the way to JMP Live. I encourage you to take a look at this talk as well. With that, I'll wrap up. Thank you for watching.