Microsoft Research has released Flint-interactive, an extension of its Flint chart language that lets AI agents produce charts you can click, brush, filter and link to tables or text, without writing low-level interaction code. In the October 22, 2026 Microsoft Research blog post, the team describes a compiler that turns raw clicks and drags into semantic events, which the agent maps to chart update operators in a short specification.
For readers who followed the original launch, this is the follow-up to Flint, Microsoft's chart spec for AI agents. Below: what changed, how the model works, how to try it, and what Microsoft has not shown.
TL;DR
| Question | Answer |
|---|---|
| What is it? | A language for interactive charts built on Flint |
| Core idea | Compiler turns raw input into semantic events; the author maps events to update operators |
| Where it runs | Chat or canvas via Flint-MCP and MCP Apps; apps via Flint Interactive Canvas |
| Presets | Includes linked brushing and more in an interaction gallery |
| Custom interactions | Programming API with triggers and handlers |
| Evidence of benefit | Design argument and examples; no published reliability benchmark |
Quick recap: what Flint already was
Microsoft Research open-sourced Flint earlier in 2026 (our post of August 1 covers release v0.4.0 of July 24) as a JSON-based visualization language built for AI agents. As we reported at the time, it compiles a compact chart spec into several backends, including Vega-Lite, ECharts, Chart.js, Plotly and Excel, and ships an MCP server and an agent skill so that hosts such as Claude Code can call it as a tool. The first version solved the question of how an agent describes a chart reliably. It did not solve what happens after the chart is on screen. Flint-interactive is the answer to that second question, and it reuses the same compiler, which is why Microsoft frames it as "a language for creating interactive data visualizations on top of Flint."
An example of the workflow
To make this concrete, imagine you ask an agent in chat to chart life expectancy against income by country and then say "let me select a group of countries in the first chart and see where they sit in the second." In the Flint-interactive model, the agent does not write event listeners. It emits the chart spec plus an interaction_spec that picks the linked-brush preset. When you drag a rectangle, the compiler resolves the drag into a semantic event, something like "these countries were selected," and the preset maps that event to a style update on the other chart. If you then ask a follow-up about the selected group, the post says the selection can be passed along as context to the next turn, which closes the loop between exploring a chart and asking the model a question about what you found.
The problem Microsoft is pointing at
Agents can already generate reports with charts, but static charts are a dead end when you want to explore. Microsoft's authors say users want to zoom into details, compare across charts, or highlight related text from a chart selection. They name two obstacles even with capable frontier models:
- High generation cost. Agents rarely get a satisfying interactive chart in one turn, and repeated rounds of reasoning, coding and debugging burn tokens and time.
- Reliability. Expressive interactive charts easily end up with poor layouts or broken interactions, and fixes can introduce new problems.
The authors also say built-in interactions in some visualization libraries are not expressive enough for bespoke charts, and trace the problem to the lack of "an expressive yet high-level language to specify visual interactions." That is a claim about the cause, not a measured result.
How Flint-interactive works
Flint Canvas is described as a state machine that tracks user interactions and manages visual rendering state. The design separates two concerns:
- Visual logic, handled by the compiler. It resolves raw triggers (clicks, drags, key presses) into semantic events that identify chart elements and data, and translates update operators into rendered canvas changes, including hit testing and low-level updates.
- Interaction logic, written by the user or agent. You map semantic events to update operators, such as set style to highlight data, set annotation to label a point, or set viewport to pan or zoom. The same events can also update external tables, widgets or application state.
The pitch is that the agent never touches renderer-specific marks. In prose: instead of writing code that finds the pixel under the cursor, works out which data row it represents and redraws, the agent states "when a country is selected, highlight it everywhere and label it," and the compiler does the rest.
Microsoft's first example uses a Gapminder dataset: brushing a group of countries in a 1952 scatterplot highlights the same countries in a 2007 plot, with a preset called linked-brush.
Connecting charts, text and tables
Because events and updates compose, the same model links charts to other page elements. In Microsoft's second example, clicking a row in a table highlights and annotates the matching bubble in a chart, and clicking the bubble selects the row.
The post says this supports data stories and dashboards where an action in one view can update charts, documents, widgets or application state in another. A fourth example, based on a technique called DimpVis, lets a user drag a point along a time path to see how temperature and precipitation change for several cities, built with the programming API.
Watch the official demo
Three ways to use it
Microsoft lists three audiences:
- Chart users in chat. Set up Flint through Flint-MCP and MCP Apps, per the MCP setup guide. With the latest release, you tell your agent what to chart and which interactions you want. It can generate an
interaction_specalongside the Flint chart spec and render the interactive chart in the conversation. The post says users can also select items and pass that context to follow-up turns. - App builders. Use Flint Interactive Canvas in a dashboard or data story. Your app handles semantic events (for example, to filter a table) and sends update operators back to change the chart. Microsoft suggests sharing the interaction-author skill with your coding agent.
- Interaction designers. Browse the bespoke examples, design a new interaction and propose it as a preset on GitHub.
For the plumbing behind chat integration, see our explainers on what MCP is and how to build an MCP server, and on agent skills, since the interaction-author skill follows that pattern.
Where this sits among agent visualization tools
Flint is one of several attempts to make agent output richer than text. Our coverage of alphaXiv's figures skill for agents shows a different approach: generating figures for research. The Flint approach is declarative, a spec compiled by a runtime, which makes agent output easier to validate than free-form code. When the original Flint launched, Hacker News commenters debated whether agents need an intermediate language at all, or can write Vega-Lite or Plotly directly; that debate applies equally here, and Microsoft's argument is that interaction logic is exactly where direct code generation is expensive and fragile.
What Microsoft has not shown
- No reliability or cost benchmark. The post states benefits (fewer layout and debugging problems, lower cost) but publishes no success rates, token counts or comparison with agents writing custom interactive code.
- Preset coverage is the limit. The easiest path is the interaction gallery and presets. Anything unusual requires the programming API, which is back to writing code.
- Host dependence. Chat rendering depends on MCP Apps support in your host. Check that your client supports it before planning around the feature.
- Security surface. Interactive artifacts rendered inside a conversation, and tools exposed through MCP, are components worth reviewing under your own agent policies. If you run agents with tool access, AgentBeam, the agent security platform from the explainx.ai team, can help stop agents before they take dangerous actions.
Who should try it
| You are | Try it? |
|---|---|
| Building a data-analysis agent | Yes, test whether interaction_spec generation is more reliable than your current code path |
| A user exploring data in chat | Yes, if your host supports MCP Apps |
| Building dashboards with fixed requirements | Maybe; conventional libraries may suffice |
| Needing audited, reproducible reports | Evaluate carefully; interactive state is harder to snapshot |
A suggested evaluation
If you want to judge the claims yourself, take five or ten interactive requests your users actually make (linked brushing, filter-by-click, a table-to-chart link, a time scrubber) and run each through your agent twice: once asking it to write the interaction in your current charting library, once with Flint-interactive. Count turns to a working result, tokens used, and broken interactions found by a human tester. That is the evidence Microsoft's post does not provide, and it will tell you whether the compiler really absorbs the debugging burden.
Related reading
- Flint: Microsoft's chart spec for AI agents
- alphaXiv figures skill for agent visualization
- What is MCP?
- Build your first MCP server
- What are agent skills?
- Official: Microsoft Research blog post and Flint project page
Details are accurate as of October 22, 2026 and come from Microsoft Research's announcement.
