Dashboards from a sentence, in 3 minutes

Context

Once the knowledge base could describe every existing dashboard, planners asked the inverse: can it just build me the one I need?

The manual path took about four days, not because the work was hard but because it was serial. Find someone who knows the domain, agree on definitions, locate the right tables, build it, discover the definitions were subtly wrong, iterate.

The problem

A dashboard request is underspecified by nature. “Power utilization by site for last quarter” omits which utilization definition is meant, which tables are authoritative, and what the reader will decide from it.

So this couldn’t be text-to-SQL. It needed grounded context: real metric definitions, real table lineage, real precedent from dashboards that already existed. It also needed to take dependent steps, checking its work between them.

What I built

MCP servers as the tool boundary. Every capability is an MCP tool with an explicit contract: search the knowledge base, resolve a metric, inspect a schema, validate a query, emit a spec. That keeps them reusable across the platform’s agents instead of welded to one prompt, and independently testable.

Strands Agent for control flow. Generation branches: resolve intent, gather context, draft, validate, repair, emit. A graph makes those states explicit, and the failure paths with them.

Grounding in the knowledge base from the first project, so a new dashboard inherits the existing estate’s definitions instead of inventing its own.

Three gates before a draft is accepted. The SQL has to run against Redshift. Every table and column it references has to exist in the real schema. And every metric has to match the definition already in the knowledge base. The first two only stop the output from being broken. The third stops it from being quietly wrong, which is the failure that actually costs something: a dashboard that renders cleanly and disagrees with the one next to it.

What comes out is a draft, not a published dashboard. A person opens it, checks it, and publishes it themselves. That was a deliberate limit rather than a missing feature: the tool is allowed to be wrong as long as being wrong stays cheap and visible. Nothing it produces becomes authoritative without someone saying so.

To decide what to build I analyzed legacy dashboard usage in Redshift and worked the findings through with planning, infra and BI stakeholders. That produced 15 high-value features with named owners, which is why the tooling targeted the requests people actually made.

The hard part

The agent was never the bottleneck. The definitions were.

I spent a while tuning the things that look like the problem: how much context to retrieve, where to split the graph, how granular each tool should be. All of it helped a little. What actually moved the output was going back to the knowledge base and getting the metric definitions right.

Obvious in hindsight. A generator grounded in a definition inherits that definition, mistakes included. Two dashboards disagreeing about what “utilization” means isn’t an agent problem. It’s a data problem, and you can’t fix it from downstream with a better prompt.

Outcome

Four days down to a median of about three minutes. The more interesting effect was on demand: when a view costs minutes instead of days, people ask questions they wouldn’t have bothered to ask.

What I’d do differently

Version the generated specs from the start and treat output as a draft with provenance. The first questions people asked were “what changed?” and “why that table?”, both far easier to answer if you designed for them up front.