AI Content Pipeline
A content system that writes a draft and stops.
One shared system helps four WordPress properties find ideas, prepare research, create drafts, plan visuals, and deliver a complete CMS draft. It writes a draft and stops. A person reviews and publishes.
The production rules use configuration per property, so your sites can keep their own voice and review standards without requiring four separate automation stacks.
At a glance
Repeatable production with a clear human finish
4
configured WordPress properties
One shared system with separate rules, prompts, visual policies, and topics for each property.
9
controlled workflow stages
A clear path from discovery through draft delivery, with a separate final release step.
2
browser tooling generations
The current code uses Playwright and Sharp; the earlier single-property codebase used Puppeteer.
0
automatic live publishes
The delivery workflow creates a WordPress draft and stops for a person to review and publish.
The problem
Content operations break when every handoff is informal
Useful content needs more than a writing prompt. Someone must decide which ideas deserve attention, what the site already covers, whether research supports the angle, which visuals prove the point, and whether the CMS version is ready for review.
The shortcut is to collect a topic, ask a model to write, and publish. That shortcut becomes cleanup when titles repeat, output is incomplete, visuals are missing, or an unreviewed claim reaches a live page.
This system standardizes repeatable work while keeping editorial judgment and public release where they belong: with people.
How it works
Nine controlled steps from a topic signal to a WordPress draft
Every workflow stage produces something useful, leaves a visible outcome, and gives the next step a clear reason to continue. The final public release stays separate from this production flow.
01
Discover ideas for the right property
The workflow starts with a chosen property and gathers possible article ideas from its configured public sources. A marketing site, an editorial site, and a niche property can each start from different signals.
What it produces
A focused pool of candidate ideas that fits the property instead of one generic list for every site.
If it cannot continue
Rate limits and temporary network problems retry with measured waits, so one unavailable source does not turn into a blind writing run.
02
Remove titles the site already owns
Before a new idea enters the queue, its title is compared with stored article titles. This happens before the writing work begins, not after a finished draft has already used time and budget.
What it produces
A cleaner editorial queue with fewer repeated angles and less cleanup for editors.
If it cannot continue
The title check happens again before insertion, so the process does not rely on a single AI instruction to avoid duplicates.
03
Build a research brief
An approved idea becomes a focused brief with evidence, audience fit, keywords, and the intended article angle. A thin trend signal is not treated as publication-ready research.
What it produces
The writer begins with prepared context and the right instructions for that property.
If it cannot continue
Research is a separate stage, so it can be inspected or fixed without throwing away later work that has not started.
04
Create a draft, not a finished promise
The writer uses the research packet, site voice, and article type to make a draft. The draft carries its own title, slug, category, and review state so an editor can see what is being proposed.
What it produces
A reviewable article candidate rather than an untracked block of generated text.
If it cannot continue
Invalid or cut-off output is rejected and recoverable model problems have limited retry behavior.
05
Review the writing before visual work begins
Humanization, fact checking, and review sit between drafting and visual production. A successful draft does not automatically earn the right to take the next step.
What it produces
The visual and delivery work receives content that has passed the defined quality gates.
If it cannot continue
Malformed review output leaves the article in a reviewable state; it does not grant a false pass.
06
Plan each visual as a specific task
The draft describes the visual it needs in structured instructions, including where to go, what to show, and whether a person needs to sign in. That turns visual work into a clear request instead of a vague handoff.
What it produces
A planned visual queue that ties an image to a real product moment and a defined article need.
If it cannot continue
Each property decides whether a missing visual blocks delivery or creates a warning, so the policy is explicit.
07
Produce and check image assets
The current system uses a browser and image-processing tools to make or capture approved visuals. It records whether each request passed or failed instead of assuming every image was created.
What it produces
Article assets with known output state, quality settings, and a record of what belongs where.
If it cannot continue
A failed capture remains visible in the queue and can stop or warn the next step according to the selected property policy.
08
Send a complete article to WordPress as a draft
The delivery check confirms the article fields, links, visual state, and image placeholders before the WordPress handoff. It then creates or updates a draft, never a live post.
What it produces
A prepared WordPress draft that an editor can inspect in the normal CMS workflow.
If it cannot continue
Existing slug and title matches are checked before creating another post, and unresolved visual placeholders block normal delivery.
09
Keep the final release in human hands
Going live is a separate, manually started workflow. It is not a side effect of writing, visual production, or draft delivery.
What it produces
A person reviews the draft and makes the public publishing decision.
If it cannot continue
A problem on one property stays contained; concurrency controls also prevent active work from being canceled by another run.
The configurable multi-property controlsshow
A manual GitHub Actions workflow selects a site identifier, optional post identifier, content type, screenshot platform, and starting stage. Each property has its own pipeline, prompts, style guide, site rules, and topic configuration rather than being hard-coded into one blog flow.
The selected starting stage lets an operator resume deliberately instead of rerunning the whole chain. The content queue holds explicit states such as pending approval and reviewing before delivery can proceed; pool limits and review-score thresholds prevent a noisy discovery burst from becoming an unbounded writing run.
The research, draft, and review mechanicsshow
Discovery adapters collect configured public signals from sources such as search suggestions, community discussion, launch activity, and news-style feeds. Normalized lowercased titles and existing database articles are supplied to the idea-analysis prompt, then checked again before insertion.
Research, writing, humanization, fact checking, and review are independently addressable jobs. HTTP collection honors retry-after rate-limit instructions and uses exponential delay for transient failures. The writing prompt receives property voice and article-type instructions with its research context.
The writer persists a front-matter draft, validates output, rejects invalid or truncated results, and uses bounded retry behavior. Numeric review scores are validated before they can change state. A property can enable multi-model review while retaining a structured fallback path.
What a visual marker and visual queue actually containshow
Screenshot markers are structured data for the platform, view, site, authentication expectation, recipe, entry URL, and target description. Utilities retain navigation recipes, focus selectors, and verification hints for reusable states such as search, settings, and filtered views.
A session-capture utility opens a visible Playwright context, waits for a real operator login, confirms the session, and only then saves reusable state. The visual queue records passed and failed capture states, allowing a property policy to block delivery or issue a warning when an image is missing.
Current image tooling, CMS delivery, and the final release boundaryshow
The current generalized repository uses Playwright for rendered-image work andSharp for image-processing support. It can search visual references, use model-assisted selection, and produce controlled assets. Bounded workers record outcomes rather than assuming every visual request completed.
The earlier single-property codebase used Puppeteer to launch headless Chromium, set a 1200-by-630 viewport, wait for network idle, capture a PNG, and return a safe fallback if rendering failed. That is the predecessor, not the current browser runtime.
Before WordPress delivery, the pre-publish check verifies required fields, visual manifest state, unresolved screenshot placeholders, and link health. The WordPress REST adapter uploads media, maps placeholders into content blocks, checks existing posts by slug or title, and explicitly sends draft status. A separate manually dispatched go-live workflow owns public publication.
What the flow means for an editor
You start with a better queue, receive a prepared article draft with its visual needs understood, and see any missing work before the CMS handoff. The automation speeds up production without pretending that a first draft is ready for public release.
How the pieces fit together
One shared engine with separate editorial rules
Shared operations make the system easier to maintain. Property-level rules protect the differences that make each site useful to its own audience.
Property controls
Four configuration folders, prompts, style guides, topics, and workflow toggles
Each property keeps its own editorial rules while the shared engine stays maintainable.
Editorial work
Discovery, research, writing, fact checking, and review
Each content decision is visible as a stage, not hidden inside one all-or-nothing writing task.
Visual work
Structured markers, capture recipes, Playwright, and Sharp
Images are planned, produced, and checked against a clear article requirement.
WordPress delivery
Media upload, placeholder mapping, post lookup, and draft delivery
One boundary owns CMS details so the rest of the pipeline does not need to improvise them.
Operations
GitHub Actions inputs, dependencies, concurrency rules, and isolated stage commands
An operator can choose a property, inspect a failed stage, and restart deliberately without operating a separate workflow service.
Why a shared engine helps
You can support more than one site without losing the distinct voice and publishing rules that each one needs. A change to shared reliability work benefits every property, while an editorial decision stays local to the site it belongs to.
Automations and safeguards
Automation that knows where to stop
The system earns autonomy only for repeatable work. Originality, quality, visual completeness, and public release all have an explicit check rather than an assumption. A structured marker makes every visual request specific before production starts.
Duplicate protection in more than one place
Candidate titles are compared with stored articles during analysis, checked again before queue insertion, and checked in WordPress before delivery.
Draft is the default state
The writer marks content as a draft, the delivery adapter sends a draft status, and only a separate manual workflow can take a post live.
Review is a real dependency
Research, writing, humanization, fact checking, and review must clear their checks before visual production continues.
Missing visuals have a visible outcome
The visual queue stores passed and failed capture states, allowing each property to block delivery or show a policy-based warning.
Retries are finite and progress is recorded
Temporary network and model problems have limited retry paths, while article states make it clear what succeeded and what needs attention.
Each property keeps its own voice
Sources, prompts, topics, style, thresholds, and visual policies are configured per property rather than flattened into one generic set of rules.
The safety posture
The workflow writes a draft and stops. A person reviews and publishes. That boundary is not a slogan: it is enforced by separate delivery and go-live paths, with checks before either one can move forward.
This is where an editor sees the work: present in WordPress, but still waiting as a draft for human review.
What it replaces
From disconnected tasks to a dependable editorial operating system
Before
A content idea lives in browser tabs, notes, and an editor memory.
After
Signals enter a configured, duplicate-checked queue with a visible approval state.
Before
Research, drafting, screenshots, and upload are separate handoffs with unclear ownership.
After
Each stage has a name, a dependency, a retry boundary, and a stored outcome.
Before
A generic image can be attached late, or a missing visual can surface after review.
After
Structured visual requirements and pass-or-fail capture states make completeness checkable before delivery.
Before
A writing automation can accidentally connect a draft to a public release.
After
WordPress receives a draft and a distinct manually dispatched workflow is required to take anything live.
What this means for your business
More editorial output without a lower editorial bar
The value is not simply faster article generation. It is a repeatable production capability that makes the right work easier to review, troubleshoot, and extend across properties while keeping final judgment where it belongs.
- One shared engine can support several editorial properties without four disconnected automation stacks.
- Editors spend their time on judgment, accuracy, and voice instead of repetitive CMS preparation.
- The system can resume from a known broken stage, preserving work that has already passed its checks.
- Visual quality becomes part of the content contract rather than a best-effort task at the end of production.
- A human always reviews and publishes, even when the repeatable production work is automated.
Plain-language glossary
Every technical term used on this page, explained without jargon.
- Configuration
- A set of property-specific rules and settings that changes behavior without copying the whole system.
- Stored-title deduplication
- Comparing a proposed article title with titles already saved to avoid repeated subjects.
- Workflow stage
- A named step with a defined input, result, and failure outcome.
- Structured marker
- Data that describes a required visual in fields a person or system can follow consistently.
- Capture recipe
- Saved instructions for reaching and verifying a particular screen or product state.
- Playwright
- A browser automation tool used here for rendered-image work and authenticated session capture.
- Sharp
- An image-processing tool used in the current codebase to prepare image assets.
- Puppeteer
- The browser automation tool used by the earlier single-property implementation, not the current one.
- WordPress REST API
- The WordPress interface that lets software create or update posts and upload media.
- Slug
- The readable URL name used to identify a WordPress post.
- GitHub Actions
- A repository service that can run selected workflow steps and retain a record of each run.
- Concurrency control
- A rule that prevents overlapping work from competing to change the same item.
Build with control
Need a content pipeline that helps your team move faster without removing review?
AK Internet Consulting designs practical content automation around the controls your team actually needs: review states, visual checks, recoverable stages, and a deliberate public release decision.