RSS to Content Feed Automation: Turning Source Overload into Daily Editorial Decisions

I rebuilt content intake as a two-layer system. Layer one listens to RSS and digest sources, cleans each item, adds summary and tags, and stores it as a reusable object.

Layer two delivers only qualified items into Telegram, where every item arrives ready for a decision.

I was consuming a lot of information and still making slow editorial decisions.

Sources were fragmented across RSS feeds, newsletter digests, and links saved in different places. The stream looked full, but most items were low-signal.

Too much time was spent on triage. By the time I found what mattered, energy for writing and framing was already lower.

The first workflow worked in theory, but the daily reality was heavy and repetitive.

The shift was simple. I stopped trying to build a better reading habit and started designing a better decision interface.

AI became a filtration and compression layer. Human work stayed where it matters most: relevance judgment, editorial angle, and final voice.

Layer one runs in n8n as intake and normalization. It collects source items, strips noisy payload, normalizes links, checks for duplicates against a local database, scrapes full context, then writes a two-sentence summary with tags.

Layer two runs in Telegram as the operational interface. Only qualified items are delivered, each with clear actions.

Actions include routing to digest queue, generating social paraphrases, creating interview question angles, or discarding noise. Final publishing still stays human.

Intake moved from ad-hoc reading to a repeatable operational system.

I now spend less time on low-signal scanning and more time on decisions that change output quality.

Telegram reduced friction by becoming the single place for triage actions.

A clear tradeoff remains. Source freshness depends on source cadence, so weekly digests can introduce delay.

This pattern fits solo creators, analyst teams, and editorial operations with high source volume.

It is most useful when the bottleneck is discovery and filtering, not final writing.

Tool choice can vary. The repeatable structure is stable: machine filtering first, human publishing judgment last.