I've made charts for research, for work, and for content creation, and I've been at it for years. I still spend way too much time tweaking them.

So I asked myself a simple question: what if I wrote my chart decisions down as rules and gave them to an agent? That idea became Chartify. It's a Streamlit app backed by a Snowflake Cortex Agent, and the agent follows 15 rules for picking the chart type, order, and color. I distilled them from years of my own charts, five data visualization books, and a widely read paper on figure design, so the agent starts where I'd start.

Along the way, I learned that getting the agent's recommendation right was only half the job. The other half was making sure the chart on screen actually matched it.

All of the code is in the companion repository, so you can run Chartify yourself or adapt its rules to your own data. Here's what this article covers:

1. The problem: why chart decisions are hard to hand off, and the sorting bug that shaped the rest of the project.
2. Building the agent: what it should recommend, the rules it follows, and the tools it uses to check its own recommendation.
3. Testing the agent: what it recommended for a set of example questions, with screenshots of the resulting charts.
4. Checking the chart on screen: the sorting fix and the Evaluation tab that checks what was actually plotted.
5. Wrapping up: how the pieces fit together, what the demo does not check, and what I learned.

Ask an agent to chart revenue by region, and it has to make three decisions:

Each of these options produces working code and a chart. But are they useful to users? Perhaps, only some of them are.

Picking the useful ones takes judgment, and that judgment has to come from somewhere. For Chartify, it comes from an agent following my rules.

The word "agent" gets thrown around a lot, so here's what I mean by it.

Most "AI apps" send a prompt to a model and show you whatever comes back. That's what I'd call AI-powered. An agent does more: it takes actions, like running a query or calling a tool, looks at the results, and decides what to do next.

My first version of Chartify was AI-powered. One model call, a hand-written description of the columns, and some chart settings back. The current version is an agent. You ask a question in plain English, like "Show me revenue by region." The agent queries your data in Snowflake, proposes a chart, and validates it against the data. If the check fails, it gets one chance to revise. Then it submits the chart settings along with the rules it used, and the app draws the chart.

My most useful lesson didn't come from the agent getting something wrong. It came from the agent getting everything right. I asked for revenue by region. The agent recommended sorting regions from highest to lowest, exactly what the rules say. The chart showed them in alphabetical order:

Figure 1. A recreation of the bug using the app's sample data. The highlight is there, but you have to scan every bar to find out that North America leads and Nordics is a close second.

The agent was fine, but the rendering code wasn't. That bug taught me to check what the app actually sends to the renderer as well as what the agent recommends. Here's the same request after the fix, with the ranking you can read top to bottom:

Figure 2. Chartify responds to "Show me revenue by region and highlight North America." The agent queries Snowflake tables to guide its chart recommendation, while the app draws the chart using separate local sample data.

Building Chartify's agent came down to three layers: what it should recommend, the rules it follows to decide, and the tools it uses to check itself.

Before writing a single rule, I had to define "the right chart." Even the revenue-by-region example hides two separate decisions: which chart type to use, and how to order and emphasize the data inside it.

Choosing a Chart Type

The first decision is the chart type. It has one job: help the reader answer the question. Revenue over time? You need a chart that makes the trend obvious. Ranking eight regions? You need a chart that makes the values easy to compare.

Choosing Sort Order, Color, and Emphasis

Picking the right chart type is only the first decision. A bar chart can show regional revenue, but sort it alphabetically and the ranking disappears. Give every region its own color and nobody notices North America, even when that's the whole point of the question. The agent needs rules for ordering and emphasis, not just chart selection.

So the agent has to know two things: what to draw, and how to arrange it. Where do the rules for that come from?

The good news: there's no shortage of advice. I drew on several well-known data visualization books and a widely read paper on figure design, listed in the Further Reading section at the end.

The hard part was deciding which advice an agent could actually use.

Choosing Which Chart Types to Support

"Make a good chart" is useless as an instruction, because an agent can't follow it. So I narrowed the problem until every piece of advice could become a specific rule.

Chartify supports eleven chart and table types over sample datasets for revenue, signups, correlations, budgets, and rankings. With the scope fixed, every rule can name the situation it covers and the chart it calls for.

Table 1. The chart and table types Chartify supports, and when each is used.

You'll notice four of these are bar charts, and that's on purpose.

