The AI Analytics Engineer for BI and Dashboards

Most analytics setups fail the same way: too many dashboards, not enough decisions. The company accumulates dashboards the way it accumulates Slack channels, each one created for a legitimate reason by someone who needed one thing, never cleaned up, never questioned. The result is a workspace with forty dashboards covering metrics that overlap in definition, contradict each other in value, and are trusted by nobody. The marketing team uses their own revenue number; the finance team uses a different one. Three people each have a version of the activation funnel, each with a slightly different SQL query underneath. The engineering team built a beautiful real-time monitoring screen that nobody in product has the credentials to access. None of this is waste in the accounting sense, the dashboards were built with real effort and real intent. The waste is that none of them drive decisions. What ai analytics engineer teams actually need is not another chart, it is a metrics framework where every number has one owner, one definition, and one SQL query, and a dashboard where every chart answers exactly one question.

Why the generalist approach breaks down

When you ask a generalist chatbot to write a SQL dashboard, it will produce a query. It will not ask you which tool you are building for, how the query performs at your data scale, whether the metric is already defined elsewhere in the system, who owns this number, or what decision the chart is supposed to enable. The query will run and return data, but the chart will be one more unowned artifact added to a system that already has too many. Generalist tools have no concept of a metrics framework: the idea that every KPI flows from a single North Star, that each metric has an explicit owner and action threshold, and that a dashboard is not a collection of charts but a collection of answers to specific business questions. That framework thinking is the difference between analytics that drive behavior and analytics that fill screens.

Cursor and GitHub Copilot can complete SQL. They will autocomplete a JOIN clause, suggest a WHERE condition based on the column names visible in context, and help debug a syntax error. What they cannot do is look at a query alongside your data model and tell you that the metric it computes is already defined differently in three other places, that the query will scan the entire events table without the right index, or that the chart it produces will answer a question nobody on the team has actually asked. The gap between a syntactically correct SQL query and an analytically correct metric definition is all the context that autocomplete cannot hold: what the business needs to decide, how the data is structured at scale, and what the existing metrics landscape looks like.

The deeper problem with generalist analytics work is that it optimizes for the visible artifact rather than the underlying clarity. A dashboard with twelve charts that returns the same inconsistent numbers in a cleaner layout is not a better analytics system, it is a more polished version of the same problem. Real analytics improvement requires someone who will audit what exists, identify which metrics are undefined or conflicting, establish a framework that resolves the conflicts, and then build the dashboards that emerge from that framework. That is the work of an analytics engineer, not a chart generator. Lens does both.

What an analytics engineer actually does

On a functioning data team, an analytics engineer is the person who sits between the raw data and the business decisions that data should inform. They do not just write queries, they design the metrics layer: the set of agreed-upon definitions, owners, and SQL queries that form the single source of truth for every number the business tracks. They design dashboards with discipline, asking for each chart: what question does this answer, who will act on it, and how do they know when to act? A chart without a clear answer to these three questions does not belong in a dashboard. They build reporting pipelines that deliver the right data to the right people on a schedule, weekly email reports, Slack alerts when a metric crosses a threshold, monthly executive summaries, because a number that requires manual retrieval will not be checked. They audit existing analytics setups to find the dashboards nobody looks at, the metrics that conflict with each other, and the data quality issues that make the existing numbers untrustworthy.

Meet Lens

Lens is Tonone's analytics and BI engineer, the specialist agent for dashboards, metrics frameworks, SQL reporting, automated delivery pipelines, and analytics audits. Lens's working philosophy is the same as a disciplined analytics engineer's: every dashboard chart answers exactly one question and has one owner; every metric has one SQL definition and one source of truth. Lens builds dashboards that enable decisions rather than display data, writes SQL optimized for the scale of the production database, and defines metrics in frameworks where the relationship between every number is explicit, from the North Star through the input metrics that drive it to the operational metrics that diagnose problems within it.

