From Manual Review to AI-Driven Loop: How I Automated My Telegram Channel Moderation

I run a Telegram channel @Lx_groups focused on free AI resources—free API quotas, limited-time offers, open-source projects, and industry news. The pitch is simple: “genuinely free,” no gray-market stuff, no ads. Behind the scenes, a Cloudflare Worker pulls from upstream TG channel preview pages, GitHub Atom feeds, and major tech company RSS feeds, deduplicates via KV storage, and pushes curated content to the channel through the Bot API.

The scraping pipeline itself isn’t hard to get running. The hard part is quality. Upstream sources are a mixed bag: there are real freebies, but also gray-market tutorials, referral-code-grabbing posts, forum spam, and garbled fragments left over from upstream resharing. In the beginning, I had to manually scan the channel every morning—eyeballing the previous day’s 20 posts, flagging the problematic ones, then going back to tweak the Worker’s filter rules. It was exhausting and error-prone.

Step 1: Replace “Manually Scanning the Channel Every Morning” with a Cron Job

The first move was automating the review process itself. I set up a cron job on Hermes Agent to run daily at 5:30 AM. It first curls the channel preview page t.me/s/Lx_groups, uses a Python script to parse out every message from the past 24 hours (timestamp, link, body text), and hands each one to the agent for evaluation against a fixed classification standard:

• ✅ Normal: Free quotas, limited-time offers, open-source, news, or tools related to AI / large language models
• ⚠️ Ads / Traffic-driving: Referral-code schemes, soft-sell ads, brand promotion
• 🚫 Gray-market: Piracy, cracks, exploit-hunting, account-ban-risk operations
• 📝 Garbled / Fragments: Forum notification snippets, spam, formatting corruption, upstream reshare residue
• ❓ Uncertain: Anything ambiguous

Every morning the agent sends me a summary report on Telegram. I wake up and see the conclusions: N posts today, Y flagged, which ones need deleting, which ones need blacklist keywords added. Review no longer eats into my attention.

Step 2: The Review Report Isn’t the End—It’s Fuel for Improvement

But soon I hit a problem: the review report came every day, and so did the problems. One day the report said “4 links appeared 6 times each,” so I manually tweaked the Worker. The next day it flagged “forum spam slipped through,” so I manually adjusted again. The review was automated, but the improvement cycle was still manual—the loop was broken halfway.

So I restructured the flow. Instead of treating the review report as the final output, I started treating it as raw material for improvement prompts. After gathering 6 days of reports (8/9–8/14, 120 pushes total, 40 flagged), I scanned through all the issues, grouped them by root cause, and assembled a structured improvement prompt for Claude Code to update the Worker.

Integration isn’t just stacking things together. The 40 issues across 6 days fell into 9 categories, but not every category is suitable for hard-rule auto-blocking. I performed a manual triage—this step was critical:

• Suitable for auto-blocking (hand off to Claude Code): duplicate links, forum metadata tag residue, forum spam fragments, deduplication failures, aggregation stitching bugs, leftover system test messages—these all have clear machine-signature patterns that regex or dedup logic can hit precisely.
• Not suitable for auto-blocking (must keep human judgment): gray-market escalation, non-AI content filtering, paid-product soft ads.

Why is the second group unsuitable? Because they’d false-positive on genuinely valuable sources. Here’s a real example: in my first integration of the prompt, I included “gray-market escalation” and “non-AI filtering” and tried to block them with hardcoded keywords. But soon I discovered—these are precisely the content sources that make the channel compelling. A post about “bypassing model hidden reasoning protections” would match the keyword “bypass” and get auto-blocked as gray-market, but it’s actually AI security research—depth content readers love. An eSIM keep-alive card from nodeloc wouldn’t match any AI keyword and would get caught by “non-AI filtering,” yet the discount strategies and script tricks it points to are exactly the kind of practical intel the freebie community cares about most.

As soon as hard rules went live, this valuable-but-controversial content disappeared. The channel would become “safe but boring.” So I deliberately removed this category from the auto-improvement list and left it for a quick manual check in the daily review—the boundary of automation should be drawn where judgment is precise; where it isn’t, leave it to humans.

Step 3: The Shape of the Prompt

The finalized prompt is saved as a .md file on my desktop, in a purely directive format—not prose for humans to read, but commands ready to be copy-pasted straight into Claude Code. The structure is:

1. Project context: paths, core files, deploy commands, test endpoints
2. Already fixed (do not touch): things fixed in the previous round (e.g., the dedupUrls function) are explicitly off-limits, to prevent redundant work
3. Pending improvements: each item includes the symptom, sample, and fix instruction, prioritized P0/P1/P2
4. Hard constraints: which files may be modified, which mechanisms must be preserved, deploy-and-verify commands
5. Execution order: numbered steps, ending with deploy + curl validation + report generation

The benefit of this format is that Claude Code can run it immediately without me having to verbally walk through “do this first, then that” or “don’t forget to deploy.” The prompt also explicitly states “don’t stop to ask questions—just finish it in one pass”—so it doesn’t pause at every step for my input.

Current State of the Loop and What’s Next

Here’s how the loop runs now:

flowchart LR
    A["Upstream Scraping"] --> B["Worker Pushes to Channel"]
    B --> C["Daily 5:30 AM Review Cron"]
    C --> D["Report Sent to My TG"]
    D --> E["I Accumulate N Days of Reports, Consolidate into Prompt"]
    E --> F["Manual Triage: Auto-Blockable vs. Human-Judgment"]
    F --> G["Claude Code Updates Worker"]
    G --> H["Deploy + curl Validate"]
    H -->|Next round of review validates improvement| C

The loop is running, but one piece is still missing: the improvement step is still manually triggered—I have to manually read the report, manually consolidate, manually triage, and manually paste it to Claude Code. The next step is to automate that last segment: have the agent accumulate N days of reports, self-consolidate, self-triage by the “auto-blockable vs. keep-human” rule, invoke Claude Code CLI on its own to execute improvements, and self-deploy and self-validate. All I’d do is glance at the final review report to see “what this round fixed.”

But before that, there’s a prerequisite I need to solve first: the auto-triage criteria must be stable enough. I manually filtered out gray-market escalation and non-AI filtering this time because they’d false-positive on valuable content sources. If I hand that triage to an agent, the agent needs to reliably reproduce the same judgment—otherwise, if the agent starts flagging things that shouldn’t be auto-blocked, one pass of “fully automated improvement” could end up cleaning out the channel’s most valuable content. That would be putting the cart before the horse. So the true next step is: first, harden the “suitable for auto-blocking” decision rules into a reproducible prompt template, validate it over several rounds, then unlock full automation.

The point of a closed loop isn’t the label “fully automated”—it’s that every stage produces verifiable output: the review report is readable, the prompt is reusable, the improvement is deployable and testable. Each step can be inspected and, if wrong, rolled back. That’s far steadier than aiming for “fully automated improvement” from day one.

Further reading:

• Following AI News on Telegram: Web Preview, Channels, and a Playbook
• How to Catch AI Freebies: Quotas, Limited-Time Models, and Not Missing a Window