Home / Recipes / Ground a model answer in current reporting without wasting the context window

Worked query

Ground a model answer in current reporting without wasting the context window

/stories in hybrid mode. The parameters matter less than the reasoning behind them, so that is most of what is below.

The request

HTTP

GET /stories
  ?q=<the user's question, unmodified>
  &mode=hybrid
  &from=<now - 7d>
  &limit=8

Why these parameters

The common mistake here is reaching for article search. On a busy day that returns twenty rows describing one event, and the model then spends most of its context learning one fact. Worse, repetition reads as significance — a model shown the same claim twenty times weights it as well-corroborated when it has seen one wire report twenty times. Hybrid mode because the query was written by a person or paraphrased by a model, and neither matches newsroom phrasing reliably.

The obvious approach, and why it loses

The obvious approach is to hand the model a general web search tool and let it work things out. It returns pages rather than an index, which means no deduplication, no story grouping, no reliable time bounds and no outlet metadata — so the model receives ten versions of one wire report with no way to tell that is what they are, and the repetition reads to it as multiple sources agreeing. The other common pattern, embedding a static corpus and retrieving from it, gives you clean deduplication and stops being current the day you built it. Neither failure is visible in the output, which is what makes them expensive.

When it returns too much, or too little

Too much is usually a limit problem rather than a query problem: eight collapsed stories is a reasonable default for a context window and twenty is not, and the model will use whatever it is given. Too little almost always means the window is too tight for the question — a seven-day default is generous for a breaking story and much too narrow for a question about a slow-moving policy process. Let the agent set the window from the question rather than fixing it globally, and give the tool description enough detail that it does. If answers are drifting off-topic, tighten the retrieval before touching the prompt; a prompt cannot repair a result set that never contained the answer.

How you would know it is working

Measure retrieval separately from generation, with a fixed set of questions whose correct source articles you have identified by hand. For each, check whether those articles came back at all, before anyone reads the generated answer. Retrieval recall is the ceiling on answer quality and it is the half that can actually be measured; teams that skip this step spend weeks rewriting prompts to compensate for a query that was never returning the right material. Re-run the set whenever you change the window, the mode or the limit, and keep the scores, because the three interact and the effect of changing one is rarely what people predict.

When this is the wrong tool

Do not use this when the question is not actually about current events. Models reach for a news tool whenever one is available, and grounding a question about a stable fact in recent coverage makes the answer worse rather than better — it anchors a general question to whatever happened to be published this week. Describe the tool as being for current events specifically, and expect to reinforce that in the system prompt. This recipe also cannot supply article bodies, so if your use case requires the model to read full text rather than reason over headlines and snippets, this is the wrong foundation and licensing text directly from publishers is the honest path. Finally, a seven-day window is a default rather than a rule; for fast-moving stories it is far too wide.

Running it for real

Response fields, failure modes, adaptations and scheduling cost: Ground a model answer in current reporting without wasting the context window, in the docs.