A Weekly KPI Digest Agent Your Team Will Actually Read

Most KPI reports die one of two deaths. Either someone builds a dashboard that nobody opens after week three, or someone commits to writing a weekly metrics email by hand and quietly stops after month two. The dashboard fails because it shows everything and says nothing. The manual email fails because compiling numbers from four different systems every Monday morning is exactly the kind of repetitive, judgment-light work humans are bad at sustaining.

Automated KPI reporting sits in an awkward middle. A plain scheduled query can pull numbers, but it cannot tell you which of the fourteen numbers matters this week. A human can tell you what matters, but not reliably at 9:00 every Monday. An autonomous agent that runs SQL against your actual databases, compares this week to last week, and writes one short email about what changed is the version of this job that actually holds up.

This article walks through building that agent on Skopx: what the instructions look like, how the SQL access works, why memory is what turns a static report into a delta report, and the specific design choices that determine whether your team reads the digest or filters it to a folder.

Why most automated KPI reporting fails

Before building anything, it is worth being honest about the failure modes, because the agent design follows directly from them.

The everything report. A report that includes every metric your company tracks is a report that requires the reader to do the analysis. If the digest lists 22 numbers and the reader has to figure out which three moved, you have automated the easy part and kept the hard part manual. The whole point of putting a language model in the loop is that it can do the triage: rank changes by size and relevance, lead with the ones that matter, and compress the stable ones into a single line.

The context-free number. "MRR: $48,230" means nothing on its own. "MRR: $48,230, up 2.1% from last week, the third consecutive weekly increase" is a sentence someone can act on. Context requires history, and history requires the reporting system to remember what it saw last time. Most scheduled-query setups have no memory, so every report starts from zero.

The unverifiable claim. When a report says churn spiked and someone asks "wait, how are we counting churn?", a report that cannot show its query starts an argument. A report that includes the exact SQL it ran ends one. This is the single most underrated feature of agent-generated reporting: the query is right there, and anyone who doubts the number can read exactly how it was computed.

The silent death. Manual reports stop when the person compiling them gets busy. Scheduled reports stop when a schema change breaks the query and nobody notices for six weeks. An agent run either completes and produces a report, or fails visibly in run history where you can see exactly which step broke. Skopx run history is append-only, so there is no ambiguity about whether the digest went out on a given Monday.

What the agent actually does, step by step

Here is the shape of a KPI digest agent on Skopx, described concretely. This is a hypothetical walkthrough, but every mechanism in it is a real platform capability.

You build the agent in Create Agent by describing it in chat. No code, no canvas: you explain what you want, and the chat assembles the agent with instructions, a trigger, grants, and budgets. A reasonable first description:

Every Monday at 9:00 UTC, query our Postgres database for weekly signups, activation rate, MRR, and churned accounts. Compare each number to last week. Write a short digest email leading with the biggest changes, include the SQL you ran, and send it to the team via Gmail. Ask before sending.

From that, the agent gets:

1. A schedule trigger. "Every Monday at 9:00 UTC." No one has to remember to run it. If you want to trigger it from an external event instead, that pattern is covered in webhook-triggered agents, but for a weekly digest a plain schedule is the right tool.

2. SQL against connected data sources. Skopx connects to Postgres, MongoDB, and other databases as data sources the agent can query with SQL and aggregations. Access is read-only with bound parameters. The agent cannot write to your database, drop a table, or mutate anything: it can only ask questions. For a reporting agent this constraint costs you nothing and removes an entire category of risk.

3. Memory that persists between runs. On the first run, the agent computes this week's numbers and stores them as a baseline. On the second run and every run after, it computes fresh numbers, compares against the stored baseline, and writes a delta report: what went up, what went down, by how much. It then updates the baseline for next week. Second runs are typically cheaper too, because the agent is not rediscovering your schema from scratch. The mechanics are covered in depth in how agent memory works.

4. A drafted email, parked for approval. Sending email is a write-shaped action, so under an approval grant it parks as a pending approval showing the exact Gmail call and arguments: recipients, subject, full body. You read the digest before anyone else does. Approving executes exactly that parked call, once. Rejecting executes nothing. After a month of clean sends, you can loosen the grant to run automatically, and the digest becomes fully hands-off.

5. A run report. Every run ends in a markdown report with a step timeline: which queries ran, what they returned, how the comparison was computed, what was drafted. If a number in the email ever looks wrong, the run report is where you trace it.

The instructions that separate a good digest from a data dump