Comparing bar lengths along a shared baseline is one of the easiest ways for people to compare values. So the rules keep the bars and change only how they're arranged: natural order, sorted by value, stacked into a whole, or diverging from zero.

That makes bar charts a good worked example of the rules in action. And the idea carries over to any chart family: start from what the reader needs to compare, then pick the variation that answers each question.

Writing the Rules the Agent Follows

A list of chart types doesn't tell the agent which one to pick. Every rule needs two things: a condition that triggers it, and often an exception that overrides it.

Here's an example with two questions, both comparing categories:

A quick note on the numbers you'll see. The conditions and cutoffs are my own interpretation of the literature rather than a universal standard. Chartify uses pie charts for up to three categories and stacked bars for four or five, so the agent never has to choose between them on its own.

Are three and five the right numbers? Not necessarily. They're arbitrary cutoffs, and I picked them because they're simple to remember and easy for an agent to apply. If you prefer a different threshold, it's a one-line change.

Here's how to read the rules. The opening lines handle requests for raw data, which return table with no rule IDs. Rules 1 to 8 map the shape of a question to a chart type. Rules 9 to 12 handle emphasis, color, and ordering. Rules 13 to 15 set constraints: minimal decoration, zero baselines, and a caption that actually says something. The last two lines tell the agent how to report the rules it used and keep its explanation short.

Two terms need a definition. The data-ink ratio (rule 13) is the share of a chart's ink that shows data rather than decoration, so gridlines, borders, and 3D effects lower it. The Lie Factor (rule 14) compares how big a difference looks with how big it really is. Start a bar axis at 90 instead of 0, and revenue of 100 versus 110 looks like a 2x gap.

Here's the full instruction text the agent follows:

Remember the signup-rate-by-weekday example from earlier? That exception lives in rule 2: a ranked comparison gets sorted by value, unless the categories have a natural order like days of the week, in which case they stay in that order.

Rules tell an agent what to recommend, but they can't tell it whether the data supports that recommendation. For that, the agent needs to act on the data and check.

That was the problem with my first version. It was a single AI_COMPLETE call with a JSON schema, working from a column description I wrote by hand. It had no way to look at the data and check its own assumptions.

Querying Snowflake Data and Validating Chart Settings

To give the agent a way to look at the data and check its own work, I rebuilt the recommendation step as a Cortex Agent with three tools. The agent is instructed to query the data, validate its proposed chart, and submit the settings the app needs.

The query tool relies on a semantic view: a description of tables in business terms that Cortex Analyst uses to turn a plain-English question into SQL. It tells Analyst which columns are dimensions to group by, which are measures to add up or average, and how the tables join. The validation tool is a stored procedure, a function that lives in Snowflake and runs there.

Figure 3. The tool sequence the agent is instructed to follow: query, validate, then submit. If validation fails, the agent can revise its proposal and check it once more.

Each tool has a narrow job. The first gathers facts about the data, the second checks the proposed chart against those facts, and the third hands the final settings back to the app. Table 2 lists them by name.

Table 2. The agent's three tools and what each one does.

The validator catches proposals that don't fit the data. A correlation heatmap needs enough numeric columns. A signed-variance chart needs negative values to show. What it can't do is tell you whether labels overlap on screen.

Here's the validator at work on the regional revenue question. The agent proposes a descending horizontal bar chart over REGION and REVENUE, and the validator confirms that the columns fit:

Figure 4. The recorded validation result for the regional-highlight request. The Tool Calls tab lets you inspect which tools ran and what they returned.

The agent specification is where these tools are defined. Here's the part of it that lists the three tools and connects each one to the Snowflake object it calls:

The specification has two parts:

1. tools defines what the agent can call: an Analyst tool for querying data, and two generic tools whose input_schema describes the arguments the agent has to supply.
2. tool_resources connects each tool to the Snowflake object that runs it, either the semantic view or a stored procedure, plus the warehouse.

With the tools defined, the app needs a way to send the agent a question. It does that through SNOWFLAKE.CORTEX.DATA_AGENT_RUN, a SQL function that runs the agent and returns its full response:

The function itself is simple. It wraps the question in the message format the agent expects, passes it with the agent's name as bind parameters (placeholders that Snowflake fills in safely when the query runs), and parses the JSON that comes back. ttl=0 stops Streamlit from serving a cached answer when someone asks the same question twice. That response holds every tool call the agent made and every result it got back. The app pulls out the submission to draw the chart and keeps the rest, which is what the Tool Calls tab shows.

