Meet Supper's Agents

The first version of Supper had one agent.

That made sense. The core job was straightforward to describe, even if it was technically difficult to deliver: give someone something that behaves like a data analyst.

Ask it for data. Have it retrieve that data. Manipulate it. Explore what is available. Generate a chart. Keep investigating.

That agent became the Data Chat Agent, or DCA, and it remains the center of the Supper experience.

But as Supper expanded, an interesting problem appeared: a conversational interface makes every job look like the same job.

Put an empty prompt box in front of someone and the natural assumption is that anything can happen there. Unlike traditional software, there is no obvious settings page, dashboard editor, or modeling screen telling you that you have entered a different mode of work.

Technically, you could respond by making the original agent responsible for everything.

We decided not to.

Why Supper uses multiple AI agents

Supper uses multiple agents because data work contains several fundamentally different modes.

The three major customer-facing roles today are the Data Chat Agent, the Semantic Agent, and the Dashboard Builder Agent.

They share a product and overlap in some capabilities, but they have different goals.

That distinction matters.

An agent doing open-ended analysis needs to retrieve data, manipulate it, explore the schema, and visualize results. An agent maintaining a semantic model needs to understand business definitions and translate them into precise specifications. An agent building a dashboard needs to think about datasets, widgets, KPI tiles, charts, themes, and how several pieces fit together.

Giving every one of those responsibilities to the same agent would mean constantly carrying tools and context that are irrelevant to the current job.

More capability can produce more complexity.

So instead of asking one agent to do everything, Supper gives different agents different jobs.

The Data Chat Agent: your general-purpose data analyst

The Data Chat Agent is the core Supper experience.

It is where customers do general analytical work: requesting data, manipulating results, exploring what data is available, and generating visualizations.

The easiest analogy is a data analyst at your company.

You do not need to know in advance which tables contain the answer or exactly which transformations will be necessary. You describe the analytical goal, and the DCA uses the tools available to it to work toward an answer.

Underneath that experience, Supper's product architecture gives the DCA access to capabilities including data retrieval, Python-based manipulation, schema exploration, statistical analysis, deeper inspection of returned datasets, and chart creation.

That breadth is appropriate because general analysis is itself a broad job.

The Semantic Agent: building the meaning behind the data

The first place where Supper clearly needed another agent was the semantic model.

A semantic model contains the business meaning that helps an analytical system understand how a company actually talks about its data.

That includes things like business Terms, schema definitions, Skills, and both general-purpose and deeply technical descriptions of concepts.

Those components can be cumbersome to build manually.

And importantly, building them is not the same job as analyzing data.

The Semantic Agent is therefore designed specifically to work on the model itself. It can explore that model, help refine descriptions, and assist with the detailed specifications needed to make a Term precise enough to support reliable analytical work.

That work ultimately feeds back into the rest of Supper. The semantic model and its Terms are part of the context Supper uses to interpret business concepts during data retrieval.

So when a definition needs work, you work on the definition. When it is fixed, you go back to analysis.

The Dashboard Builder Agent: from analysis to presentation

Dashboard construction introduces another mode entirely.

At that point, the job is no longer simply: "What does the data say?"

Now the questions are:

• Which datasets belong together?
• Should this become a chart or a KPI?
• How should it be visualized?
• Which components should live on the same dashboard?
• How should the presentation be themed?

Those are related to analysis, but they are not identical to analysis.

The Dashboard Builder Agent exists for that reason. It focuses on creating the datasets and visual components that make up a dashboard and helping organize them into a coherent whole.

Analytical work does not have to disappear when you make that transition. A dashboard can follow from work already done in chat, allowing a useful result to become a reusable visual component.

Why not build one super-agent?

This is the obvious question.

If AI agents can use tools, why not simply give one agent every tool?

Because tools are only half the problem.

Intent matters too.

Think about working with a human data team.

There is a meaningful difference between saying, "Help me investigate customer churn," "Let's fix how our company defines an active customer," and "Turn this analysis into the executive dashboard."

A talented person might be capable of participating in all three activities. But the mode of collaboration changes.

The information they need changes.

The definition of a good result changes.

And the next action changes.

Supper's agent boundaries work the same way.

The product does not need an agent for every tiny action. It needs a different agent when the customer's goal has moved far enough away from the previous goal that a new working context becomes useful.

The UX challenge: every chat box looks universal

There is a catch.

Users already understand boundaries in traditional software.

You go to a settings page to change settings. You go to a dashboard editor to edit a dashboard.

Chat changes that expectation.

When users see a blank prompt, they naturally try to do everything there.

That means a multi-agent product has to make the boundaries legible without making the product feel restrictive.

Supper approaches that in two ways.

First, agents themselves need to understand their purpose. When a user goes too far outside that purpose, the agent should be able to explain where the task belongs.

Second, the surrounding product interface has to provide deterministic context. The experience should make it clear when the customer is working on a dashboard, working on the semantic model, or doing general analysis.

The goal is not to prevent exploration.

It is to make sure the product always helps the user find the shortest path to the right kind of work.

A multi-agent product should feel like one product

The long-term challenge is making specialization feel seamless rather than fragmented.

Today, Supper deliberately separates its largest modes of work.

In the future, those boundaries may evolve. Some functionality could combine. New specialized agents could appear. Supper could eventually use a main-agent/sub-agent structure where customers remain inside one larger conversational thread while specialized agents handle parts of the work.

The architecture is less important than the principle:

The customer should not have to choose between the flexibility of conversation and the clarity of purpose-built software.

One interface does not require one agent.

Sometimes the better conversational experience is an agent that knows exactly which job it is there to do.

FAQ

What is the Supper Data Chat Agent?

The Data Chat Agent is Supper's general-purpose analytical agent. Customers use it to retrieve, manipulate, explore, analyze, and visualize data.

What is Supper's Semantic Agent?

The Semantic Agent is a purpose-built agent for creating and refining components of Supper's semantic model, including business Terms and technical definitions.

What is Supper's Dashboard Builder Agent?

It is the agent focused on dashboard construction, including datasets, charts, KPI tiles, visualization choices, themes, and the organization of related dashboard components.

Why does Supper use multiple agents instead of one?

Because analysis, semantic-model maintenance, and dashboard construction have materially different goals. Specialized agents can use context and tools appropriate to the current task rather than carrying every possible responsibility at once.