Search "AI news digest" and you will find a hundred versions of the same tutorial: connect a model to an RSS feed, ask it to summarise, dump the result somewhere. Twenty minutes, very satisfying, looks like magic in a demo.
I built one of these for a client, and I want to be honest up front: the pattern is not novel. Pulling articles, sending them to a model, writing the output to a sheet is one of the most-built automations on the internet.
But there is a gap between that demo and a system a business relies on every morning, and almost nobody writes about it, because it is the boring half. That gap is what this post is about.
What it does, in sixty seconds
The client used to spend the first hours of every day scanning industry publications across dozens of sources, looking for anything their competitors or their niche were doing that mattered. It was slow, and worse, it was lossy — a human skimming dozens of articles at 8am will miss things, and there is no way to know what they missed.
The system replaces that. Every morning it reads the day's articles across every source on a list, answers a fixed set of questions the company actually cares about, and writes the answers to a Google Sheet. On a quiet day it emails to say nothing relevant came up.
That is the part you have seen before. The rest of this is the part you have not.
The model is a component. The reliability is the product.
- Sources, of wildly uneven quality. Some have a usable feed; many do not.
- Fetch and scrape, because a feed cannot be assumed.
- Recency filter and de-duplication, so yesterday is not re-read today.
- The model, asked pointed questions rather than told to summarise.
- The evidence gate: a claim without a supporting quote does not pass.
- Two outputs — the sheet, and an explicit email on a quiet day.
01 — A model that lies politely
The default failure mode of these systems is not that they break. It is that they are confidently wrong, and nobody notices for weeks.
A language model is built to be helpful. Ask it "did any competitor change their pricing?" when the honest answer is no, and it will still reach for something plausible. It will infer, extrapolate, and hand back a clean, well-written answer that is quietly fabricated. A digest full of those is worse than no digest, because the client acts on it.
The fix is counterintuitive: you have to make the model comfortable saying nothing. The prompt instructs it to answer only where there is real evidence in the source text, and to return a hard NOT FOUND otherwise. That single constraint is the difference between a tool the client trusts and one they quietly stop opening.
Requiring a quote does two things at once. It gives the reader something to verify against, and it removes the model's room to invent, because there is nowhere to put an answer that no source supports.
02 — "Summarise this" is the most expensive prompt in automation
The instinct is to ask the model to summarise the news. It is the wrong instinct, and it is expensive twice over.
It is expensive literally: summaries are long, so you pay for tokens to generate paragraphs nobody reads carefully. And it is expensive in attention: a generic summary buries the one sentence that matters under ten that do not, so a human still has to read it. You have automated the typing and kept the reading.
So the system does not summarise. It interrogates. The prompt carries a fixed set of pointed questions — the specific things this business needs to know — plus one catch-all for anything else genuinely notable. The model is never asked "what happened today?" It is asked "did this specific thing happen, yes or no, and if yes, where?"
Q1 Did any named competitor change pricing, packaging,
or launch a product? → quote the line, else NOT FOUND
Q2 Any regulation, lawsuit, or funding round in our niche?
→ quote the line, else NOT FOUND
Q3 Anything else a founder here would want to know today?
→ quote the line, else NOT FOUNDThe output is short, scannable, and immediately actionable. It is also cheap, because a question with a yes-or-no shape does not invite three paragraphs.
03 — The web is hostile, and you plan for it or you lose
Demos run on clean inputs. Production runs on the actual web, which is a mess.
- Feed quality is inconsistent. Plenty of publications have no usable feed, so the system falls back to fetching and scraping the page. Assume this on day one; do not bolt it on later.
- Articles repeat. Without a recency filter and de-duplication, the same story is processed twice and the model spends money re-answering yesterday.
- Silence is ambiguous. If the system finds nothing and says nothing, the client cannot tell "no news" from "it broke."
- News days vary. A heavy day can overflow the context window or quietly balloon the cost, so the volume going in has to be budgeted, not assumed.
The third one is worth sitting with, because it is the cheapest trust you will ever buy. A quiet day triggers an explicit "nothing relevant today" email. Turning silence into a signal costs almost nothing to build and is the difference between a system the client believes is running and one they have to go and check.
None of this is glamorous. All of it is why the system still runs every morning instead of breaking in week one — for cents a day, in place of the hours that used to disappear into manual scanning.
The decision I am most sure about: don't own the questions
The most important design choice was not technical. The set of questions the system asks lives in the client's spreadsheet, not in my workflow. They can change what gets watched without touching code, and without asking me.
This runs against the engineer's instinct to keep the logic. But the people closest to the business know what is worth monitoring far better than I do, and a system they can steer themselves stays useful as their priorities shift. The intelligence is not only in the prompt. It is in who is allowed to edit it.
What this means for you
If you are scoping something like this, the question to ask a builder is not which model they will use. It is what happens when the model has nothing to say, and who can change the questions without a change request.
When this approach doesn't work
The honest version of any build includes its limits. This pattern is good when the questions are stable and the signal is textual. It is a bad fit when you need real-time alerting — this is a daily batch, by design — when the sources are mostly paywalled or behind heavy JavaScript, or when the questions change constantly.
At that last point you are not monitoring, you are researching, and that is a different system with a different shape. Knowing which of the two you actually have is most of the work.
The takeaway
This was never really a story about news monitoring. It is about the distance between an AI demo and an AI system, and that distance is made almost entirely of unglamorous, judgment-heavy decisions: making a model admit uncertainty, asking pointed questions instead of generic ones, and engineering for a world that does not behave.
If there is a process someone in your business does by hand every morning — reading, checking, watching — there is a good chance it can run itself. The hard part will not be the AI.