An AI newsletter workflow should not publish whatever a model can scrape and summarise. It should preserve the source, separate extraction from judgement and make editorial approval impossible to skip.
The original Collab365 experiment used Feedly, Make, Apify and an AI model to turn weak feed descriptions into fuller draft summaries. The useful idea survives, but claims about subscriber counts and time saved were not independently evidenced here and are not proof of the workflow’s performance.
The reliable architecture
Use five distinct stages:
Discover -> Retrieve -> Extract -> Draft -> Review and publish
Each stage should leave a record. When the final summary is wrong, you need to know whether the feed supplied the wrong URL, extraction missed the article, the model invented a claim or the editor approved a bad draft.
1. Discover candidate sources
Feed readers such as Feedly can centralise selected publications. Store at least:
- source URL;
- feed title and description;
- publisher;
- discovered time;
- published or updated time if supplied;
- stable item identifier;
- campaign or topic tags.
Do not assume the feed description is the full article. Do not assume the publication date is accurate if it came from an aggregator.
Deduplicate on canonical URL where possible, then title and publisher as a fallback.
2. Retrieve within the publisher’s rules
Fetch the original page only where you are permitted to do so. Respect access controls, robots rules, rate limits, copyright and contractual terms.
Apify Actors can run extraction tasks and store results in datasets, but using a scraping platform does not grant rights to republish the source. Store a short evidence extract and your own summary, not a copied article.
If retrieval is blocked, paywalled, empty or suspiciously short, route the item to a person. Do not ask the model to fill the gap from the headline.
3. Normalise the evidence
Keep the raw retrieval separate from the cleaned text. Record:
- final URL after redirects;
- page title and publisher;
- extraction time;
- character count;
- detected publish date;
- warnings;
- content hash;
- selected evidence snippets.
This gives the editor a way to compare the draft with the material the model actually received.
4. Draft to a fixed schema
Ask the model for structured output:
{
"headline": "",
"summary": "",
"whyItMatters": "",
"claims": [
{"claim": "", "evidence": "", "sourceUrl": ""}
],
"uncertainties": []
}
Instruct it to use only supplied evidence and to return NEEDS_REVIEW when support is missing. Validate the schema before saving.
Make’s current guidance says a standard scenario is suitable for deterministic work, an AI app for structured AI transformation, and an agent for work requiring more flexible reasoning. Its Make AI Agent documentation labels the current agent app open beta, so product behaviour and pricing may change.
If you choose Make, Collab365’s Make signup link preserves the original affiliate attribution. That is an affiliate link; it does not change the evaluation criteria above.
A summarisation pipeline rarely needs an autonomous agent with broad tools. Use the least powerful component that meets the requirement.
5. Require editorial review
The review screen should show the draft beside the original URL and evidence. The editor must be able to:
- edit or reject the item;
- open the source;
- remove unsupported claims;
- record why it was rejected;
- confirm attribution;
- schedule or publish through a separate approved action.
Never let “draft generated” be the trigger for a public send.
Operational failure handling
Add explicit routes for:
- duplicate item;
- source timeout;
- blocked extraction;
- malformed model output;
- missing evidence;
- model or API rate limit;
- storage failure;
- review deadline missed;
- publishing failure.
Use bounded retries, an error queue and alerts. Make the item idempotent so a retry does not create two newsletter entries.
Data, licensing and security boundaries
Check the terms and data handling of Feedly, Make, the extraction service, the model provider, storage and email platform. Minimise personal data and secrets passed between them. Use separate credentials with least privilege and rotate them when staff or suppliers change.
Costs and feature availability vary by plan and usage. Measure them in your own run history rather than publishing a fixed estimate.
Proof boundary, checked 24 August 2026
A successful end-to-end test proves that named inputs passed through the configured scenario and reached the review or publishing step. It does not prove editorial accuracy, copyright compliance, deliverability, audience growth or time saved.
For practical AI-assisted content workflows with visible controls, join the Microsoft Copilot Adopters Space.