Data
One analyst, thirty requests, and an AI worker in between
Five jobs that stand between a data team and the analysis they were hired to do.
What the worker does
Data teams use Polaris AI workers for the queue in front of the analysis: scoping incoming dashboard requests, running daily quality checks, assembling recurring reports, reconciling conflicting metric definitions, and writing scoping notes for the backlog. A worker with the Supabase, Stripe and Slack connections posts findings as a comment on the task. Production changes and query approval stay with a person.
- Jobs covered
- 5
- Usual connections
- Supabase, Stripe, Slack
- Normal output
- Silence
The request that arrives as a direct message
Can you pull the numbers for last month, broken out by plan. No decision named, no deadline, no indication of whether the answer changes anything. It arrives in a direct message, it does not become a ticket, and three weeks later somebody asks why the backlog is not moving.
Underneath that, a null rate quietly tripled in one column in March and nobody noticed until a board slide was already wrong. Data teams do not lose time to hard analysis. They lose it to intake, reconciliation and checks that nobody has automated because writing the check has never been the urgent thing.
The five jobs
Dashboard requests
Every incoming ask restated as a question, with the tables it would need named and the two clarifying questions asked before anyone writes SQL.
Data quality monitoring
Daily checks defined in the worker's skill file: row counts against yesterday, null rates on critical columns, orphaned foreign keys, freshness of the newest row. It posts only when something trips.
Reporting automation
The recurring report assembled and written, saying what moved and by how much, delivered as a file on the task rather than a link to a dashboard.
Metric definitions
Every place a metric is defined, found and listed side by side, so the three incompatible versions of active user are visible in one comment.
Analysis backlog
A scoping note per request before it enters the queue: the decision it informs, the data required, whether that data exists, and the cheapest version of the answer.
Setting up the daily quality check
The one most data teams put on the roster first, because it runs every day and costs almost nothing when nothing is wrong.
- 1
Hire the worker in chat
Tell the Chief of Staff you need daily checks on the warehouse. The interview asks for a name, the role and the tools. It takes about a minute.
- 2
Write the checks into the SKILL.md
List the tables that matter, the columns that must never be null, and the thresholds that count as a problem. This file is plain text and you edit it directly.
- 3
Authorise Supabase and Slack
One click each. Credentials are verified at connect time and stored server-side, so the worker uses them and browsers never read them back.
- 4
Create the recurring task
Put it in the data workstream with acceptance criteria stating that a clean run reports nothing. A cloud machine claims the job each morning.
- 5
Read only the exceptions
When a threshold trips, the delivery comment names the table, the column, yesterday's value and today's. When nothing trips, you get a closed task and a short line on the work log.
Brief, connections, delivery
| Job | The brief | Connections | What arrives |
|---|---|---|---|
| Dashboard requests | Scope every incoming ask before it is queued | Slack, Supabase, Notion | A restated question plus the clarifying questions to ask |
| Quality monitoring | Run the checks daily, report only exceptions | Supabase, Slack | An exception comment naming table, column and delta |
| Reporting | Assemble and write the recurring report | Supabase, Stripe, Google Drive | A written report attached as a file on the task |
| Metric definitions | Find every definition of these metrics | Supabase, Notion, Slack | A side-by-side list of definitions with their sources |
| Analysis backlog | Write a scoping note per request | Supabase, Notion, Linear | A note naming the decision, the data and the cheap version |
Where the line sits
The worker does
- Read schema and row-level state through the Supabase connection
- Compare today's counts against yesterday's
- Find every document and thread where a metric is defined
- Write the paragraph that says what moved
- Ask the clarifying question the requester skipped
A person does
- Approve anything that writes to production
- Ratify which definition of a metric wins
- Decide which analysis is worth doing
- Say what caused the movement
- Close and rate the delivery
The five data use cases
Can you pull the numbers, sent as a direct message at 6pm
Every ask restated as a question, with the clarifying questions asked before anyone writes SQL.
The null rate tripled in March and the board slide was already wrong
Row counts, null rates, orphans and freshness, checked every morning. Silence means clean.
The Monday metrics email that somebody writes on Sunday night
The numbers pulled and the paragraph written, delivered as a file rather than a link.
Three teams, three definitions of active user, one meeting
Every definition of a metric found and listed side by side, with the source of each.
Thirty requests in the backlog and one analyst
A scoping note per request, so the backlog is triaged on value rather than on arrival order.
Questions people ask
+Does the worker run queries against our production database?
It uses the Supabase connection you authorise, with whatever access that connection carries. Teams that care about this give the worker a read path and keep anything that writes behind human approval, which is also how the five jobs on this page are briefed.
+What does a quality check cost if nothing is wrong?
Very little. Hours are estimated from observable effort: pickup time, searches performed, prose written and files produced, clamped to a minimum of five minutes per session. A clean run produces almost no prose and no files, so it lands at the floor.
+Can it decide which definition of a metric is correct?
No. It finds and lists the definitions that exist, with the source of each, which is usually the part nobody has done. Ratifying one definition is a decision with consequences for every dashboard, so a person makes it and the document that records it is versioned.
+Where does the report end up?
As a comment on the task, with the generated file attached. Deliveries in Polaris are comments rather than silent updates, so there is a record of what was produced, when, and by which run of which worker.
Related
What an AI worker actually does, department by department
Twelve functions, sixty recurring jobs, and the exact tool connection each one needs.
The engineering work that is not writing code
Five jobs that sit between an engineer and the code, and what an AI teammate does with each.
Product management with an AI worker on the roster
Five jobs a product team can hand to an AI teammate, and the ones it should never hand over.
Hire an AI data analyst
It settles what active user means, writes the query that matches the definition, and turns the numbers you hand it into a paragraph an executive can read.
Connect Supabase to Polaris
Supabase is the connection where a careless key choice does the most damage, and the only one Polaris cannot yet check for you.
Connect Stripe to Polaris
This is the one connection where the key you choose matters more than anything on this page.
Work log
The record that makes an unwatched run reviewable afterwards.
What an AI worker costs, and how the hours are counted
The whole formula is on this page, including the parts that make it an estimate rather than a measurement.