Microsoft wants AI agents to draw charts you can actually click

Microsoft Research has released Flint-interactive, an extension of the Flint language that lets an AI agent build charts you can click, filter and highlight. For teams building data assistants, the key point is that a selection in the chart can flow back into the conversation as input.

The agent describes the chart's behavior and the compiler does the rest

On October 22, Microsoft Research introduced Flint-interactive as a language for interactive visualizations built on top of Flint. Charts are meant to respond to clicks, filtering, zooming, highlighting and links to other charts. The author does not write low-level code. They describe which event the chart should react to and how it should change.

The core idea is a split in responsibilities. The compiler turns clicks, drags and key presses into semantic events that say which element and which data the action touches. The user or the agent then maps those events to update operators, such as setting a style, adding a label to a point or moving the viewport. The compiler handles the translation to the rendering library.

In chat, this runs through Flint-MCP and MCP Apps. The agent generates an interaction_spec alongside the chart spec and renders the interactive chart inside the conversation. For applications there is Flint Interactive Canvas, which emits events so that a click on the chart can filter a table or change application state. A programming API covers custom interactions.

The chart stops being output and becomes input for the next question

Flint shipped this summer as an open source language that agents use to produce charts for Vega-Lite, ECharts or Chart.js. According to the project site, it now supports 52 chart types and 23 interaction presets. The July release focused on making a static chart look good. This one goes a step further: making the chart something you work with.

For users, the most interesting part is the feedback loop. Select a group of countries or a point in time, and the agent receives that selection as context. The next question no longer has to start by describing what you mean. The chart becomes a way to point at something.

For developers, the benefit is different. The agent does not have to write and debug its own JavaScript for every interaction. Microsoft itself admits that repeated rounds of coding, debugging and fixing eat up tokens and time. A shorter spec means fewer places for things to break.

Only the authors know the savings and the reliability so far

The post promises lower cost and better reliability but shows no measurement. There is no token count per finished chart, no rate of broken interactions and no comparison with an agent writing code directly. For the original Flint, Microsoft at least published LLM-judge scores. Here there is only a description and demos.

The second limit is vocabulary. An agent will reliably handle what the presets cover. Anything beyond that needs the programming API, which brings back the very code the language tries to avoid. One of the authors is an engineer from the Power BI team, but the announcement says nothing about Flint-interactive appearing in Microsoft's commercial products.

Adoption by tools outside Microsoft will decide this

The first signal is whether agents and chat environments outside Microsoft's lab start using Flint-MCP. The second is community presets: the authors invite designers to propose new interactions on GitHub. If the vocabulary grows, there will be fewer reasons to reach for custom code.

The third signal is measurement. A comparison of tokens and error rates against direct code generation would turn a demo into an argument you can take to the head of a data team.

Lilith's verdict

Microsoft has swapped the agent's paintbrush for a pointer: the user taps the chart and the agent knows which country they mean. How many tokens that saves, the authors are keeping to themselves, showing only the pretty pictures.