Why "AI writes your blog" usually fails
The standard setup is one agent with a prompt that says "write a post about X" and a human who reads it before publishing. It fails in two predictable ways. Either the human becomes the bottleneck and the cadence dies, or the human stops reading carefully and the quality drifts until something embarrassing ships.
The problem is that drafting and verifying are the same actor. An agent that writes a post and then checks its own post will pass it, because it already believes the post is correct. You cannot prompt your way out of that — it is a structural conflict of interest.
It is the same failure that catches teams wiring a single generation step together on ano-code agent platform: the canvas makes the chain easy to draw and does nothing to stop the drafting node from also being the approving node.
The chain of custody
We split the work across four agents, each with its own mandate and its own hard limits:
| Agent | Owns | Explicitly does not |
|---|---|---|
| Knowledge | What is working per platform, what changed, who to watch | Write anything. It curates. |
| Studio | Producing the draft from an approved topic | Decide what to write — that is approved upstream |
| QA | Verifying the artifact against the manifest | Know what Studio intended the result to be |
| Publisher | Getting verified work onto the platforms | Decide what publishes, or verify content itself |
The drafting agent's instructions are blunt about the boundary: "You don't decide WHAT to write — operator approved that (or a scheduled blog cron picked a non-duplicative topic from approved niches)." Note the second half — even the autonomous path is constrained to pre-approved niches and checked for duplication, so unattended runs cannot wander.
The publisher's three refusals
The shipping agent is the last line before something becomes public, so its limits are written as refusals rather than preferences. Verbatim from its own instructions:
- "You do not post without QA verification." No verification, no publish. There is no override flag.
- "You do not guess or use fallback auth." If credentials for a platform are not properly configured, it stops rather than improvising a way in.
- "You do not silently skip a platform." If one destination fails while others succeed, that failure is surfaced, not swallowed.
That third one is the least obvious and the most valuable. A publisher that quietly succeeds on two platforms and fails on the third looks green on every dashboard while a third of your distribution silently stops.
The runbooks
Each stage is a documented procedure the agent follows, not a freeform instruction. The drafting agent alone carries six: seed, draft,editor-review, humanize, post,publish-blog. Verification carries one — verify — and it is the same procedure every time, which is the point.
Writing the procedure down and having the agent execute it is what makes the output consistent across hundreds of runs. It is also what makes a failure debuggable: you know which step ran and what it was supposed to do.
What runs unattended
| Job | Cadence | Purpose |
|---|---|---|
| Primary blog publish | Tue + Fri, 09:00 | Topic → draft → verify → ship |
| Second content track | Mon + Thu, 10:00 | A separate publishing stream on its own schedule |
| QA daily sweep | Daily 11:00 | Verification pass over pending artifacts |
| Publisher daily check | Daily 10:00 | Confirms the shipping path is healthy |
| QA-to-publisher watcher | Continuous | Moves verified work forward automatically |
| Platform knowledge refresh | Weekly Sat 06:00 | Updates the per-platform playbook |
The drafting agent has logged 457 sessions, the most of any agent in our fleet. That is the volume the separation of duties has to survive — and the reason we would not run this without an independent verification step.
What broke — the honest part
Both publishing jobs were in a failed state at survey time, and the causes are worth showing:
- An upstream 500. The primary publish job hit a provider-side internal error. Nothing wrong on our side, and nothing our code could have prevented — which is precisely why a fallback path matters.
- No delivery target resolved. Both tracks hit a configuration state where the work completed but had nowhere to go. This is the single most common failure class across our entire fleet: eight of our scheduled jobs have hit it.
The lesson we take into client builds from this: wire the last mile before you celebrate a green run. A job that completes successfully and delivers nowhere is invisible in every model-level metric and completely useless to the business.
What this case study does not prove
- It does not prove content performance. Session counts and publish cadence are evidence of a system running. Traffic and conversions are a different claim and we are not making it here.
- It does not prove cost. Our host carries no per-task cost ledger. We will not publish a per-post figure we did not measure.
- It does not remove the human. Topic approval is still a gate, and the retention audit that decides whether a track keeps running only recommends — a person decides.
- It is not a client system. The second content track belongs to a client engagement under NDA; we are not naming it or publishing its output.
What we would carry into your build
Three transferable decisions, none of which require four agents: keep the agent that verifies ignorant of what the agent that drafted intended; write the shipping agent's limits as refusals with no override; and treat "delivered nowhere" as a failure, not a success.
If you want a publishing cadence you do not have to babysit, that is the shape of it. The same separation is what keeps thelead generation engine honest about which rows are actually contactable, and the wider sequence for putting a workflow behind agents is in automating a business process with AI agents.