The AI Content Engine

A reel dies in 72 hours. A post on ground you own is still being found in 2028. Most content advice ignores that asymmetry entirely — it teaches you to feed platforms instead of building an asset.

Below are six principles and six paste-ready prompts that hand the build to your coding agent: it reads your site, your stack and your writing, and builds a content engine that publishes daily without you.

The one thing to hold onto

Every business is different. Your site, your tools, the way you actually capture ideas — none of it looks like mine, so a copy-paste system fits badly. What transfers are the principles and the hard numbers. Give these to your agent, let it study what you already have, and let it build your version.

What you need

• A coding agent, doing the heavy lifting.
• A place on the internet you own, with a blog. Not a social profile.
• Somewhere with rows and columns — Airtable, Notion, a database.
• An hour or two of letting the agent work, checking in between steps.

How this works

Six principles, each with a starter prompt you can paste as-is. The prompts deliberately ask the agent to interview you before building — answering its questions is where your business gets in.

1. Research before you build

Don't start from your guesses, and don't start from mine. Have the agent pull what's actually working right now, then read your own site and stack, and only then plan. Current practice plus your real setup is what makes the plan fit.

Starter prompt:

research how people are actually running automated content systems right now — seo blogs, newsletter engines, ai writing pipelines. whats working, whats hype, and where these things break after a month. then look at what i already have: my site, my cms, where my writing lives, what i post to today. combine the two into a short plan for a content engine that fits THIS setup. before you build anything, ask me at least 3 questions about how i actually work.

2. Name the one thing only you can do

Most people design a content system by listing what it should produce. Wrong end. Design it by naming the single act that can't happen without you, then engineer everything else away.

Mine is a voice memo — something clicks mid-build and I talk for ninety seconds into a chat window. That's my entire recurring job. Writing, SEO, formatting, publishing, distribution, remembering what day it is: none of it needs me, so none of it gets my time.

Write yours as one sentence: "The only thing that can't run without me is ___." That sentence is your spec. Everything on the other side of it is a build task.

Starter prompt:

help me find the one act in my content process that genuinely needs me — the part thats my judgment, my story, or my taste, and cant be handed to a machine. interview me first: how i capture ideas today, where i am when the good ones hit, what part of publishing i dread, what ive tried and quit, and how many minutes a week ill realistically give this. then give me one sentence — the only thing that cant run without you is ___ — plus a table of every other step marked automate or delete, no maybes.

3. Amplify, never invent

This is the rule that decides whether automated writing is worth reading.

The system takes ninety seconds of you and expands it to eight hundred words. That's the job. What it must never do is manufacture a lesson you didn't live — invent a client, a number, a war story. I learned this the expensive way: a draft came back with a detail about my own life that was plausible, well-written and completely false. Ship that and every reader who knows you clocks it instantly.

So the instruction is narrow and absolute: amplify only what was said. Thin seed, short post. No story in the seed, no story in the piece. The other half is a voice doc — not "professional but friendly," the real rules: the words you'd never use, how you open, what you sound like annoyed.

Starter prompt:

write the step that expands my raw seed into a full post, with one hard rule: amplify only what i actually said. it may never invent a client, a number, a date, a result or a story i didnt tell it — a thin seed makes a short post, not a padded one. add a self check where it lists every specific claim in the draft and marks each one sourced or invented, and refuses to finish while anything is invented. then interview me for ten questions and write a voice doc — my rhythm, words id never say, how i open and close, what i sound like when im annoyed — and have the writer read it before every piece.

4. The column is the address

This is the piece that makes the whole thing operable by a normal person on a Tuesday.

One row per idea. One column per destination. Body goes to your site. Thread goes to X. LinkedIn goes to LinkedIn. Filled column publishes, empty column skips. No routing rules, no config file, no wondering where anything goes — and you can see your whole pipeline at a glance.

Two things go with it. Don't cross-post — platforms penalize duplicate text, and each surface gets a native rewrite derived from the published piece, never the raw seed. And one keyword per piece, never two pieces chasing the same one — two of your own posts competing for a query is worse than either ranking alone, and it's invisible unless something checks.

The constraints worth stealing outright:

• Slug: 3–6 hyphenated words carrying the keyword. Never dates. /brief/2026-w30 ranks for nothing.
• Title: keyword front-loaded, ≤60 characters or search truncates it.
• Meta description: 150–160 characters, written as a click promise — that's the text people actually read in results.
• X: 280 hard, and every URL costs 23 characters no matter how short. Work to 260.
• LinkedIn: ~1300 characters. The link in the first comment is the folklore, and it may well

