I didn't build a content engine. I built a slop filter.

The context

I post on LinkedIn because that's where the work I want comes from. Compliance buyers and AI hiring managers both read it. So the platform isn't optional.

The problem isn't the writing. I can write. The problem is the rhythm of the writing. Posting happened when I felt like it, which meant once a week on a good week, nothing for two weeks on a bad one. No brain-dump. No queue. No catch system for the half-thoughts that show up in the middle of a discovery call and would have made great posts if I'd written them down.

I'd already tried the obvious fixes. Ghostwriter? Voice drift, every time. ChatGPT one-shot prompts? AI slop, every time. n8n templates from the Skool communities? Volume play, even more slop, and not in my voice.

I needed something different. A system that produced less than I could produce by hand, but with a quality floor I couldn't hit when relying on willpower and a free afternoon.

The constraint

The hard part of automating personal content is not throughput. It's the slop bar.

LinkedIn is already saturated with AI-generated posts that read like LinkedIn-generated posts. Hooks that all start the same way. Three-line paragraphs with one emoji separator. "Here's what I learned" closers. The platform has trained millions of people, including the LLMs, to write a single shape of post, and that shape is now invisible to anyone whose attention is worth having.

If I built a system that just generated more of that shape faster, I'd be solving the wrong problem. I'd be louder, not better. The constraint wasn't speed. The constraint was: can I build a system that lets me publish 3-4 times a week without the output looking like every other AI builder on the feed?

The decision

I built two filtering gates, not one.

Margin note: most personal content automations have a single review step at the end. That's where slop hides.

Gate 1 lives at the research layer. Before any drafting happens, the system surfaces candidate topics. I kill topics here, when the cost of killing is one tap and zero generation tokens. Bad topic, dead topic. No draft ever gets written. This is the cheap filter.

Gate 2 lives at the draft layer. Drafts that survive topic selection get generated, reviewed in Telegram, and either approved, edited, or killed. Killing here is more expensive (tokens already spent) but catches the cases where a topic looked promising and the actual draft revealed it wasn't.

Two gates, two cost profiles. The first gate is for taste. The second gate is for execution. They filter different failure modes.

The rest of the architecture is a staged pipeline: research → draft → review → publish. Each stage has defined contracts and writes to a handoff directory the next stage reads from. The Telegram bot is the review interface, chosen because slop-checking should happen in the cracks of a day (in a queue at lunch, between meetings, on the commute) and not at a desk.

Stack is Python, an LLM SDK for drafting, a research/search API for the surfacing layer, serverless deployment with cron scheduling, and flat-file JSON for persistence. Boring stack. The interesting part is the gate placement.

The tradeoff

The human-in-the-loop isn't a tradeoff. It's the feature.

I want to be precise about this because it's where most people writing about content automation get it wrong. They build a fully autonomous pipeline, then apologize for the human gate as a "for now" measure until the prompts get good enough. The implicit promise is that the gate goes away.

I built the opposite. The gates are permanent. The system is designed around the assumption that I will always be the slop filter, and the question is just how cheaply I can do the filtering. Gate 1 makes the filtering cheap (one tap, no tokens). Gate 2 makes it precise (full draft visible). The whole pipeline exists to route my taste through more posts per week than my willpower can.

The actual tradeoff is volume. The two-gate design caps me at whatever I can review across both stages. That's roughly 4 posts a week. A pure throughput system in n8n could push 15. I don't want 15.

Annotation (arrow pointing at the volume number): "this is on purpose"

The result

Before: 1 post a week on a good week, two-week gaps on bad ones, no system for capturing post seeds.

After: 3-4 posts a week, consistent, with a queue that I review in 10 minutes per session two or three times a week. The 6 hours of weekly content production is gone. The 10 minutes of review is the new cost.

But the volume metric isn't the interesting one. The interesting result is consistency. Personal brand on LinkedIn is almost entirely a function of showing up on a rhythm the algorithm can predict. The platform rewards predictability. I went from irregular to systematic, which is the actual unlock, not the post count.

And no post that ships sounds like AI slop, because I killed it at Gate 1 or Gate 2 before it got there.

What I'd do differently

The weakest part of the system today is where approved drafts go after publishing. Right now they get archived to flat-file JSON. Useful for the pipeline, useless for me.

The next move is wiring this into a Karpathy-style second-brain setup. Drafts (both shipped and killed) become structured notes that feed future drafting. The system learns my taste over time by watching what I kill, what I approve, and what I edit. Right now it doesn't. Gate 1 and Gate 2 are stateless: every topic is judged in isolation, every draft reviewed against my mood that day.

Stateful taste is the obvious next layer. The system that remembers what I've killed and why is the system that eventually drafts in a voice indistinguishable from mine. That's the version I'm building toward.

The build was always the easy part. The taste capture is the work.