Tonone's Lens builds BI dashboards where every chart answers exactly one question, with one owner, one SQL definition, and one clear action threshold attached to each metric.

What Lens actually does

Building structured BI dashboards

The lens-dashboard skill produces complete dashboard specifications: every chart named, every question it answers, the SQL query that powers it, the owner responsible for acting on it, and the visualization type most appropriate for the data shape. Lens asks what decisions the dashboard should support before writing a single query, because the decision determines the chart, not the other way around. A retention dashboard that exists to trigger a re-engagement campaign needs different charts than a retention dashboard that exists to evaluate the impact of a product change. The output includes not just the SQL but the dashboard layout recommendation: how many charts, which ones belong above the fold, which should be grouped by theme, and which should be on a separate page because they serve a different audience. For teams building in Metabase, Looker, Redash, or Grafana, Lens produces queries formatted and named for those tools' conventions. For teams with a custom internal dashboard, it produces the queries and chart specifications that a frontend engineer can implement. The dashboard specification is a decision document: it explains why each chart was included and what action the chart should enable, so the dashboard has a defensible structure rather than accumulating charts through scope creep.

Defining a metrics framework

The lens-metrics skill defines a metrics framework from the North Star down through KPIs and operational metrics, each with a SQL definition, an owner, an action threshold, and an explicit relationship to the metrics above and below it in the hierarchy. This is the work that turns a collection of ad-hoc numbers into a coherent measurement system. The North Star metric captures the singular output the business is optimizing for. The input metrics are the levers that teams can pull to move the North Star. The operational metrics are the diagnostic layer that tells you which part of the system is working and which is not. The lens-metrics skill writes the framework document, writes the SQL for each metric definition, and flags any places where two existing metrics measure the same thing with different queries, the source of most analytics trust problems. For companies that have data but no coherent measurement strategy, lens-metrics is the starting point: it forces the clarity that makes every subsequent dashboard and report meaningful rather than decorative. The framework it produces is the document that ends the argument about which revenue number is correct.

Building automated reporting pipelines

The lens-report skill builds automated reporting pipelines that deliver the right data to the right people without anyone having to remember to pull it. Lens designs the report structure, which metrics, what time range, what comparison period, what format, and produces the SQL, the scheduling configuration, and the delivery specification: a Slack message to the product channel every Monday morning, an email to the executive team at the end of each month, an alert to the on-call engineer when the error rate crosses a threshold. The output includes the SQL optimized for batch reporting (different concerns than interactive queries, larger scans, historical comparisons, trend calculations), the delivery format appropriate for the audience (a Slack block for a quick metric update, a formatted HTML email for a weekly summary), and the alert thresholds with the action they should trigger. For teams where the current reporting process involves someone manually pulling numbers from four different tools every Friday afternoon, lens-report makes that process automated and consistent, with the added benefit that the report is based on a single SQL definition rather than four slightly different manual queries.

Auditing existing analytics setups

The lens-audit skill examines an existing analytics setup and produces a structured findings report covering the dimensions that matter most for analytics health: dashboard utilization (which dashboards are actually being viewed, which are orphaned), metric consistency (which metrics have conflicting definitions across different dashboards), SQL quality (queries with missing indexes, full table scans at production scale, or logic errors that produce subtly wrong numbers), and coverage gaps (business questions that are clearly important but have no corresponding metric or dashboard). The audit output is prioritized: high-severity findings like conflicting revenue definitions or broken queries first, medium findings like unutilized dashboards second, low-impact improvements like naming inconsistencies last. For teams that have built their analytics setup over several years with different tools, different owners, and no governance process, the audit is often the moment the team discovers that a metric they have been reporting to the board is calculated differently in two different dashboards. Fixing that is more valuable than any new dashboard Lens could build.

Reconnaissance before building

