DJY89
← Work index
0x0011f41 · SEC/WORK/CONTENT-AGGREGATOR · REV.03

Content Aggregator

A deterministic research collection engine with a shared dashboard, MCP interface, scheduled harvests, and separate source rules for each collection.

Live
Next case ↗
content-aggregator
[06:00:00] harvest heartbeat started
checking source schedules...
✓ due sources selected by cadence
fetching web, RSS, video, and event records
parse → hash → store → update
✓ factual records refreshed
interpretation remains human-led
── Collection cycle complete ──
Content AggregatorFIG.01

I separated factual collection from interpretation

Research systems often blur two different jobs. One job is collecting what a source actually said and keeping that record current. The other is deciding whether the record matters, how it connects to a question, and what action follows. Content Aggregator keeps those jobs apart so scheduled work remains repeatable and interpretation remains accountable.

It is a shared browser dashboard, MCP server, and scheduled harvest engine for multiple research collections. Each collection owns its sources, cadence, saved evidence, and reports while using the same operational core. A source can be due hourly, weekly, or on a workflow-specific interval without changing the way records are stored or reviewed.

I made the harvest deterministic

The engine fetches, parses, hashes, stores, and updates factual records without making an LLM call. It can collect web pages, RSS feeds, video captions, search snippets, and structured event records. Hashing gives the system a simple way to recognize unchanged material, while Postgres keeps the history available to both the dashboard and the MCP interface.

The result is deliberately plain. A scheduled run does not invent a summary to make itself look intelligent. It records what arrived, what changed, and which source failed. The coding agent can interpret the evidence later, with a human deciding whether a report should become a decision, a brief, or nothing at all.

I made source adapters explicit and triage human

The shared core handles scheduling and persistence. Source adapters handle the differences between a web page, a caption transcript, an RSS item, and an event connector. Specialized workflows can add event tracking, follow controls, and grouped winner reports without turning those rules into hidden behavior in the harvester.

That boundary also makes failure legible. A dead source should appear as a source problem, not as an empty research result. The dashboard and MCP server read the same Postgres-backed records, so a scheduled refresh and an interactive review see the same evidence and the same gaps.

I built it for collections that keep changing

The first use cases are research collections that need a durable source trail rather than a one-off answer. The system can run unattended on its heartbeat, refresh only the sources whose cadence says they are due, and leave the interpretive work for a deliberate review. Twenty-two MCP tools expose those operations to the assistant without moving the factual boundary into the model.

0x0011f42 · SEC/WORK · MEASURED RESULTS

MCP Tools

22

Collection and workflow operations

LLM Calls

0

Harvesting stays deterministic

Heartbeat

Hourly

Due work follows source cadence

0x0011f43 · SEC/WORK · RELATED SYSTEMS