The publishing pipeline
Every idea in Contentpipe travels the same route — from a one-line stub to a published article, spawning channel promos along the way. Here's how each status works and who moves it forward.
A publication is a single article. It carries exactly one status at a time, and that status determines what actions humans and agents are allowed to take on it. Statuses only ever move forward — except reopen, which sends an approved item back to draft for edits.
A stub is a title and an optional note. Agents can pick one up and draft it, or you can promote it to draft yourself and start writing. Batch-creating stubs is how campaign planning happens.
Overview
The pipeline is deliberately linear so that state is never ambiguous — at any moment you know exactly who owns an item and what happens next. Publications and their promos share the four middle statuses (draft, reviewing, approved, published) so the same review muscle memory applies everywhere.
stub ──▶ draft ──▶ reviewing ──▶ approved ──▶ promoting ──▶ published ──▶ archived
▲ │ │
└─────────┘ │ (request_changes)
└──────────────────────┘
The seven statuses
Each status pairs a color with a glyph, so the pipeline reads at a glance and stays legible for color-blind users.
| Status | Used by | What it means |
|---|---|---|
stub | publications | A raw idea — title plus an optional note. |
draft | both | Being written by a person or an agent. |
reviewing | both | Awaiting critique before it can be approved. |
approved | both | Signed off and ready to ship. |
promoting | publications | Live, fanning out into channel promos. |
published | both | Publicly visible on its destination. |
archived | publications | Retired from the pipeline — the outlier. |
Once a publication hits approved, Contentpipe can generate promos for every connected channel. Entering promoting is the natural moment for an agent to draft one promo per target channel.
Promos
When a publication reaches promoting, it fans out into channel promos — one per channel (Substack, X, LinkedIn, Bluesky, and more). Each promo runs its own mini-pipeline: draft → reviewing → approved → published.
draft ──▶ reviewing ──▶ approved ──▶ published
▲ │
└──────────┘ (request_changes)
Approved promos on auto channels are dispatched by the system through the upload-post API at their scheduled_for time. Channels without upload-post support (like Substack) are manual — a human publishes and records the URL.
Promos respect each channel's limits. A draft over the character cap (e.g. 280 / 280 on X) can't move to approved until it fits.
Automating with MCP
AI clients drive the pipeline over the Model Context Protocol. A client calls a workflow-level tool with an item id; the server validates the transition in the database and returns the updated item.
await client.callTool("submit_for_review", {
publication: "pub_9f21",
});
The tool maps to a SECURITY INVOKER Postgres function, so RLS and the transition triggers apply to the calling user exactly as they would in the admin UI.
Skipping statuses is rejected. Trying to jump a publication from draft straight to published raises an invalid-transition error naming the current status and the allowed next states — so the client can self-correct. Always go through review.