You tried AI content. What came back was smooth, empty and sounded like everyone else, so you either posted it with a wince or deleted it. This is how my own pipeline is actually built, including the parts that broke.

Four stages, three models, no autoposting

I run a daily content pipeline for my own LinkedIn and X accounts. It runs overnight on a small rented server and finishes well before my morning posting slot, around 9:20 am India time. It builds a bank of drafts. It never posts. I choose about three a day and publish them myself.

Each stage is a separate scheduled job:

Research. One model gathers the day's raw material.
Draft writer. A different model writes three sections: about 10 LinkedIn drafts, about 10 X versions written natively for X rather than copy-pasted, and 2 to 4 reserve idea seeds.
QA reviewer. A third model, from a different model family, reviews every draft. A model never grades its own work.
Doc sync. Plain Python, no AI at all. It pushes the reviewed drafts into a Google Doc I read in the morning.

The X versions are not LinkedIn posts with the paragraphs chopped up. They are written for X first. Notice what else is not on that list: a publish step. That absence is a design decision, not a missing feature.

The reviewer is never the writer

The models come from three different families: Grok for research, Kimi for drafting, DeepSeek for QA. Three models from three families sounds like a committee. It is one, and that is the point.

I am not precious about the specific models. Swap any of them out and the system still works, as long as one rule holds: the reviewer is never the writer. A draft that passes through two different families gets read with fresh eyes. A draft graded by its own writer gets waved through. I would rather have a mediocre reviewer that did not write the text than a brilliant one marking its own homework.

The written rules do the heavy lifting

The value of this system is not in any model. It is in the stages, the checks between them, and the rules I wrote down. Three rules do most of the work. None of this is clever. That is why it works.

Format mix. The pipeline enforces a mix so the feed does not become one note: roughly 30% how-to or framework, 25% story or cultural hook, 20% hot take, 15% satire of AI hype, 10% light teardown. Each LinkedIn draft also carries a slot tag: morning, midday or evening, matching format to posting time.

Proof rule. The system is told never to invent client metrics, results or testimonials. On the first full live run, QA flagged one draft for an unsourced specific metric inside an anecdote. The draft contained no banned word. A keyword filter would have missed it. The reviewer model caught it.

Banned words. There is a deterministic check for hype words: revolutionize, unlock, seamless, cutting-edge, game-changer. It is only a warning, not a hard fail, because my satire posts quote those words on purpose to mock them. The QA model makes the final call on whether a usage is satire or sincere. On the first live run it correctly passed two satirical uses.

What broke: the boring parts

The failures were not exotic. They were parsing and auth.

I log each day's topics so the pipeline does not repeat itself. The log parser was copied from an older single-platform pipeline. It picked up the "Format" and "Topic" lines from every block, including the new X blocks and reserve blocks, and mislabelled the LinkedIn drafts. The fix was a simple state flag so only LinkedIn draft blocks feed the log. The lesson: adding a second output platform quietly breaks assumptions made for one.

Auth was the other one. The doc sync uses a Google service account that has edit access to that one Doc, instead of a personal login token. Personal tokens expire, and the pipeline dies silently at 5 am. The service account does not. You find out when your morning Doc is empty, which is a bad way to find out.

The first full run, by the numbers

The first full live run produced 10 LinkedIn drafts, 10 X drafts (5 threads, 5 single posts) and 4 reserve ideas. QA result: 9 passed, 1 flagged. The flag was legitimate: the unsourced metric from the proof rule above. In the morning I read the reviewed drafts in the Doc, pick about three, and publish them myself.

The same four-stage pattern now runs two other daily content pipelines for client work. Each new one needed a new project folder, four scripts and scheduled jobs. No server changes. Same skeleton, same checks between the stages.

Your checklist for this week

If you are building your own version, here is what I would do, in order:

Write down your rules first: format mix, proof rule, banned words. Before any code.
Split the work into stages with a check between each. Keep research, writing and review as separate jobs.
Make the reviewer a different model family from the writer. Never let a model grade its own work.
Keep a human as the publisher. The pipeline prepares, you decide.
Expect the boring parts to break: parsing, auth, scheduling. Test those first.

If you want a second pair of eyes on your own setup, the AI Audit is the working session where I map a firm's content or outbound workflow and rank what is worth automating.

The models will keep changing. The stages, the checks and the written rules are the asset.

My daily content pipeline: four stages, three models, and it never posts for me