# How we get the weekly metrics report written for us Our reporting agent is hooked up to our Postgres database and Slack. Each Monday it pulls the numbers, writes the weekly report with notes on what changed, and posts it to the team channel. Canonical page: https://themachine.myapps.ai/use-cases/weekly-report Somewhere on your team, a person loses a chunk of Monday to the weekly numbers. They rerun last week's queries, paste the results into the usual template, and add a sentence about what looks different. It's dull, it's predictable, and it tends to get skipped in exactly the week when someone should have been looking. Machine has an agent do it for us. Every Monday a schedule kicks it off: it pulls the metrics from our Postgres database, writes up the week with notes on what shifted and the likely reason, and posts the report in Slack. It can read the database but never change it. Below we walk through the setup: what starts it, how each run is set up, and the limits we put on it. - **Team:** Machine - **Runs on:** A schedule that fires every Monday - **Connected systems:** Postgres · Slack - **Mode:** Runs on a schedule · can read the database, never write to it ## The problem Nothing about the weekly report is hard. It just has to be done identically every time: the same queries, the same layout, week after week. Doing it by hand costs someone about an hour each Monday. When things get hectic, it's the first job to slide, and the hectic weeks are usually when the numbers most deserved attention. The standard workarounds leave a gap. A dashboard can display every figure, but it won't tell you which ones changed or why, so a person still has to study it and write the summary. A scheduled SQL query can drop numbers into a channel, but it can't explain them. Working out what shifted and whether it matters is the bit that needs a human, and it's the bit that quietly falls off. ## What we built Every Monday, a schedule on Machine starts our reporting agent. Each run gets its own isolated session (a cloud sandbox). That session can read the Postgres database through a narrow, read-only connection and can post in a single Slack channel. The agent runs the metric queries, sets the results beside previous weeks, writes notes on what changed, and posts the report. Writing to the database is not something it can do. ## How it works ### Kick it off with a Monday schedule A scheduled **trigger** starts the project early every Monday. Each time, it opens a new **session**: a fresh cloud computer (a sandbox) that exists for that one run and is then thrown away. Nothing leaks from one week into the next, so every report starts from a blank page. ### Teach it the report playbook Everything the report needs lives in **skills** and **memory** that go with the agent: how each metric is defined, the queries behind them, the layout, and how big a change has to be before it deserves a mention. When we start caring about different metrics, we write that down, and the following run uses it. ### Hook up what the report draws on **Connectors** are scoped connections to your tools. The keys stay on our servers, so the model never sees a raw token. With them, the agent can: - **Read from Postgres, and only read.** It runs the metric queries through a read-only role, fetching this week's figures plus earlier weeks to compare. - **Work out the changes.** Inside the sandbox it measures this week against recent history to see what moved and how far. - **Write the notes.** It turns those changes into plain sentences about what shifted and whether anyone should care. - **Post to Slack.** The report and its notes arrive in the team channel as one message. ### Put the limits in place The database connection is **read-only**. The agent can run queries, but it has no way to insert, update or delete, and its role can only see the metrics tables. It can post to one Slack channel and nowhere else. Its credentials are stored encrypted in the **Secrets Manager** and only handed to the agents you grant them to, when a run starts. ### Let every Monday produce its own report From there, each Monday looks the same. The agent runs the queries, compares them with recent weeks, writes up what moved, and posts the report in Slack before anyone signs on. The figures and a plain-English reading of them sit together in one message. Nobody gives up their Monday morning to build it. > **The pattern** > Each Monday a **trigger** opens a session with narrow **connectors**: one > read-only role into Postgres and one Slack channel for output. The report > playbook is kept as **skills** and **memory**. The agent queries, explains > and posts, and it has no route to writing to the database. ## Guardrails The agent looks at production data, so we keep its reach tight: - **Isolation.** Each run happens in a sandbox of its own. The session pulls the metrics and writes the report there, and the Slack message is the only thing that comes out. - **Scoped secrets.** The Postgres and Slack keys are stored encrypted in the Secrets Manager and only handed to the agents you grant them to, when the run begins. - **Read-only database access.** The database role can run SELECT and nothing more. It can't insert, update or delete, and it only sees the metrics tables. The report has no way to alter the numbers it describes. - **Everything is code.** The agent's setup, its skills and its permissions are files in the repo. They're versioned, and any change goes through a reviewed **change request**, not a toggle on a settings page. ## The outcome - **Every Monday:** The report is written and posted before the team signs on - **With commentary:** What changed and whether it matters, not a bare table - **Read-only:** Production metrics are read and never altered The weekly report no longer waits on someone finding a spare Monday morning, and it shows up already explained instead of as a grid of numbers to puzzle over. The team opens the week talking about the changes that count, not piecing the figures together by hand.