Building A Weekly Report That Reads Itself Into My Inbox
Every week I used to spend twenty to thirty minutes writing the same report. Pull numbers from a couple of dashboards, glance at what shipped, write three or four sentences about what mattered, send it. Not hard work, just repetitive work, and the kind that's easy to skip when you're busy, which is exactly when you need it most.
So I automated it. Not with a magic "AI does my job now" button, but with a plain pipeline: a script on a schedule, a couple of data pulls, one AI summarization step, and an email send. This post is what's actually inside that pipeline, what I chose to run locally versus in the cloud, and where the "agent" language people throw around actually applies here and where it doesn't.
The problem with weekly reports
The report itself isn't hard to write. The hard part is doing it consistently, on the same day, without it eating a chunk of your Monday morning. That's a scheduling and data-collection problem before it's ever an AI problem. If you get the AI step right but the data collection is manual, you haven't automated anything, you've just added a fancier way to procrastinate.
So before touching any language model, I mapped out what actually goes into the report: video upload stats, a couple of numbers from my site's analytics, and a short list of what I published that week. All of that already exists somewhere as an API or an export. The job was to pull it automatically, not to have a model guess at it.
What "reads itself into my inbox" actually means
The phrase is literal, not poetic. There's no dashboard I open on Monday. A scheduled task runs, gathers the raw numbers, hands them to a summarization step, formats the result, and sends it through an email API. I don't touch it unless something breaks. That's the whole trick, and it's the same trick behind most useful automation: remove yourself from the loop for the parts that don't need judgment, and keep yourself in the loop for the parts that do.
I still read the report. I still catch things and follow up. The automation isn't replacing my judgment about what the numbers mean, it's replacing the clerical work of assembling them in the first place.
The pipeline, piece by piece
Data collection. A script runs on a schedule (Windows Task Scheduler on my end, cron on a Linux box works the same way) and hits two or three APIs I already have access to: analytics, video platform stats, and a plain text log of what I published. No scraping, no guessing, just calling the same endpoints I'd check by hand.
The summarization step. This is the only part that touches a language model. The raw numbers get dropped into a fixed prompt template, something like "here are this week's numbers versus last week's, here's what published, write a five sentence summary flagging anything unusual." The model doesn't decide what data to include, it only writes prose from data I've already selected. That distinction matters a lot, because it means the model can't quietly drop a metric it finds boring or invent one that looks plausible.
Formatting and delivery. The summary gets dropped into an HTML template alongside the raw numbers in a small table, so I can sanity check the AI's read against the actual figures at a glance. Then it goes out through a transactional email API to my own inbox. Nothing here is novel engineering, it's the same shape as any automated report system, with one LLM call inserted in the middle.
Local model or cloud API: what I actually chose and why
This is the part I get asked about most, so I'll be specific about the tradeoff rather than declaring a winner.
My weekly numbers aren't sensitive, so I didn't have a strong privacy reason to keep the summarization step local. I run a cloud model for that step because the writing quality on a short summarization task is noticeably better than what I get out of the local models I run on my own hardware for other jobs. That's a real cost, not a free call, and I treat it like any other small recurring line item, not something I write off as zero cost because it's "just AI."
Where local models earn their place for me is different work: batch processing video transcripts, running drafts through a model overnight, anything where the data shouldn't leave my machine or where I'm making enough calls that a cloud bill would add up fast. For one email a week, cloud is the simpler and more sensible choice. For a hundred transcript passes a day, local starts winning. The right answer depends on your volume and your sensitivity to where the data goes, not on which option sounds more impressive.
Where agents and MCP actually fit in
I want to be careful with the word "agent" here, because it gets stretched to cover things it shouldn't. What I built is not an agent that decides what to check or when to check it. It's a script that runs on a fixed schedule and calls a fixed sequence of steps: pull data, summarize, format, send. There's no autonomous decision-making about what data matters or whether to send the report at all. If something like that mattered to me, I'd need a very different, much more carefully guarded design, because letting a model decide when to act on my behalf raises the stakes considerably.
MCP comes up because it's the standard I'd reach for if I wanted the summarization step to pull data itself instead of me feeding it a pre-built payload, letting the model call a defined tool to fetch analytics rather than me wiring a separate API call for each source. I haven't rebuilt this pipeline around it yet, because for three data sources a direct API call is simpler and easier to debug than standing up an MCP server for the privilege. MCP earns its keep once you've got enough tools and enough reuse across projects that the standardization pays for itself. For a once-a-week report with three inputs, it would be over-engineering.
What this doesn't do
It's worth being honest about the limits. The model can misread a number if the prompt is ambiguous, so I keep the raw table next to the prose specifically so I can catch that. It can't tell me anything I haven't already surfaced in the data pull, it has no access beyond what I hand it. And it doesn't make any decisions on my behalf, it writes a summary that I read and act on. If a number looks off, that's on me to notice and fix, not something the system catches for me.
None of this replaces the judgment part of running a weekly review. It replaces the twenty minutes of copying numbers into a document, which was never the valuable part of the task to begin with.
Was it worth the setup
Yes, but for a specific reason: it made the report reliable instead of optional. Before, a busy week meant a skipped report. Now the report happens whether or not I have time to write it, and I spend my attention reading it and deciding what to do next instead of assembling it. That's the actual payoff of automating something like this, not "AI wrote my report," but "the report stopped depending on whether I remembered to write it."
If you're weighing whether to build something similar, start with the data collection, not the AI step. Get the numbers flowing on a schedule first. The summarization is the easy part once the inputs are solid.
If you want to see how I build things like this out on camera, with the actual scripts and tradeoffs on screen, [check out more on xavierfok.com](/).
Get new guides and videos first — join the Telegram channel.