A newsroom that opens to a queue of drafted stories instead of thirty browser tabs

Stop 1 · Watch

Every source gets its own watcher

Rather than one clever scraper, each community page and site runs as its own scheduled Make scenario.

City government, the school district, the chamber of commerce, the public library, parks and recreation, theatres, sports clubs, local businesses and event calendars each have a scenario of their own. Facebook pages use the Watch Posts module; websites are fetched over HTTP and parsed out of the raw HTML. Each one runs on its own schedule and returns only what has appeared since it last looked.

One scenario per source is deliberately the unglamorous choice. A single generic scraper breaks the first time one site changes its markup, and takes every other source down with it.

Stop 2 · Branch

A router asks whether there is more to read

Some posts are the whole story. Others are three lines and a link to the real article.

Straight after the watcher, a router splits the run. If the post carries a link, the pipeline treats the post as a pointer and goes after the article behind it. If there is no link, the post text is all there is, and it goes to the model as-is. The two paths converge again at the same Airtable table, so nothing downstream needs to know which way it came.

Stop 3 · Check

Look it up before spending anything on it

The duplicate check sits before the fetch, not after it.

The same announcement often appears on a city page, a chamber page and a venue page within the same hour. An Airtable search runs before the article is fetched and before the model is called, so a story already in the base costs nothing the second time it is seen. Ordering it this way — check, then spend — is the difference between a pipeline that scales to thirty sources and one that gets expensive at ten.

Stop 4 · Read

The linked article is fetched and flattened

An HTTP request pulls the page; a parser strips it back to readable text.

For the link path, Make requests the article and runs the response through an HTML-to-text parser, so the model receives prose rather than navigation, cookie banners and markup. Website sources go through a longer version of the same idea: fetch the index page, pull the anchor elements, aggregate them, work out which are actual articles, then iterate and fetch each one.

The link-extraction step still runs on an older assistant module that Make has since deprecated. It works, but it is the next thing in this pipeline that should move across to Claude with the rest.

Stop 5 · Structure

Claude returns a shape, not a paragraph

The model is asked for strict JSON, because its output has to land in named Airtable fields.

Claude receives the post or the article text and returns a fixed object: a clean headline, a short summary, a publishable body, and the metadata the newsroom sorts by. Because the contract is a shape rather than prose, every field maps straight into its column with no parsing on the far side. Anything the model could not determine comes back empty rather than invented, so a gap stays visible instead of becoming a confident mistake.

This started on an earlier model and moved to Claude partway through. Because the prompt only ever asked for one JSON shape, the switch was a module swap inside each scenario rather than a rewrite of anything downstream.

Stop 6 · Triage

It also decides what the story is — and whether it is one

Each item comes back tagged by type, community, priority and suggested channel.

The same call classifies the item across ten content types — event preview, business happening, meeting recap, school news, sports recap, newsletter brief, evergreen and the rest — assigns it to one of the six communities, sets a priority, and suggests whether it belongs in the newsletter, on the website, on social, or all three. It also writes editorial notes flagging what is missing: no ticket price listed, year not confirmed, address not given.

Anything outside the coverage area comes back as skip with a written reason — an Atlanta concert, a UK webinar, a Milwaukee job fair. An editor can overrule a stated reason. They cannot overrule something that was quietly discarded.

Stop 7 · Review

One screen: what was scraped, and what will publish

An Airtable interface puts the raw capture beside an editable draft, with the queue counts across the top.

The Newsroom Flow interface opens on counters — how many are unprocessed, how many drafts await review, how many have gone out. Selecting an item shows the untouched scrape on the left and the working draft on the right: title, full body, AI summary, region, tags, section, start date and featured image, all editable. The editor rewrites what needs rewriting, swaps or removes the image, and presses Submit.

Stop 8 · Publish

Approval writes the WordPress draft

Submitting fires a webhook that builds the post — body, image, section and tags — as a draft.

A second Make scenario listens for approved records, reads the finished fields out of Airtable and creates the matching WordPress post with its featured image already attached. It lands as a draft on purpose: the last decision in the chain is a person reading the post on their own site and pressing publish. Nothing reaches readers that an editor has not seen twice.