buy you reach — but check your scheduler can actually do it before you design around it. Commenting on your own post needs the platform's native post id, and most schedulers hand back their own id instead. Mine couldn't, so the link goes in the body and the first ~140 characters do the work, because that's where the feed truncates you.

Starter prompt:

build me a table where each row is one idea and each column is a publishing destination — body to my site, one column per platform i actually use, ask me which. filled column means publish there, empty means skip, no routing config anywhere. add seo keyword, slug, title and meta description, and tell me which fields must be filled before anything can publish. then write a short craft doc per platform and build the rewriter that turns my published post into each native form, always linking home. enforce these hard: slug 3-6 hyphenated words with the keyword and no dates, title under 60 chars, meta 150-160, tweets under 280 counting every url as 23. and before writing anything new, read every existing keyword and slug in the table and warn me if the new piece would compete with one i already have.

5. Default-ship, catchable

Here's where most systems quietly die: someone builds an approval gate.

It feels responsible. In practice nothing publishes on the days you're slammed — exactly the days you most need the machine working. The gate becomes the bottleneck and inside a month you're back to nothing.

Invert it. Hands-off by default, catchable when you care. The piece is drafted a day ahead and you can see it. Ignore it and it ships. One word holds it. You keep the veto and lose the obligation.

The discipline that makes it safe: arm last. Once a post is live its URL is fixed — change it and you orphan every link pointing at it. So the publish trigger is a separate, explicit, final step, never a side effect of writing.

Starter prompt:

build my publishing flow as default-ship, not approve-first. the piece gets drafted at least a day before its slot and surfaced to me. if i say nothing it publishes on schedule. if i say hold, it stops. i keep the veto and lose the obligation, because an approval gate that needs me on a busy day is how this dies. make the publish trigger a separate explicit step thats never a side effect of writing content, and make changing a slug after publish impossible rather than just discouraged. then prove both: show me a test where i ignore the draft and it still ships, and one where a half filled row is refused.

6. Make it prove it can't go quiet

Don't take the system's word for it. Two failure modes, and the agent should test itself against both.

You run out of seeds. Some weeks you'll have nothing. Keep a bank of evergreen topics — the questions you answer constantly, the arguments you always make — and let it pull from there so the cadence never depends on you having a good week.

It fails silently. The dangerous one. Automation stops and you don't notice for a week, until someone asks why you went quiet. Mine has one rule: nothing published in 26 hours, wake me up — firing once when it breaks, not every time it checks.

And the trick that gives you exactly-once publishing for free: when a destination publishes, write the live URL back into that row. The written URL is the receipt. A row with a URL has published; one without hasn't. A failed platform retries alone and nothing ever double-posts.

Starter prompt:

prove my engine cant go quiet, and dont report done until youve run all three tests and shown me the output. one, build an evergreen topic bank it pulls from automatically when i have no new seeds, and interview me to fill it with twenty real topics from my own business. two, alarm me if nothing has published in 26 hours, firing once when it breaks not every time it checks — simulate a failure and confirm i actually get woken. three, when something publishes write the live url back to that row and treat a filled url as proof it already went, so a failed platform retries alone — simulate a crash mid publish and show me nothing duplicates.

The /goal trick — make the agent hold its own standard

The tip that made the biggest difference to quality: give the agent a /goal with a hard pass-fail line and permission to keep working until it's met. It'll test its own build, find its own gaps and iterate without you babysitting.

Most people prompt for a deliverable. Prompt for a standard instead.

Sample /goal prompt:

/goal my content engine must publish every single day without me touching it, and must never fail silently. actually run it for a few cycles and check your own work — dont just assume. keep optimising until a full week would go out with zero input from me.

Start here

Pick principle one, paste the prompt, and answer the agent's questions honestly — that's the whole unlock. Build it once and every week after runs itself.

The only thing that can't run without you is the part that was always yours.

Want it built instead?

That's the architecture, and it's real — it's the same shape as the system that published the page you're reading.

But there's a difference between having the plan and having it running. The full engine — wired to your site, trained on your own words, every channel connected, publishing while you work — is what I build for businesses. If you'd rather have it than build it, book a call and we'll scope yours.