Home / Recipes / Produce a machine-readable daily brief
Worked queryProduce a machine-readable daily brief
/stories in recent mode. The parameters matter less
than the reasoning behind them, so that is most of what is below.
The request
GET /stories
?mode=recent
&language=<iso>
&from=<24h ago>
&limit=25
# hand the collapsed set to the model in one callWhy these parameters
A daily brief for a model is the digest recipe with the human formatting removed. Collapse first so the model sees twenty-five events rather than four hundred articles, and pass the outlet counts through — they are the only importance signal available without asking the model to invent one.
The obvious approach, and why it loses
The obvious approach is to hand the model the same article-level feed a person would read and let it summarise. On a quiet day it works and on a busy day it inverts: the model spends its budget on whichever event was most syndicated, and reports that event as the day's most important because it saw it most often. The other shortcut, pre-summarising each article before passing it in, costs a model call per article and discards the outlet counts, which are the only importance signal in the data that was not invented by a model. Collapse first, pass the counts through, and let the single call reason over events.
When it returns too much, or too little
Too much is a limit rather than a query problem: twenty-five collapsed events fits a briefing, and raising the limit produces a longer brief rather than a better one. Too little usually means the language or topic scope is narrower than the brief's remit — check that before widening the window, since extending a recent-mode query backwards mixes yesterday's events into today's brief and makes consecutive briefs overlap. If a particular beat never appears, it is being outranked by cluster size rather than excluded; run a separate per-topic query for it and merge, rather than loosening the main one.
How you would know it is working
Read the brief yourself for a week against another source you trust, and mark what it missed. What you are calibrating is the shape of the omission, not its size: this selection is by recency and cluster size, so it will systematically drop slow-moving and specialist stories, and if those are what your readers need the recipe needs supplementing rather than tuning. Then check the reverse — how often the brief's top item turned out to be inconsequential. Outlet count is an attention signal and not a truth signal, and the day that distinction matters is the day someone acts on the brief.
When this is the wrong tool
Twenty-five collapsed events is a briefing, not a record. The recipe is tuned to fit a context window, which means it is a selection, and the selection is by recency and cluster size rather than by importance to you. Anything narrow, slow-moving or specialist will not make the cut on most days, so this is the wrong tool if the brief has to be complete for a defined beat — for that, run per-topic queries and accept the extra requests. It is also worth remembering that outlet counts are an attention signal and not a truth signal: the most-covered event of a day is regularly the least consequential one.
Running it for real
Response fields, failure modes, adaptations and scheduling cost: Produce a machine-readable daily brief, in the docs.