Posit's AI Packages Explained: A Decision Map for R and Python Developers

Posit has been shipping AI packages recently. If you've tried to keep up but ended up more confused than when you started, you’re not alone.

If you search for something like "Posit AI tools" you’ll see packages like `ellmer`, `chatlas`, `ragnar`, `querychat`, `shinychat`, `vitals`, `mcptools`, `btw`, `chattr`, `mall`, `gander`, `chores`, `lang` - and that's before you hit the "also worth knowing" tier. Each one has its own docs page, its own GitHub repo, and its own set of use cases that partially overlap with the others. All tools are great, but there isn’t a clear map you can follow if you’re just starting out.

This article is that map. In about 10 minutes, you'll know what each package does, how they fit together, and exactly where to start based on what you're trying to build.

Let's go from the ground up.

ellmer and chatlas: The Foundation of Posit's AI Stack

Before you look at any other Posit AI package, you need to know about these two. Every other tool we’ll mention either builds on top of them or connects to them.

ellmer

ellmer gives R a unified interface to LLMs. You create a chat object with a single constructor function: `chat_openai()`, `chat_anthropic()`, `chat_google_gemini()`, `chat_ollama()`, and many more and interact with it through methods on an R6 class. The same code works regardless of provider; switching is a one-line change.

ellmer’s chat objects are stateful: they retain the full conversation history, so each response builds on the previous exchange. Two features make it especially powerful for data science: tool calling (register R functions the LLM can invoke mid-conversation) and structured data extraction (define a schema, get back clean typed R objects instead of raw text).

ellmer also supports streaming, async operations, multi-modal input (images), batch processing, and interactive chat via `live_console()` and `live_browser()`.

Docs: https://ellmer.tidyverse.org

chatlas

chatlas is the Python equivalent, designed to stay closely in sync. One unified interface across providers, tool calling via Python function registration with automatic schema generation from type hints, structured output via Pydantic models, and full async support.

Docs: https://posit-dev.github.io/chatlas/

How to choose between ellmer and chatlas

The two packages stay closely in sync by design. If you've used ellmer in R, chatlas will feel familiar in Python. And if you're building something that uses both languages - say, a Shiny for Python app backed by existing R analytical code - both packages speak the same conceptual language.

So, pick ellmer if you're in R, chatlas if you're in Python. With that decision made, the rest of the stack can start to make sense.

The Rest of the Stack: What Each Package Does

You’ve set a strong foundation in the previous section. Now, let’s add some sprinkles on top.

shinychat - Chat UI for Shiny

shinychat gives you a ready-made chat UI component for Shiny apps, both for R and Python. It means you don't have to build the chat interface from scratch. Just add the package into an existing Shiny app, wire it up to an ellmer or chatlas chat object, and you have a working conversational interface with streaming responses, tool call displays, and bookmarking.

In a way, it’s like a front end to ellmer's back end.

Docs: https://posit-dev.github.io/shinychat/

querychat - Natural Language to SQL

querychat lets users ask questions about tabular data through natural language. The LLM doesn't interact with the raw data directly - instead, it generates a SQL query, querychat runs it against a local DuckDB instance, and returns the result. The generated SQL is always visible, so users can verify exactly what ran.

It works as a drop-in Shiny component, but also supports Streamlit, Gradio, and Dash. The package is available for both R and Python.

Docs: https://posit-dev.github.io/querychat/

ragnar - RAG for R

RAG stands for Retrieval-Augmented Generation. It’s a technique where you give an LLM access to a knowledge store of documents so it can ground its answers in specific content rather than guessing from training data.

ragnar handles the full RAG pipeline in R, from document ingestion, text chunking, embedding generation, storage in DuckDB, to retrieval. It integrates directly with ellmer - you register a retrieval tool on a chat object, and the LLM can pull relevant document chunks on demand during a conversation.

Docs: https://ragnar.tidyverse.org

mcptools - Model Context Protocol

MCP stands for Model Context Protocol - an open standard that lets LLMs communicate with external tools and services through a common interface.

mcptools implements MCP for R in both directions. As a server, it lets MCP-compatible apps like Claude Desktop or VS Code Copilot run R code in your active R sessions. As a client, it lets you register third-party MCP servers with ellmer, so your Shiny or querychat apps can pull in context from external sources.

Docs: https://posit-dev.github.io/mcptools/

vitals - LLM Evaluation

Once you've built an LLM-powered app, how do you know if it's actually working well? That's what vitals is for. It's an evaluation framework for R built specifically for ellmer users. It lets you measure how well your LLM product performs across a labeled dataset of inputs and expected outputs.

You define a dataset, a solver (your ellmer chat), and a scorer, then run the evaluation. vitals tracks accuracy, cost, and latency, and writes logs you can explore in an interactive viewer.

It's the closest thing to automated QA for your LLM apps.

Docs: https://vitals.tidyverse.org

btw - Context Toolkit

Connects R environments with LLMs. Gathers session context (data frames, package docs, session info), provides an in-IDE chat assistant, and the recommended MCP server for R. Use `btw_mcp_server()` to give coding assistants access to your R environment.

Docs: https://posit-dev.github.io/btw/

Additional packages worth knowing

These tools are more specialized or still early-stage, but good to know about:

