Show HN: Microsoft releases Flint, a visualization language for AI agents (microsoft.github.io)

350 points by chenglong-hn ↗ HN
Data visualizations are the bridge between user and data.

But building AI agents that can generate visualizations reliably can be very tricky:

- simple chart specs can be reliable, but generated charts are often of low quality due to reliance on system defaults; - complex chart specs with explicit details can produce good-looking charts, but they are verbose and agents can struggle with reliability

We figured out it is a limitation on the language issue (not just AI capability thing) -- current visualization languages are a bit too low-level for AI agents, requiring them to explicitly make visual decisions that are supposed to be handled by a good compiler. Flint is a visualization intermediate language to address this issue, allow AI agents to solve this last-mile human-agent interaction problem. It provides a simple semantic-type based specification, and contains a layout optimization engine that can produce good-looking charts (filled with derived low-level details) from simple high-level specs. The result is also very human understandable and adaptable. Flint powers data formulator for generating visualizations (another open source project from microsoft https://data-formulator.ai/).

Flint is available open source, and we built a MCP server that you can directly plug flint in your favorite agent app to play with data.

54 comments

[ 3.5 ms ] story [ 90.3 ms ] thread
> requiring them to explicitly make visual decisions that are supposed to be handled by a good compiler

Isnt graphviz there for the same reason?

Edit: I see it is using JSON as the declaration language, I am OK with llms being "good at json" but a syntax also consumable by humans it is not!

It compiles into Echarts, but echarts already has a JSON co figuration spec
The charts are very nice, and I think the visualisation layer for LLMs is a very interesting problem.

I’ve been building https://smalldocs.org for this exact reason. It’s an office suite for AI agents - but my main use case is giving a cli based LLM the canvas to express itself - charts, mermaid diagrams, etc. I’ve extended it a bit further to be a format for all types of work so the agent can embed slides and spreadsheets in a document.

Sample document: https://smalldocs.org/blogs/what-is-a-smalldoc

Source: https://github.com/espressoplease/smalldocs

This is cool to see from a research team. A few weeks ago I was exploring a similar idea with ntcharts, where a user or LLM can specify a chart in a Golang or JSON object...

and then that spec would be rendered either to a Bubble TUI via NTCharts or to HTML/SVG via ECharts. That Echarts HTML could be naturally served by a Golang http service.

But Flint goes much deeper with semantic layers and settings optimizations. Perhaps a NTChart, or whatever terminal chart, could be a rendering target? I'll add it to the list to explore...

https://github.com/NimbleMarkets/ntcharts/blob/spec/spec/REA...

Forget AI agents, this DSL is better even for humans. Cool project!
Is there a specific explanation about how this is better or different than vega itself? https://vega.github.io/vega/docs/specification/

My understanding is that Vega was already an expressive DSL for visualizations and its probably already well spread through LLM training data.

I was wondering the same for vega-lite, which is relatively high level, declarative, and looks similar to their syntax.
This is pretty crazy, literally built something almost exactly like this for a project I'm working on (a local-first AI agent that does work on folders while you sleep). Basically going from JSON "Lego blocks" to full reports (including charting, though a subset of what Flint offers). And with post-generation validation and retry steps.

Functions extremely well and the result is a very clear (and consitent) human-readable "output layer." Cool idea, fun to see people converging on similar concepts in the space.

> simple chart specs can be reliable, but generated charts are often of low quality due to reliance on system defaults; - complex chart specs with explicit details can produce good-looking charts, but they are verbose and agents can struggle with reliability

N of only a few of us working on an analytics agent, I don't think we've been finding this to be the case. We've been impressed with just how good LLMs (even smaller open weight models) are at using Python and R for visualization. Often any shortcomings go away if we iterate a bit to about ambiguity. Are there any threads of research that could better support this claim or highlight where issues might be?

There’s an emerging pattern in agentic systems and this project is a great example.

A deterministic layer like a compiler or generator of code with some kind of IR that the LLM generates and feeds it with.

I feel we will be seeing this more and more in the near future.

Yes, this has been the pattern for agentic systems since the beginning: permissive generation, that retries over and over until it gets the right size shape through the hole, and the input validates.
I'm all in on this idea. Every piece of agentic coding I have done in the last month has been via an intermediate representation. Iteration is done in the IR layer mainly. It's remarkable how close you can get to a deterministic coding output using this methodology.
"For AI agents". I understand why everything needs to be marketed in this way, but it's just ... an easy-to-generate language for expressing charts. That's impressive! That's useful.
This can’t be said enough. “Good for Agents” just means self-documenting, obvious ergonomics, save defaults, succinct (or controllable) output, programable interfaces, … all of which support human users too!
And as per packages, built on top of existing charting libraries.
Thank you for summarizing it this way. All their flowery language (esp from OP) seems like long for "we figure out how the chart should look based on its data". From their page:

> Instead of requiring verbose low-level parameters such as scales, axes, spacing, and layout, the Flint compiler derives optimized chart settings from the data, semantic types, chart type, and encodings.

(comment deleted)
(comment deleted)
(comment deleted)
I don't really understand the point of this, I feel like LLMs have been able to one-shot matplotlib since GPT 3.5. I have extensively used LLMs to do data viz and haven't run into any problems. What is a specific instance where an agent struggles to generate a visualization and Flint solves it?
>Instead of requiring verbose low-level parameters such as scales, axes, spacing, and layout.

Ok, Microsoft is conflating two different things here: LLMs don't really care about code being low level and verbose, they can read things like Assembly and SPIR-V just fine: visualization is the real issue in that LLMs have no natural understanding of spatial composition through visual comparison because they literally "see" things differently than humans, so the way to get around that is provide them with "visualization" in code form that they can easily reason about and understand, so basically anything that's not deeply nested and has hidden states that they have to reason about.

Also, Flint being stringly typed in JSON is a decision that I don't think I agree with. Looking at the actual spec, this could have just been a normal, human usable TypeScript library, and it would have been 100x better. Using their own example (excuse the formatting):

type SemanticType = "Category" | "YearMonth" | "Profit";

type ChartType = "Heatmap" | "BarChart" | "LineChart" | "ScatterPlot"; // extend as needed

interface ChartEncodings { x: string; y: string; color?: string; size?: string; tooltip?: string; }

interface ChartProperties { colorScheme: string; [key: string]: unknown; // allow other optional properties }

interface ChartSpec { chartType: ChartType; encodings: ChartEncodings; chartProperties: ChartProperties; }

type SemanticTypes = Record<string, SemanticType>;

interface ChartConfig<TData = Record<string, unknown>> { data: TData; semantic_types: SemanticTypes; chart_spec: ChartSpec; }

// The actual typed object literal: const chartConfig: ChartConfig = { data: {}, // replace with your actual data shape/type semantic_types: { game: "Category", period: "YearMonth", newUsers: "Profit", }, chart_spec: { chartType: "Heatmap", encodings: { x: "period", y: "game", color: "newUsers", }, chartProperties: { colorScheme: "redblue", }, }, };

EDIT:

Went and actually looked at the source instead of just eyeballing it from the docs, and it was a lot more complete and sophisticated than my assumed mockup already.

Core complaint (string-keyed JSON vs. a real generic authoring surface) still stands, but the specific types I posted aren't what Flint has. My bad.

This happens if a company has a CEO who presumably can no longer successfully go to the toilet without AI assistance.

Agents, npm, typescript, MCP. All buzzwords are there. Will anyone look at the slop charts? Of course not, the tokens are the goal.

MSFT stock is at 2024 levels. Maybe someone should produce a flint chart and present the agentic work to Nadella. No one buys this AI slop any more.

Nice to stumble over this thread.

I'm not sure if Flint is the right tool for me. I'd like to have a tool that expresses code in visual form for me. For example, right now I need to reverse engineer some code for debugging purposes.

I already found out there are three tasks:

    * Task one fills task two's queue and waits for an event to get notified
    * Task two reads from its queue, forwards elements to task three's queue.
    * Task three reads from its queue and sends a success/fail message back to task two's queue
    * Task two then notifies the waiting task one.
Visually it's easily expressed: 3 bubbles lined up with 2 connections between the neighboring ones.

Which ML tools suited best for that?

Probability of an MS project existing in the next N days:
This is a valuable method of closing the gap in making LLM results available in a good visual form. The idea of viewing the charting process as the last step—where the AI deals only with high-level semantic specifications as opposed to all the low-level visual details—makes so much sense. I'm interested to know what the layout optimization engine does: can the developers inject the desired limitations for some cases, or is the layout design process a black box? It's good to see you've made it open-source!
Flint: because watching an AI agent work is like watching a Roomba navigate — you need a visualization to understand why it spent 20 minutes in the corner