In February 2026 I built a content engine for my own sites. It used no SaaS and no framework, just an AI agent, a few scheduled jobs, two model families, and shell commands to build and deploy.

It wrote and published every day across five sites. This post documents how it worked, so you can steal the good parts and skip the mistakes.

Scope

The goal was to automate the busywork and leave the thinking to me.

The pipeline handles:

What it doesn't handle:

That second one is where version one fell short. I'll come back to it.

The actual stack

Kai: my AI agent on OpenClaw, running on Claude. It runs the scheduled jobs and reports to me over Telegram. Gemini sub-agents: by mid-February the drafting work ran on Gemini 3 Pro sub-agents, which kept the Claude quota free for judgment work. Images: a free Unsplash or Pexels hero image with attribution, plus two or three section images from a Gemini image model. Astro + Cloudflare Pages: every site is static, so publishing is a markdown file and a deploy command. Content calendars: one per site, a list of planned topics.

How it works, step by step

Step 1: Pick the next topic

A scheduled job fires, reads the site's content calendar, and takes the next topic that hasn't been written yet.

Step 2: Draft

The drafting brief was simple, close to "write a 1,500 to 2,000 word article on this topic for this site." The sub-agent writes the post as markdown with frontmatter (title, description, date, tags) straight into the site's content folder.

Step 3: Images

The job adds a hero image from a free stock library, with attribution, and generates a few section images saved alongside the post.

Step 4: Internal links

After writing, the job looks up three to five related articles on the same site and adds contextual links, so new posts don't land as orphans.

Step 5: Build and deploy

Then it's two commands:

npm run build
npx wrangler pages deploy dist --project-name=aimarketingpicks

The site is live on Cloudflare's edge a minute later.

Step 6: Report

Kai posts what shipped into our Telegram chat, so I see each article without opening anything.

What works well

The system is repeatable: same steps every time, on every site.

Splitting models by job works. The orchestrator handles judgment calls and tool use. A cheaper drafting model handles volume. Gemini drafts are competent, but in my testing they skew flat and brochure-like and tend to come in under word targets, so plan an editing pass.

The calendar keeps topics deliberate. I decided in advance what each site should cover, so the AI never picks random topics.

What's broken

It overwrote my work. The jobs treated each blog folder as empty. One rewrote an existing article and wiped a YouTube embed I'd added by hand, and the file had never been committed to Git. Fix: a content registry tracking every article across all five sites, a hard rule that jobs never overwrite an existing file, and Git commits for the articles.

It failed silently. Twice the jobs just stopped: once the scheduler wasn't firing overnight, once the agent sessions filled their context window and stopped responding. Nothing errored; the posts just didn't appear.

Nothing checks quality. No step verifies a claim, cites a source, or asks whether the post says anything new. A week in, the new sites had zero pages indexed. Some of that was a sitemap problem I fixed. Some of it, I suspect, is that the content is generic.

The cost-benefit

Hosting is free and the model costs are small. On paper, the cost per article is close to nothing.

But cost per article is the wrong metric. An article that never gets indexed, or that a reader can't trust, has negative value: it spends crawl budget and credibility. The number that matters is cost per article worth publishing.

Building your own

The engine works because it's simple and repeatable. There are no AI frameworks or machine learning involved, just an agent, two model families, shell commands and APIs.

You can build something similar for your business if you understand: 1. How to call APIs (easy in bash or Python) 2. How to write good prompts (practice) 3. What part of your process is automatable (the boring parts)

The harder skill is knowing where the busywork is, and which step must never be automated away: the check on whether the output is any good.

Extending the system

The basic pipeline I described handles drafting to publishing. But you can extend it:

Post-publishing automation:

Content calendar management:

Before any of those, though, add the gate.

The maintenance question

The pipeline requires maintenance:

Why this works for me specifically

I'm SEO-focused, so the outputs matter. If the posts don't rank, the system is pointless. I'm willing to invest time in tuning it because that's the only way to find out what actually earns rankings.

Also, on my own sites I work alone. No team to convince that this is a good use of time. I can just build it and learn.

If you're in a team environment, getting buy-in might be harder. The principle still holds: automate the repetitive parts that don't need judgment, and spend the time saved on strategy.

Update, October 2026

My suspicion that the content was the problem turned out to be right.

In July 2026 I rebuilt the engine from scratch as a fully autonomous pipeline: research, brief, draft, quality gate, publish, deploy. It uses codex exec as the LLM engine and DataForSEO for keyword and trend data. The gate scores every draft for unsourced claims, derivativeness, staleness and guardrail violations before anything is published, and the higher-stakes sites still wait for my review.

Before reusing the February backlog, I ran all 68 of the old pre-written articles through that gate. It rejected every one. The topics were mostly fine, so they now feed back into the pipeline to be rewritten with real sources.

Since July the new pipeline has published about 70 articles across six sites. The lesson from version one stands: automate the drafting, never the judgment about whether it's good.