Returning Chart Settings to the App

That submission is the last step in the tool sequence. Once a proposal passes validation, the agent calls submit_chart_recommendation and returns its settings as structured fields, so the app can read each value directly instead of interpreting a paragraph of text.

The schema describes those fields, but it doesn't guarantee the agent will call the tool. So the app rejects anything missing, failed, duplicated, truncated, or malformed. When that happens, it keeps the earlier chat turns and shows a Retry button instead of making up a recommendation.

Don't skip this check just because a request succeeded. One of my development runs returned status 200, the HTTP code for a successful request, yet the agent never called the validation or submission tools, and the trace didn't say why. When a request fails, look at the tool trace first.

One more thing to know now: the app draws its charts from local sample data, not from the agent's query results. I'll come back to the full setup in section 5.1 and to that boundary in section 5.2.

With the rules and tools in place, I started asking questions that exercise different rules. The first surprise turned out to be my fault rather than the agent's.

I asked for the top five product lines' share of total revenue. The agent recommended a pie chart.

The agent read the question as a comparison of two groups: the top five product lines combined versus everything else. What I actually wanted was each of the five product lines shown separately.

So I rewrote the question to name each product line separately and to use those five lines' combined revenue as the denominator:

With the reworded question, the agent recommended a stacked bar chart instead of a pie. A single bar now spans 100% of the five lines' combined revenue, with one segment per product line, as the bottom-right panel of Figure 5 shows.

That matched the app's fixed data mapping, but I also changed the question. Clearer wording and narrowing a question to fit your demo are two different decisions.

With the wording fixed, I ran the rest of the example questions. Table 3 pairs each question I typed in with the chart the agent recommended and the tool calls behind it. Treat these as results from one recorded run rather than guaranteed outputs. Large language models are generally non-deterministic, and agents built on them inherit that, so the same question can come back with a different chart or a different explanation on another run.

Table 3. Recorded recommendations for the example questions.

The correlation question shows why the query step matters. Instead of guessing the relationships from column names, the agent measured them in SQL, then picked a chart for a matrix of signed values.

To show what these recommendations look like on screen, I asked several of the Table 3 questions again in the app while writing this article. In that later run, the agent picked the same chart type for each of them. Each panel in Figure 5 pairs a question with the chart it produced: the correlation, budget, and top-three regions questions from Table 3, plus the reworded top-five question from section 3.1 ("Show each of the top five product lines as a separate share of those five product lines' combined revenue").

Figure 5. Chart recommendations rendered in the app for four example questions. Top row: a heatmap with a diverging color scale and diverging bars for actual versus budget. Bottom row: a pie chart for three parts of a whole and the reworded top-five question as a stacked 100% bar.

The correlation question produced the heatmap in the top-left panel. Blue cells mark positive correlations and red cells mark negative ones, with white at zero, so churn rate's negative relationship with the other three metrics stands out at a glance.

The budget question needs a chart that shows values above and below a reference point. In the top-right panel, the bars extend right for departments that came in over budget and left for those that fell short, sorted from the largest surplus to the largest shortfall.

The top-three regions question is one of the few cases where the rules allow a pie chart, since there are only three parts of a whole to compare (bottom left). "Other" is one of the eight regions in the sample data, not a bucket for the remaining regions.

For the weekday question, the agent kept the days in calendar order rather than ranking them by value, as rule 2 allows for naturally ordered categories. That run also tripped one of the app's evaluation checks, which I come back to in section 4.2.

Here's the submission the app received for the plain "Show me revenue by region" question, without any request to highlight a region:

Every field has a job: chart_type picks the renderer, sort_order and highlight control ordering and emphasis, and color_scheme selects the palette family. reason is the plain-English explanation shown with the chart, and rule_ids lists the rules the agent applied, which the Best Practice tab displays.

This is what makes the recommendation inspectable. You can even see choices the question didn't ask for, like the North America highlight the agent added on its own. In the regional-highlight run behind Figures 2, 4, and 6, I asked for that highlight explicitly. One caveat: color_blind_safe only reflects what the agent claims, and nothing in the app runs an accessibility test to confirm it.

Everything so far checks the recommendation. But as the opening example showed, a correct recommendation still has to reach the screen intact.

The agent returned sort_order: "descending", yet the chart showed the regions in alphabetical order, as in Figure 1.

