Building a content pipeline with no human in the loop

The first time the whole thing ran end to end, nobody was watching.

Around 2am it found a source it had never seen before, crawled it, rewrote the article, scored the result against a quality threshold, published it, generated the SEO metadata, and pushed a handful of social posts. No one approved anything. No one was awake.

That was the entire point of the platform: a content engine that runs a niche from source discovery to distribution with no human in the loop. It was also the thing that took the better part of a year to make safe, because every stage in that pipeline tried to take the system down before it learned to behave.

This is the tour, stage by stage, and the failure behind each decision.

Why it's a pipeline, not a script

The naive version of "automate content" is one long script: fetch, rewrite, post. We built it that way first. It broke the moment any single step was slow, rate-limited, or wrong, because a script has no memory of where it was when it fell over.

So the real system is a pipeline of independent, durable jobs. We run on Elixir/Phoenix with Oban for the job layer, which means every stage (crawl, rewrite, quality check, publish, SEO, distribute) is its own queue with its own retry policy, its own concurrency limit, and its own backpressure. A provider timeout in the rewrite stage doesn't stall the crawlers. A flaky source doesn't block publishing of everything queued behind it.

The crawl tier lives at the edge, on Cloudflare Workers, so discovery and fetching run close to the source and in parallel, dozens of crawlers at once across whatever site structures we throw at them. The heavy stateful work (orchestration, scoring, the database of everything we've ever seen) stays on the Elixir side.

It is, deliberately, a boring distributed system. The interesting part is not that an AI writes the article. The interesting part is everything that keeps the AI from bankrupting us, lying to us, or getting us blocked.

The AI bill showed up before the traffic did

The first surprise was the invoice.

An autonomous loop has a property a human-driven workflow doesn't: nobody is watching the meter. When a person clicks "generate", they feel each call. When a pipeline runs itself, it will happily call a model ten thousand times overnight, including for things it already did an hour ago.

Two failure modes drove almost all of it. Duplicate work: the same source, the same passage, rewritten again because nothing remembered the last result. And retry storms: a transient error sends a job back through the queue, and now it's paying for the same expensive completion two or three times.

We fixed it with two pieces of plumbing, neither of them clever. A two-tier cache (hot in-memory, then a durable layer) so an identical request never hits a paid API twice. And request coalescing, so when twenty jobs ask for the same thing in the same window, one call goes out and twenty jobs share the answer. Together that took something like 40 to 60 percent off the AI spend. Same output, half the bill, because half the bill was waste we couldn't see.

In a system with a human in it, cost is self-limiting. In an autonomous one, cost is a bug you have to design out.

Treat the model like infrastructure that fails

The second thing we learned is that you cannot build an autonomous system on top of one AI provider, because providers go down, rate-limit you, change behaviour, and deprecate models, usually at the worst possible time.

Early on, a single provider hiccup was enough to stall the whole rewrite stage. Jobs piled up. The queue drained the wrong way. We were one upstream outage away from a dead pipeline.

So the AI engine became multi-provider by default, sitting behind a circuit breaker. We run across three (Gemini, DeepSeek, and OpenRouter as a broad fallback), and the orchestration layer fails over automatically: when one provider starts erroring or slowing past a threshold, the breaker trips, traffic shifts to the next, and the dead one gets probed quietly until it recovers. The job doesn't know or care which model answered. It just gets text back.

The mental shift here is the whole lesson. Stop thinking of the LLM as a smart API you call. Start thinking of it as an unreliable dependency you route around, the same way you'd treat a third-party payments provider or a flaky DNS resolver. Failover, health checks, timeouts, breakers. Boring resilience patterns, applied to the newest part of the stack.

The gate that has to say no

Here is the uncomfortable truth about "zero human intervention": it is only as trustworthy as the thing standing in for the human's judgment. For us that is the quality gate, and it is the part I'd defend hardest.

The early pipeline published whatever came out of the rewrite. Most of it was fine. Some of it was thin, off-topic, or subtly wrong, and it went live anyway, because there was no one to say no.

So we built an automated scorer with a configurable threshold per niche. Every candidate article is scored before it can be published. Below the line, it doesn't get a human (there is no human); it gets a smart retry, where the failure reason is fed back into a targeted regeneration instead of a blind re-roll. Too thin gets told to go deeper on the specific gaps. Off-topic gets pulled back to the brief. Only what clears the bar ships.

This is also where the large-article handling lives, because a 20,000-word source can't be rewritten in one shot without the model losing the thread halfway. We chunk it, process the pieces, and validate the reassembly, so length doesn't quietly degrade quality.

The gate is the reason I can sleep while the thing publishes. "Autonomous" without a hard gate is not autonomous, it's just unsupervised.

The least comfortable stage: distribution

Publishing an article is the easy half. Getting it seen means pushing into social platforms (Pinterest, Reddit, X), and those platforms do not love automation that looks like automation.

This is the stage I'm most honest about being a moving target. It's a cat-and-mouse problem, not a solved one. The distribution layer behaves like a careful human rather than a bot: it spaces posts on human-like timing, rotates identities and network paths so traffic isn't all coming from one obvious place, and backs off the moment a platform pushes back. When an account gets limited, the system treats it as signal and slows down, rather than hammering through and burning the account.

I won't pretend this is permanent. Platforms change their rules and their detection, and this part of the system needs more ongoing attention than any other. The lesson we took: design distribution to degrade gracefully under pressure, because pressure is the steady state, not the exception.

What actually made it autonomous

If you zoom out, almost none of the hard work was the AI.

Generating an article was the easy 20 percent, and frankly the part that gets easier on its own every few months as models improve. The other 80 percent was the unglamorous machinery around it: durable jobs so nothing is lost, caches and coalescing so it doesn't go broke, circuit breakers so one outage doesn't cascade, a quality gate so it doesn't publish garbage, and a distribution layer that knows how to lose gracefully.

That machinery is also what makes the economics work. Once the platform exists, adding another niche is mostly configuration, because the expensive part (the orchestration, the resilience, the gate) is shared. The marginal cost of the next vertical is close to nothing, which is only true because the fixed cost of building the autonomy was paid up front, in full, in exactly these boring places.

If you're building something that's supposed to run without you, that's where I'd tell you to spend your year. Not on the model. On everything that decides whether you can trust the model when no one is watching.

---

We design and build autonomous, production-grade pipelines like this end to end. If you've got a workflow you want to run without a human babysitting it, get in touch.