How to build a useful news monitoring digest

A useful news digest tells you what changed, where the information came from and whether you have already seen it. Start with a short list of named subjects and a clear date window. A broad search for an industry can produce a full page of links without revealing a single new event.

The workflow below produces one reviewed digest. Repeating it requires your application to keep the previous run's state and start the next run; the search call itself does not create a monitor.

Describe the decision the digest supports

An account owner may need funding and leadership changes. A product team may need competitor releases and deprecations. Give those event types separate inclusion rules so a passing company mention does not enter every digest.

Connect using Vaaya's setup guide, then give the agent this brief:

Review news about [entities and official domains] from [start] to [end].
Include [event types]. Exclude [unrelated names, topics and sources].
Return up to [count] distinct developments with original links and dates.
Separate publication date, event date and retrieval time.
Group repeated coverage of the same development and retain source links.
Use [budget] in total, with a ceiling for each call. Do not send messages.
If there is no qualifying news, return a short coverage report.

Put ambiguous company names beside their domains and locations. If you are watching “Mercury,” specify which organization before searching.

Build the first digest in five steps

1. Choose a source and time window. brave/news accepts a query and freshness controls. serper/news supports query, country, language and time filters. For explicit bounds, gdelt/news accepts startdatetime and enddatetime in its documented timestamp format. Ask consult to select the route and confirm the current inputs.

2. Save the search response before summarizing. Preserve headline, source URL, supplied date and search parameters. The response is the evidence of what the search returned, even if a later page changes. Record the retrieval time independently.

3. Read the candidates that pass entity matching. Prefer original announcements, filings and first-hand reports when they answer the question. Read linked sources through an appropriate page extractor. If only a snippet is available, label the summary as snippet-based and avoid details the agent cannot verify.

4. Group articles by the underlying event. Normalize URLs and compare the named organization, event type and event date. A syndicated article and five republications should usually occupy one digest item. Keep genuinely independent reporting linked under the same event so the reader can inspect disagreements.

5. Write the digest and a coverage note. Each item should state the observed change, its date, its source and why it meets the requested inclusion rule. Finish with queries run, sources reached and gaps. Separate the agent's proposed follow-up from the facts reported by the source.

GDELT's DOC API documentation describes article lists, date windows and result limits. A returned list is a bounded view of the index, so keep the requested limit in the coverage note.

Save enough state for the next run

A compact record can use these fields:

entity_id | event_id | headline | event_type | source_urls
published_at | event_date_or_unknown | retrieved_at | summary
evidence_excerpt | first_seen_run | last_seen_run | coverage_note

Keep a stable event_id in your application. New reporting about an earlier event can update that event instead of appearing as a second announcement. Preserve corrections and reversals rather than overwriting the first version without a trace.

For recurring use, schedule a bounded query window with a small overlap, then deduplicate against saved records. Overlap can catch delayed indexing; it also produces repeats that the application must recognize. Set a per-run limit and a daily or weekly total appropriate to the job.

Handle quiet days and broken sources differently

If searches succeed but no item meets the brief, say that. If the source is unavailable, record a failed run and decide whether an alternate index is worth the remaining budget. Neither state should produce an invented digest item.

Review the first few digests before enabling delivery. Select an approved recipient and destination, then connect a separate authorized mail or notification step. Store the delivered digest and its source table together so a reader can trace a later question to the exact run.

Questions

Does an empty result mean there was no news?

No. It means the selected queries and sources returned no eligible articles in that run. Indexing delays, query wording and access limits can leave gaps.

Is the article publication date the event date?

Not always. Store publication time and the date of the underlying event separately when the source provides both.

Does this automatically email a daily digest?

No. Run a first review, then configure a scheduler and an authorized delivery integration separately. Vaaya search calls do not create that recurring job by themselves.