The renderer had two bugs: an inverted ascending/descending condition, and a categorical axis that ignored the DataFrame's order.

The fix was to sort the rows first, then tell Vega-Lite the exact category sequence. Here's a simplified version of the descending case, with the zero baseline from the styling helper (the app also handles ascending and natural order):

First, the code sorts the DataFrame by revenue. kind="stable" keeps tied regions in their original order. In the spec, "scale": {"zero": True} keeps the value axis at zero, and "sort" passes the sorted region names to the y-axis.

That last line is the actual fix. Without an explicit order, Vega-Lite sorts a nominal axis alphabetically. The full renderer also adds tooltips and the supported color and highlight choices.

The same approach handles the other cases. In Figure 2, North America gets an accent color and the other regions are muted. Weekdays always render Monday through Sunday instead of being ranked by signup rate. Signed bars include zero but keep their negative range, because forcing the lower bound to zero would hide part of the data.

It's also worth testing the fix where the app actually runs. My first fix used st.bar_chart(..., sort=False). It worked on my machine but failed in deployment, because that Streamlit version didn't accept sort. The explicit Vega-Lite order worked in the deployed app.

That sorting bug is why Chartify has an Evaluation tab next to its Best Practice tab. Best Practice lists the rules the agent says it applied. Evaluation checks what the app actually plotted.

The checks are plain Python and Pandas, with no extra model call or Snowflake query. For Vega-Lite charts, the evaluator sees the final specification after styling and the data passed to the chart. For native Streamlit charts, it sees the data and explicit API arguments, but not the encodings the browser resolves.

Figure 6. The regional-highlight run's evaluation summary and upper table rows. Each row separates the check result from whether the agent cited the relevant rule.

There are four statuses:

The checks cover ordering, chart structure, part-to-whole category counts, explicit zero baselines, diverging color midpoints, supported highlights, and caption presence. Others reconcile plotted values against the local source data, such as top-category selection and histogram bin counts. Time-series checks look for missing periods and duplicate or out-of-order timestamps.

The six Not Checked results in Figure 6 matter as much as the nine passes.

The evaluator can't tell you whether the caption is accurate, whether the data answers the question, whether labels overlap, whether the chart is cluttered, or whether it's fully accessible. A chart can pass its ordering check and still need a human to decide if it answers the question. That's why there's no overall compliance score. A single number would hide exactly what you need to see.

Failures show a visible warning below the chart, and the Evaluation tab lists the evidence. The weekday run from section 3.2 is a real example. The question didn't ask for a highlight, but the agent added one on its own to mark the lowest day. Its SQL used Snowflake's DAYNAME() function, which returns three-letter names, so it asked to highlight "Sun". The app's local data uses full day names such as Sunday, so no bar matched, and the evaluator reported "Highlight 'Sun' is absent from encoded categories" (Figure 7).

Figure 7. The weekday run's failed highlight check. The days are in the right order, but the requested highlight, "Sun", doesn't match any plotted category, so the app shows a warning below the chart.

The fix belongs in the app rather than the agent: match highlights against abbreviated day names as well as full ones before styling the chart. It's the same lesson as the sorting bug, showing up at the handoff between the agent's query data and the app's local data.

A failure like this doesn't remove the chart, and it doesn't trigger an automatic repair loop. It tells you where to look.

With the agent built, tested, and checked on screen, here's how the pieces fit together, where the demo stops, and what I took away from building it.

Each part of Chartify so far has been covered on its own. Here's how they connect in a single request, and how the companion repository is organized.

The End-to-End Flow

Here's one question, start to finish:

1. The user asks a question in the Streamlit chat input, such as "Show me revenue by region and highlight North America."
2. The app calls the agent. recommend_chart() sends the question to the Cortex Agent through SNOWFLAKE.CORTEX.DATA_AGENT_RUN.
3. The agent works through its tools. It queries the data through chartify_analyst, checks its proposal with validate_recommendation, revises once if needed, and finishes with submit_chart_recommendation, guided by the 15 rules.
4. The app validates the submission. It finds the submission in the agent's response and rejects anything missing, duplicated, or malformed. If there's no usable result, it shows a Retry button instead of a chart.
5. The app renders the chart. render_chart() maps the chart type to a native Streamlit chart or a Vega-Lite spec, using the local sample data for that chart type, and style_chart() applies the supported ordering, color, and highlight choices.
6. The app evaluates what it drew. evaluate_chart() checks the final specification and plotted data, and the results appear with Pass, Fail, Not Applicable, or Not Checked statuses.
7. The app explains the result. Five tabs show the agent's reason, the rules it applied (Best Practice), the evaluation, the recorded tool calls, and the raw JSON.