The lens-recon skill maps the current analytics landscape before any new dashboards or metrics are defined. It inventories existing dashboards and their apparent purpose, reads the data schema to understand what is available and how it is structured, identifies the analytics tool in use and its conventions, and produces a brief that Lens uses to ground all subsequent work in the actual state of the data environment. Recon prevents the common mistake of building a new retention dashboard without knowing that three already exist with overlapping scope, resulting in a fourth conflicting definition rather than a cleaner version of the right one. It also surfaces the data quality issues that would make any new dashboard untrustworthy before that trust is built and then broken: columns with high null rates, event tables where the event name semantics have changed over time, foreign keys that do not enforce referential integrity. Addressing these findings before building new analytics is the difference between a dashboard that drives decisions and one that gets abandoned because the numbers do not add up.

A worked example

A growth team wants to understand 30-day cohort retention across their user base and how it varies by acquisition channel. They ask Lens to write the query. Rather than producing a simple retention query immediately, Lens first asks about the events table structure, the user table schema, and the definition of "retention" for this team (does a user have to perform a specific action, or is any session sufficient?). Once the definitions are clear, Lens produces an optimized cohort retention query with clear comments explaining each step:

-- Cohort retention by acquisition channel, generated by Lens
-- Definition: retained = any session within the 30-day window after signup
-- Granularity: weekly cohorts, 30-day retention window

WITH cohorts AS (
  SELECT
    u.id                                          AS user_id,
    u.acquisition_channel,
    DATE_TRUNC('week', u.created_at)              AS cohort_week,
    u.created_at                                  AS signup_at
  FROM users u
  WHERE u.created_at >= CURRENT_DATE - INTERVAL '90 days'
),
retained_users AS (
  SELECT DISTINCT
    c.user_id,
    c.cohort_week,
    c.acquisition_channel
  FROM cohorts c
  INNER JOIN sessions s
    ON  s.user_id = c.user_id
    AND s.created_at > c.signup_at                -- exclude signup-day session
    AND s.created_at <= c.signup_at + INTERVAL '30 days'
)
SELECT
  c.cohort_week,
  c.acquisition_channel,
  COUNT(DISTINCT c.user_id)                       AS cohort_size,
  COUNT(DISTINCT r.user_id)                       AS retained_count,
  ROUND(
    COUNT(DISTINCT r.user_id)::NUMERIC
    / NULLIF(COUNT(DISTINCT c.user_id), 0) * 100,
    1
  )                                               AS retention_rate_pct
FROM cohorts c
LEFT JOIN retained_users r
  USING (user_id, cohort_week, acquisition_channel)
GROUP BY 1, 2
ORDER BY 1 DESC, 2;

The query includes a NULLIF guard to prevent division-by-zero on channels with a single cohort entry, uses DATE_TRUNC for consistent weekly bucketing, and excludes the signup-day session from the retention count to prevent inflation. Lens then produces a dashboard specification around this query: one chart showing retention rate by week as a line chart (for trend), one showing it as a bar chart grouped by acquisition channel (for channel comparison), and an alert definition that fires a Slack notification to the growth channel when any channel's 30-day retention drops more than three percentage points week-over-week. Each chart comes with its owner, its decision purpose, and its action threshold, the full dashboard specification that Lens builds into every analytics output.

Lens vs the alternatives

Lens is not a replacement for a BI tool, it generates the SQL, the metric definitions, and the dashboard specifications that power them. The comparison below focuses on the approaches most commonly used as proxies for a real analytics engineering practice: generalist chatbots, code completion tools, and the built-in template and chart systems in tools like Looker and Metabase.

Tonone's Lens defines a metrics framework where every KPI has one SQL definition, one owner, and one action threshold, eliminating the conflicting numbers that undermine analytics trust.

Install and try

Tonone is free and MIT-licensed. Install it once and all 23 agents, including Lens, are available in your Claude Code session. Start with lens-audit on your existing analytics setup to understand what you already have before adding anything new.