How my AI publishing pipeline writes and waits

OScar started life as an article tool, long before it became my personal life OS. That tool is still in there, now called Publishing, and it runs my own content sites. This post is a look inside that AI publishing pipeline: what each stage does, why it is built the way it is, and where a human (me) stays firmly in charge. It is a tool I built for myself. It is not for sale.

The one-line version: agents find topics, write articles from several sources, find pictures, and then wait. Most of the interesting design is in the waiting.

The shape of the AI publishing pipeline

Think of it as a conveyor belt with a gate in the middle.

1. Discovery searches, reads and proposes ideas.
2. Ideas wait for my approval.
3. Writing turns an approved idea into a full article.
4. Images find or make the picture.
5. Publishing delivers it to a website.

Each stage is a separate background job that can fail and retry on its own. Research and writing take minutes, not milliseconds. A web page waiting for that would simply time out. So nothing heavy happens when I click a button. The button starts the job, and the job reports its progress back while I make coffee.

Agents: the researchers

Every publishing project has one or more agents. An agent has a topic, a few keywords and a schedule. When it is due, it runs a real search, picks several promising sources, reads the actual articles behind them, and proposes an idea: a suggested title and an angle.

That "several" matters. The writer is always asked to combine multiple sources into something new, never to rephrase one page. That is the whole point of the tool. A single-source rewrite is just a worse copy of someone else's article.

Agents come in a few flavours:

• A topic agent explores freely around its keywords.
• A batch agent works through a queue of titles I wrote, in order or shuffled, one or more per run.
• A recipe agent for my cocktail site reads the structured recipe data many recipe pages carry, so quantities and times come through exactly.

Used sources are remembered, even with tracking bits added to the address, so the same page never feeds two articles. And each scheduled run fires exactly once. I learned that rule from an incident where a hiccup in the scheduler fired one agent six times, and six cocktail recipes went live in a morning. Now duplicate ticks collapse into one run.

The gate: ideas wait for me

Ideas land in a queue. I can approve them, which starts the writing, or reject them, which deletes them. No archive of sad, unwanted ideas.

For agents I trust, there is an auto-approve switch, with a setting for how many ideas a run may create. Even then, writing an article is only half the trip. Going live is its own switch.

Writing: many sources, one voice

The writer receives the sources and produces the article body, a search-friendly title, a meta description and tags. It matches the language of its sources by default. A project can also be pinned to one language, from a fixed list, and then everything comes out in that language.

A few things happen in code after the writer is done, because code is more reliable than asking nicely:

• Internal links are added from the destination site's own sitemap. The first natural mention of a page gets a link, so a link can never point to something made up.
• Promo mentions work the same way. The writer mentions a name once, naturally, and the link is attached afterwards.
• Stray control characters are scrubbed out, after a few recipes once rendered their dashes as little boxes.

Images: sampling beats prompting

Each agent chooses its picture source. The simple option is a stock photo from Pexels, copied onto my own storage and never reused across articles.

The fancier option is a generated image. Here I learned two things. First, a scene described from tags alone made every image in a niche look the same. So a short scene is now written from the article itself, staging its most specific detail. Second, every single generated image has some flaw somewhere. Rewording the prompt does not fix it, but choosing does. So each article gets four candidates, and a vision check picks the most natural-looking one.

Logos are added to the corner in code, never drawn by the image model, because generated text always garbles. And if an image fails, the article is flagged for review. It never quietly swaps in a stock photo, which would break the look of the site.

Publishing: drafts, flags and my own click

Articles can be delivered to WordPress, to a webhook, to my own sites, or to this very blog. My own sites get a tiny signed "an article is ready" message and then fetch the full article themselves. That way a missed or doubled message is harmless.

The most important rule: a flagged article never auto-publishes. Any review note, like a failed picture, holds the article in "ready" with an amber banner until I press Publish myself. This rule was born when an article once went live with no picture at all.

Articles headed for the blog always arrive as drafts. They wait for the blog's own checks and my click.

Insights: the SEO coach with Fix buttons

Once a week, OScar reads each project's numbers from Google Search Console and Google Analytics. It looks at impressions, clicks, positions and search queries, and writes a report with concrete suggestions:

• refresh this article,
• try this new title and description,
• write about this query people already find you for,
• or a structural note about the whole site.

If a site has too little traffic to say anything honest, there is no AI call at all. The report just says "not enough data yet". Better than generic advice.

Every suggestion has one Fix button. For a refresh or a retitle, Fix applies the change and re-delivers the article to the sites that already have it. For a new title, it runs the writing right away. Nothing runs by itself. The report only suggests, and the click is the permission.

Once a month there is a deeper scan of the whole history. It also proposes a short "playbook" of content rules for each site. Those rules only reach the writers after I approve them.

The social scheduler

There is also a small social media scheduler. I write a post for Facebook, Instagram, Pinterest or X, pick a date and time, and it goes out then, word for word as I wrote it. Each platform's limits are checked while I type. TikTok and YouTube can be scheduled, but they fail honestly at send time, because no connection exists for them yet. Pretending would be worse.

Why it is built this way

Every stage that talks to an outside service sits behind a swappable piece, so a search provider or picture source can change without rebuilding anything. Failed checks and missing pictures degrade gracefully: they flag, they never block. And the human gate stays in the middle, on purpose.

It is less "robot writes the internet" and more "very diligent assistant who always asks before hitting send".

Want to see the rest of the desk? Have a look at OScar, or browse the tools you can use yourself. More behind-the-scenes posts are on the blog.

Thanks for reading. This post, by the way, was written by a human.