Running the Companion Project

To follow along in code, you'll need a Snowflake account with access to Cortex Agents and Cortex Analyst, and Python 3.11. The companion repository generates every backend object the agent calls, including the validation procedure, but setup is still a few reviewed steps rather than one command.

All the code lives in the chart-agents-for-data-viz repository. Table 4 lists the paths you'll use most:

Table 4. Key paths in the companion repository.

To run the app and tests locally with Python 3.11:

The first three commands create a virtual environment, install the app with its test dependencies, and run the tests. The last two start the app from the app/ directory, with CHARTIFY_AGENT_FQN pointing at your agent.

You'll need a Snowflake connection, configured through Streamlit's connection settings, and an agent you can access. To set one up in a fresh account: run the three SQL files that prepare_backend.py generates (sample tables, submission procedure, validator), deploy the semantic view and agent from cortex_project/, then run one question and inspect the tool calls.

Because the validator runs with owner's rights, meaning it uses the privileges of the role that owns it rather than the caller's, it's written so that the agent's text never becomes part of a SQL statement. Column names go in as bind parameters, the lookup only covers the six demo tables, and the negative-value check for diverging bars uses the Snowpark DataFrame API with names read back from INFORMATION_SCHEMA. A unit test feeds it an injection-style column name to confirm that.

The Evaluation tab checks one chart at a time. Here's what the project as a whole has and hasn't verified.

Local Tests and Deployed Browser Checks

Start with the tests: the local suite has 63 passing tests. They cover response parsing, recovery, ordering, styling, evaluation, and the validator procedure, and AppTest, Streamlit's built-in app testing framework, exercises all eleven chart and table types with mocked agent calls.

That covers the app's logic, but it doesn't fully cover the deployed interface. I checked the regional chart in the deployed app in dark theme, and the screenshots in this article come from a local light-theme run against the same agent. Broader chart, theme, and viewport coverage is unverified.

If you extend the app, keep the rules in sync. The deployed agent has its own copy of the instructions, and the app keeps a separate copy for follow-up suggestions and the Best Practice tab. Change one and the other doesn't update.

Separate Query and Rendering Data

Next, the boundary I promised to come back to: where the data comes from.

The agent queries Snowflake tables, while the app draws charts from local sample data, with a fixed mapping per chart type: regional revenue for horizontal bars, weekday signup rates for vertical bars, the top five product lines for stacked bars, and the top three regions for pies.

That keeps the experiment manageable, but it also means Chartify recommends charts and doesn't render arbitrary Analyst results. A general-purpose app would need to carry the selected data, filters, and aggregation all the way to rendering, and verify that they answer the user's question.

Checks That Still Require Human Review

Finally, some things no automated check can catch.

A rule can require a caption, but it can't make the caption accurate. Likewise, a zero baseline won't catch a cherry-picked time window. That's why visual review and source-data review still matter.

Simpler Alternatives and When They're Enough

An agent isn't the only way to get better charts, and it isn't always the right one.

I reached for an agent because I wanted it to check its choice against real data before committing. If you don't need that check, start with one of the simpler options.

So what would I tell you if you were starting this tomorrow?

Looking back, almost every problem showed up at a handoff: guidance to rules, rules to recommendation, recommendation to screen. The sorting bug, where the agent was right and the renderer wasn't, is the clearest example.

If you're building something like this, here's what I'd do again, grouped by handoff.

From Guidance to Rules

From Rules to the Agent's Recommendation

From Recommendation to Screen

I started with a simple question: what if I gave my chart decisions to an agent? Chartify is the answer, a Snowflake Cortex Agent that recommends charts from 15 rules and a Streamlit app that draws and checks them. The rules combine my own charting decisions with guidance from data visualization literature. The agent uses tools to query and validate against the data, and returns structured settings with the rules it applied. The app draws the chart and checks what it actually sends to the renderer.

Getting a good recommendation was only the start. The rest of the work was getting it to the screen intact and being honest about what the checks still can't verify.

Want to try it? Grab the companion repository, adapt the rules to your own data and chart types, and test one question end to end before you add more.