• mall - Runs batch NLP operations (sentiment, classification, summarization) over data frame columns using LLMs. It’s available for R and Python and comes in handy for labeling or enriching tabular data at scale
• Positron Assistant - An AI coding assistant built into Positron, Posit's new IDE for R and Python. It's aware of your live session state, such as loaded data, plots, console history, so its suggestions are more relevant than a generic coding assistant
• Databot - A Positron-only, experimental EDA agent. You give it a high-level instruction, it writes and runs code to explore your data, and you review the results. It’s still in research preview and not production-ready, but worth watching
• shinyrealtime - Integrates OpenAI's Realtime API with Shiny for voice-enabled apps. It’s built for R and Python.
• ggbot2 - A voice assistant for ggplot2. You can talk out loud to describe the visualization you want, and it generates the plot and the R code. It’s built on shinyrealtime and requires an OpenAI API key.
• chores - Connects ellmer to your editor for automated code transformations.
• gander - Inline AI code assistance with R environment awareness.

Which Packages Do You Actually Need? Start Here.

Most people don't need the whole stack. It’s better to pick the path that matches what you're trying to build. Here are three to choose from.

Path 1: I want AI inside a Shiny dashboard

Start with ellmer (R) or chatlas (Python) to handle the LLM connection, then add shinychat to drop a chat interface into your Shiny app. Those two packages get you a working conversational UI with minimal setup.

If you want users to ask questions about a dataset inside the same app, add querychat on top. It handles the natural language to SQL translation and fits in as a Shiny component next to your existing dashboard elements.

Path 2: I want chat-with-data that's verifiable

Start with querychat on its own. You don't need ellmer or shinychat to get started - querychat has its own app interface and works out of the box once you point it to a data frame. Every answer comes with the SQL that produced it, so users can verify the result themselves rather than trust the model.

When you're ready to embed it in a full dashboard, it drops into Shiny as a component. It also works with Streamlit, Gradio, and Dash if you're building on the Python side.

Path 3: I need context-aware answers from my own documents

Start with ragnar to build a knowledge store from your documents, such as internal reports, SOPs, clinical protocols, whatever you need the model to reference. Then register the retrieval tool on an ellmer chat object so the LLM can pull relevant chunks during a conversation.

If you want external services or tools to feed into that same chat - say, a database, an API, or another system - mcptools connects them to ellmer through the Model Context Protocol.

It's the right path when "I need the LLM to know things that aren't in its training data" and "I need it to pull from multiple sources at once" are both true.

Posit's AI Stack in Pharma: AI in Clinical Dashboards

Pharma teams working with clinical trial data face a specific version of the problem this whole article is about. The data is complex, the regulatory requirements are regulated, and the people who need answers - statisticians, clinical operations leads, medical reviewers - aren't always the ones who can write scalable R or Python code to get them.

That's exactly the gap this stack was built to close.

A clinical dashboard built with Shiny is already a common pattern in pharma. What's changing is what those dashboards can do.

• With ellmer handling LLM integration and shinychat giving you chat interface, a statistician can ask a question like "show me the adverse event rate for the treatment arm in patients over 65" and get a direct answer - without writing a single line of code. Under the hood, querychat translates that question into SQL, runs it against the trial dataset, and returns a verifiable result with the query visible. That last part matters in a regulated environment.
• The ragnar + ellmer combination adds another layer. When the LLM needs to reference a Statistical Analysis Plan, a protocol amendment, or an internal SOP, ragnar retrieves the relevant sections from a document store and feeds them into the conversation. The model's answers are grounded in your actual documents.

The result is a reporting environment where clinical data, company documents, and validated analytical code work together through a single interface. It’s not yet another chatbot included for no apparent reason.

We've written about what this looks like in practice through the lens of TealFlow, Appsilon's tool for automating clinical reporting applications. If you're a developer building these systems or a decision-maker, read our perspective on automating clinical reporting apps with AI and {teal}.

Summing up Posit AI Packages

Posit's AI package ecosystem is big, but it's not complicated once you see the structure.

Packages like ellmer and chatlas are the foundation. shinychat, querychat, ragnar, mcptools, and vitals each solve one specific problem on top of that foundation. And the three start-here paths we discussed give you a clear entry point based on what you're actually building.

If you want to go deeper, we've put together an extended guide that covers each package in more depth, including code examples. And if you're working in pharma and want to see what an AI-native clinical reporting app looks like in practice, TealFlow is worth a look.

You can also download Appsilon's Shiny dashboard templates - a collection of open-source, fully customizable templates to help you start building Shiny apps faster.

Frequently Asked Questions

Do I need to know R to use Posit's AI packages?

Most of the core packages - ellmer, ragnar, shinychat, querychat, vitals - are R-first. chatlas and querychat are available for Python as well, so Python users aren't left out. If you're starting from scratch, some familiarity with either language helps, but you don't need to be an expert to get a basic app running.

Can I use these packages with any LLM provider, or am I locked into one?

You're not locked in. ellmer and chatlas both support a wide range of providers, including OpenAI, Anthropic, Google Gemini, Azure OpenAI, AWS Bedrock, Databricks, and Ollama for local models. Switching providers is usually a one-line change, so you can experiment with different models without rewriting your app.

Are these Posit AI packages production-ready?

Most of the core stack - ellmer, chatlas, shinychat, querychat, ragnar, and vitals - are available on CRAN and actively maintained by Posit. mcptools is still marked as experimental and its interface may change. Databot is explicitly in research preview and not recommended for production use yet.

We work in a regulated pharma environment. Is it safe to send clinical data to an LLM

querychat is designed with this in mind - it never sends raw data to the LLM, only schema metadata like column names and types. The model generates SQL, which runs locally against your data. For document-grounded answers with ragnar, only retrieved text chunks are passed to the model, not your full document store. That said, your organization's data governance policies should always drive the final decision on what goes outside your environment.