The agent's instructions are plain language, editable, and versioned. This is where most of your design effort should go, because the instructions are the difference between a digest people read and one they skim past. Some hard-won specifics:

Name the metrics and their definitions. Do not write "report our key metrics." Write "weekly signups means rows in the users table created in the last 7 days, excluding rows where email ends in @ourcompany.com." Every ambiguity you leave in the instructions is a decision the model makes for you, possibly differently each week. Nail the definitions once and they hold.

Cap the length. "The email body must be under 300 words, excluding the SQL appendix." An uncapped digest grows. A capped digest forces triage, which is the value.

Specify the lead. "Open with the single largest week-over-week change, whether good or bad." This one sentence prevents the agent from burying a churn spike under three paragraphs of stable metrics.

Demand the queries. "Include every SQL query you ran in a collapsed appendix at the bottom of the email." Numbers with queries attached are trustworthy in a way that numbers alone are never quite.

Define quiet weeks. "If no metric moved more than 2% in either direction, say so in one sentence and keep the whole email under 100 words." A digest that admits nothing happened this week earns the attention it asks for when something did. This is a candor feature: the worst thing a report can do is manufacture significance.

Instructions are versioned on Skopx, so when you tighten a definition in week four, you can see exactly what changed and when. Writing good agent instructions is a skill of its own, and the instructions guide goes deeper on the patterns.

Agent digest vs. dashboard vs. manual report

The honest comparison, because each of these has a real place:

The dashboard is still the right tool for exploration: when someone wants to slice signups by channel on a Tuesday afternoon, they should open the dashboard, not wait for Monday. The agent digest is the right tool for the push: the guaranteed weekly moment where the numbers come to the team with a narrative attached. Most teams that get this right run both, and the digest links to the dashboard for anyone who wants to dig.

Note the last row. A dashboard fed by a broken pipeline shows last month's numbers with today's date, and nobody notices. An agent run that cannot execute its query fails, and the failure is sitting in run history with the exact step that broke. Visible failure is a feature.

Budgets, guardrails, and what keeps this boring

A weekly reporting agent should be the most boring agent you own. The guardrails that keep it that way:

Read-only data access. The SQL layer is read-only with bound parameters at the platform level, not as a promise in the instructions. The agent physically cannot write to your database.

Token and step budgets. Each agent carries budgets: tokens per run, tokens per day, a max step count, and a minute cap. A KPI digest has a predictable shape, maybe eight to twelve steps: a handful of queries, a comparison, a draft, a send. Set the step budget a little above that. If a schema change ever sends the agent into a retry spiral, the budget stops the run instead of letting it burn. Three budget failures auto-pause the agent entirely, so a persistently broken digest stops itself rather than failing quietly forever. Sizing these is covered in the token budgets guide.

Success criteria. You define what a successful run means: "queried all four metrics, computed deltas against the stored baseline, drafted an email under 300 words with a SQL appendix." The run report evaluates against these criteria, so a run that technically completed but skipped a metric is flagged rather than silently counted as fine.

Approval on send. Keep the email behind approval for at least the first month. The approval shows the exact call: you are not approving "the agent sends an email," you are approving this specific email, with this subject, to these recipients. Skopx also supports a drafts-only mode where the agent prepares the email but a human always sends it, which some teams prefer permanently for anything leaving the company.

A kill switch. Pausing the agent kills queued runs. If you ever need the digest to stop, it stops now, not after the next scheduled run.

Choosing metrics: fewer than you think

The strongest practical advice for a KPI digest has nothing to do with the agent: pick four to six metrics, not fourteen.

The test for inclusion is simple: if this number moved 15% in a week, would someone change what they are doing? If the answer is no, the metric is dashboard material, not digest material. Typical digest-worthy sets:

• A SaaS team: new signups, activation rate, MRR, gross churn, support ticket volume.
• An ecommerce team: orders, revenue, average order value, refund rate, repeat purchase rate.
• A product team: weekly active users, feature adoption for the current launch, retention cohort movement.

Everything else can live one click away. Resist the stakeholder who wants their metric added "just so it's visible": every added metric dilutes the ones that matter, and the digest's entire value is concentration.

One useful extension once the core digest is stable: let the agent pull one or two numbers from tools rather than the database. A digest that includes closed-won deals from HubSpot next to product signups from Postgres tells a fuller story, and Skopx agents reach nearly 1,000 integrations for exactly this kind of cross-tool stitching. Start with the database-only version, though. Get one source trustworthy before adding a second.

Rolling it out without losing the room

The digest lives or dies on trust, and trust is built in the first four weeks.

