How to schedule a Claude Cowork task that reports reliable numbers

An agent with database access rewrites the SQL every time you ask. That is the right behavior when you are exploring and the wrong behavior when you are reporting.

Ask “how many active users last month” on Monday and again on Thursday and you might get two different answers. Not because the data changed, but because the agent wrote a different query. One run counted anyone with a session while the other counted anyone who ran a query. Maybe it’s because the underlying query wasn’t stored, the number moved too much and your agent second guessed itself, or you’re using an MCP tool and it’s re-exploring the toolset every time you run it.

This guide shows you how to fix it using one agent running on a schedule and reporting from a definition that won’t drift.

How the pieces work together

The source. Supabase MCP if the events live in your Postgres, PostHog MCP if they live in your product analytics. Either way the agent reaches it through a read-only connector.

The dataset. It’s a single query with one grain and one row per period. This is the part that makes the whole thing work. It is the written-down definition of the metric, and keeps a singular query backing it up regardless of the number of sources needed.

Promotion. All datasets start as scratchpads and will expire. This is a strength as it allows you to explore and verify data before committing to heavy storage operations. Promoting a dataset makes it durable, so history accumulates period over period so you can keep that definition pinned forever.

The Cowork scheduled task. This is the default Claude scheduler. You know it’ll read the right dataset, compares the new row against the prior ones, and write a summary.

Slack. A convenient place to share with your team.

Step 1: Connect the source

Connect Supabase or PostHog as a read-only connector. Nothing in this guide writes to your database, and the scheduled task should never have permission to.

If you are on Supabase, scope the MCP server to one project and set read_only=true. The setup is covered in the MCP setup docs.

Step 2: Pick the grain before you write the query

The grain is the set of columns that make a row unique. Decide it first and write it down: (week, section), or (week, plan, region). Every column you add multiplies the row count, and every column you leave out is a question you cannot answer later without a rebuild.

Two things worth settling before you choose:

Coarse beats fine. Store the aggregate you actually report on, not a full copy of your database. Fine grain multiplies rows quickly and buys less than it looks like it will. Detail questions are better answered ad hoc at the moment somebody asks one.

Store values, not derivations. Anything your source computes at query time belongs in exploratory work, not in a definition you intend to stand behind. If a number is going in a board deck, it should be a value you can point at, not a calculation that gets re-run with whatever assumptions are current that day.

Step 3: Save it, check it, promote it

Save the dataset as scratch first and query it. Reconcile at least one number against something you already trust whether that’s an existing dashboard, a manual count, or last month’s board deck. Scratch datasets expire on their own which makes them the right place to be wrong.

Now promote it! Promotion is what turns a scratch calculation into a definition your team trusts: history starts accumulating, and the number is never recomputed. Validate first for the same reason you would validate a migration before running it, not because it is difficult to change, but because a metric people have already acted on is expensive to correct.

Step 4: Schedule it in Cowork

Run the prompt on demand first and read what it produces. Once it looks good, confirm the schedule. Something like this has worked well for us:

Every Monday, report on our weekly metrics. First search aggregates, then
datasets if you need more history. Use the Dreambase MCP and Skills for
the report, using dreambase-echarts, dreambase-visualization-detail, and
dreambase-data-stories.

1. Query the aggregates for rolling 7d intervals, or query the
   dataset for more changes over time.
2. For each measure, give the current value, the change against the prior
   week, and the change against the four-week average.
3. Call out any measure that moved more than 25% in either direction, and
   say plainly whether the move looks real or looks like a data artifact
   (a partial week, a tracking change, a spike from one account).
4. Do not recompute anything. If a number you need is not in the dataset,
   say so and stop — do not write a new query to fill the gap.
5. Post to #metrics as a short summary: the headline, the movers, and one
   line on what to look at next. If nothing moved materially, say that in
   one sentence and post nothing else

Every Monday, report on our weekly metrics. First search aggregates, then
datasets if you need more history. Use the Dreambase MCP and Skills for
the report, using dreambase-echarts, dreambase-visualization-detail, and
dreambase-data-stories.

1. Query the aggregates for rolling 7d intervals, or query the
   dataset for more changes over time.
2. For each measure, give the current value, the change against the prior
   week, and the change against the four-week average.
3. Call out any measure that moved more than 25% in either direction, and
   say plainly whether the move looks real or looks like a data artifact
   (a partial week, a tracking change, a spike from one account).
4. Do not recompute anything. If a number you need is not in the dataset,
   say so and stop — do not write a new query to fill the gap.
5. Post to #metrics as a short summary: the headline, the movers, and one
   line on what to look at next. If nothing moved materially, say that in
   one sentence and post nothing else

Every Monday, report on our weekly metrics. First search aggregates, then
datasets if you need more history. Use the Dreambase MCP and Skills for
the report, using dreambase-echarts, dreambase-visualization-detail, and
dreambase-data-stories.

1. Query the aggregates for rolling 7d intervals, or query the
   dataset for more changes over time.
2. For each measure, give the current value, the change against the prior
   week, and the change against the four-week average.
3. Call out any measure that moved more than 25% in either direction, and
   say plainly whether the move looks real or looks like a data artifact
   (a partial week, a tracking change, a spike from one account).
4. Do not recompute anything. If a number you need is not in the dataset,
   say so and stop — do not write a new query to fill the gap.
5. Post to #metrics as a short summary: the headline, the movers, and one
   line on what to look at next. If nothing moved materially, say that in
   one sentence and post nothing else

Point 4 is the one that matters. Without it the agent will helpfully invent a query when the dataset does not have what it wants. The underlying dataset is key here though! You can always ask it for the raw data from the dataset.

What a run produces

The same columns with one new row per period. A comparison that is valid because both sides came out of the same definition rather than two different improvisations.

Keeping it safe

Keep it read-only. This is the best defense.

Scope the connection to one project, so a scheduled task cannot wander into data it was never meant to summarize.

Be deliberate about what you promote. A durable dataset is a definition your team will quote in board decks or take action on for your business.