How We Publish
Four stages from idea to live post. A human creates the content and gives one approval: a publish date and a move to scheduled. A daily routine handles everything after that: validation, the live page, the index, and the report.
Human in front, routine behind
The handoff is a status change: a human sets the publish date and moves the post to scheduled. Everything before it is human judgment. Everything after it is automated.
The four stages
Posts start as blog entries on the marketing calendar, from the content plan or an ad hoc idea. The drafting itself is the writer agent's job: it drafts, edits, optimises, illustrates and assembles the post step by step, and hands the result to a human. No publishing happens here, just the asset taking shape.
The final human review. The reviewer reads the copy, checks the hero image and the SEO plan, sets the publish date, and moves the asset to scheduled. That status is the approval; the routine never touches a post that is not scheduled. An admin who wants it live now can press Publish instead, which runs the same core the routine does.
Once a day the routine picks up every scheduled blog asset whose publish date has arrived and runs each through the same deterministic publish:
- Resolves the destination site from the asset's brand; a brand without a live blog is refused
- Validates: body copy of at least 600 words, a hero image, an FAQ, and an SEO plan with a unique kebab-case slug, a title tag and a meta description
- Normalises the SEO plan into columns (slug, title tag, excerpt, keyword, category, read time) and flips the status to published
- Revalidates the post page, the blog index, the sitemap and llms.txt, so the post is live the moment the run ends
A post that fails validation stays scheduled, is retried on the next run, and is named in the report. A bad post never silently disappears.
After publishing, the routine fetches the live URL and stamps it on the asset when it answers. Each run is recorded on Settings → Agents with how many posts it checked, published and failed, and every published post gets an audit row. When anything happened, the ops Lark chat gets one message listing what went live with its URL and what was held back with the reasons. When nothing is due, the run says so and sends nothing.
The seven elements
Every workflow we document has the same anatomy: seven elements, each assigned to a human, a machine, or both. This is the Centaur Map from our workflow design method.
The content calendar or an ad hoc idea. Content starts with a human wanting to say something.
The approved copy, the hero image, and the SEO plan (slug, title tag, meta description) the writer agent drafted and a human signed off.
The approval gate: a human reviews the post, sets its publish date, and moves it to scheduled. Nothing ships without it.
The asset’s brand decides the destination site. A brand without a live blog is refused, never published to the wrong domain.
A live post page, a refreshed blog index, sitemap and llms.txt, and the asset stamped published with its live URL.
A daily routine publishes whatever is scheduled and due, then fetches the live URL to prove it. No manual upload, no deploy.
The run log on Settings → Agents (checked, published, failed per run), the audit row per post, and the ops Lark message naming every post that went live or was held.
Quality gates before anything ships
- Only blog assets, only when scheduled and due
- A hero image, at least 600 words, and an FAQ block for structured data
- A valid slug nobody else is using, a title tag and a meta description
- A brand with a live blog to publish to, or the post is refused
Why it works
- One approval gate keeps humans in control of what gets said
- The button and the routine share one publish core, so the result is identical either way
- The run log and the audit row mean every post can be traced to a run
- Writers write. Nobody hand-edits pages or deploys anything.