Week 1: run it to yourself. Set the recipient to just you. Check every number against the source. This is where definitional bugs surface: the signup count that includes test accounts, the churn query that counts pauses as cancellations. Fix the instructions, not the output.

Week 2: verify the deltas. The second run is the first one with memory, and therefore the first real digest. Confirm the week-over-week math is computed against the stored baseline and that the baseline updated. This is also your first look at whether the agent's triage matches yours: did it lead with what you would have led with?

Week 3: add one skeptic. Send it to yourself plus the person most likely to challenge the numbers. Their first question tells you what the digest is missing. Usually it is a definition, and the SQL appendix answers it on the spot, which is precisely the moment the digest earns its credibility.

Week 4: ship to the team. Widen the recipient list. Keep approval on the send for a few more weeks, then loosen the grant once the streak is clean.

When something does look off later, the debugging path is short: open the run, expand the step timeline, read the raw query results. Every claim in the email traces back to a specific step. The debugging guide covers the workflow, but for a digest agent it usually amounts to reading one query and spotting the schema change.

Limits worth knowing before you build

Candidly, what this agent will not do:

It will not explain why metrics moved. The agent can tell you signups dropped 18% and can note that the drop is concentrated in one channel if you instruct it to break down by channel. It cannot know that the drop happened because the marketing site's checkout was broken for two days. Causal investigation is human work; the digest's job is to make sure the humans start that work on Monday instead of discovering the problem in the monthly review.

It is only as good as your data. If your events table double-counts signups, the digest reports double-counted signups with perfect confidence. The SQL appendix makes such errors findable, but the agent will not audit your data model for you. If your source data is genuinely messy, a dedicated data-quality pass is a better first project than a digest.

Fixed scope per run. The digest answers the questions in its instructions. It does not follow up on "interesting, can you break that down by plan tier?" That is a chat question or an instruction edit for next week, not something the scheduled run improvises.

LLM prose needs the numbers pinned. The narrative around the numbers is model-generated. The defense is structural: the numbers come from SQL, the queries ship with the email, and success criteria require the appendix. Keep the model's freedom in the prose and the triage, never in the arithmetic. Instruct the agent to compute deltas in SQL where possible rather than in its head.

If your reporting need is genuinely just "run this one query and post the result," you may not need an agent at all: a simpler scheduled workflow does that with less machinery. The agent earns its place when the job involves judgment: comparing, ranking, summarizing, and writing. The agent versus workflow distinction is worth reading if you are unsure which side of the line your use case sits on.

FAQ

How is this different from a scheduled SQL query that emails results?

A scheduled query sends you rows. The agent sends you a judgment: which of the numbers moved, by how much, and which one to look at first, written as prose a non-technical teammate can read. It also carries memory between runs, so deltas are computed against a stored baseline rather than requiring you to remember last week's numbers. And when it breaks, it fails visibly in run history instead of silently emailing stale or empty results. If you do not need the judgment layer, the scheduled query is genuinely fine, and cheaper.

Can the agent write to or damage my database?

No. Connected data sources on Skopx are queried read-only with bound parameters. The agent can run SELECT-shaped queries and aggregations; it cannot INSERT, UPDATE, DELETE, or alter schema. The write-shaped actions in this setup are things like sending the email, and those sit behind grants you control, including an approval mode that shows you the exact call before anything executes.

What happens if a query fails one Monday?

The run records the failure at the specific step, and the run report shows what the agent attempted. Depending on the failure, the agent may retry within its step budget or complete the digest with the failed metric flagged as unavailable, if your instructions tell it to do that rather than guess. Persistent failure is bounded: three budget failures auto-pause the agent, so a permanently broken digest stops itself instead of failing every week indefinitely. You then fix the query context in the instructions and resume.

Which model should the digest use?

Skopx lets you pick the model per agent across Claude, GPT, Gemini, Kimi, and more, either with your own API keys at zero markup or on the $16 per seat Team plan with included tokens. For a digest, the workload is modest: a few queries, some arithmetic already done in SQL, and short prose. A mid-tier model is usually plenty. If you find the narrative quality lacking, moving one model tier up is a one-setting change, and you can compare the results across runs in history.

Can one agent produce different digests for different teams?

You can, but you usually should not. One agent with instructions covering three audiences produces a compromise email for all of them. The cleaner pattern is one agent per digest: a company-wide Monday email, a deeper metrics digest for the product team, a pipeline-focused one for sales. Each has its own metrics, definitions, recipients, and schedule, and each shows up in the agents rail beside the others. Memory and instructions stay clean because each agent has exactly one job.