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.

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

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

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.