Building a personal content pipeline: research, draft, review, and publish with OpenClaw

A personal content pipeline is the difference between publishing when you have energy and publishing on a schedule. This guide walks through building a fully automated pipeline with OpenClaw: your agent researches a topic, drafts the piece, runs it through a review pass, and delivers it ready to post. You don’t need a content team. You need the right cron jobs.

What a content pipeline actually is (and why most people overbuild it)

A content pipeline is a sequence of steps that takes a topic and produces a published piece. Most people think of it as a complex automation with many moving parts. In practice, a working pipeline has four stages and nothing else:

1. Research: Gather the information needed to write the piece. Sources, quotes, data points, context.
2. Draft: Write the piece from the research. Structure, voice, length.
3. Review: Check the draft against quality criteria. Fix what fails.
4. Publish: Deliver the finished piece to the publishing platform.

That’s it. Everything else is optional. A pipeline that does those four things reliably is more valuable than a complex system that does ten things unreliably.

OpenClaw can run all four stages. The question is how to structure them so the pipeline runs consistently, produces quality output, and doesn’t cost more than the content is worth. That’s what this guide covers.

Before you build: what you need

This guide assumes you have OpenClaw running on a server. You need:

• A running OpenClaw instance (if you don’t have one, read the setup guide first)
• A topic queue: a list of topics you want to publish about (can be a simple markdown file)
• A publishing target: WordPress, Beehiiv, Ghost CMS, or even just a folder of markdown files
• A model configured: deepseek-chat for drafting, a local model for research and review

You don’t need a writing background, editorial team, or prior automation experience. If you can paste a command into your OpenClaw agent and read the output, you can build this.

Stage 1: Research

The research stage takes a topic and produces a brief: a structured document with key points, sources, and any data the draft needs. The brief is the input to the draft stage. Getting the brief right is the most important step in the pipeline.

Here’s how to build the research stage:

Create a file at /home/node/.openclaw/workspace/pipeline/CONTENT-QUEUE.md with this structure:

## Topic Queue
| ID | Status | Topic | Angle | Target length | Published URL |
|—–|——–|——-|——-|—————|—————|
| T001 | PENDING | [your first topic] | [specific angle] | 1200 words | |

Add three topics you want to write about. For each one, note the specific angle (not just the topic, but the specific thing you want to say about it). Save the file.

The angle is what separates useful content from filler. “OpenClaw model routing” is a topic. “Why routing deepseek-chat for drafts and phi4 for scheduling cuts your content cost by 80%” is an angle. The angle tells the research stage what to look for.

Now build the research cron job:

Create a cron job that runs every day at 6 AM and does the following: Read /home/node/.openclaw/workspace/pipeline/CONTENT-QUEUE.md. Find the first PENDING topic. Search the web for 5-8 sources relevant to the topic and angle. Read each source and extract: the main claim, one supporting data point or quote, and any technical details relevant to the angle. Write a research brief to /home/node/.openclaw/workspace/pipeline/briefs/[ID]-brief.md with sections: Topic, Angle, Key Points (5-7 bullets), Sources (URLs with one sentence each), Data Points, and Draft Instructions. Update the queue to mark this topic as RESEARCHED. Send me a Telegram message with the topic and brief location. Use ollama/phi4:latest for this task.

This runs daily, picks one topic, researches it, and delivers a brief. You wake up to a brief ready for drafting. The phi4 model handles web search and summarization well and costs nothing.

What makes a good research brief

The brief is what your drafting agent reads before writing. A brief that’s too thin produces thin drafts. A brief that’s too long wastes tokens. The target is 400-600 words covering: the core claim, 5-7 supporting points, 2-3 specific examples or data points, and any constraints (don’t repeat X, don’t claim Y without data).

Read the brief at /home/node/.openclaw/workspace/pipeline/briefs/T001-brief.md. Does it have: a clear core claim? At least 5 supporting points? At least 2 specific examples or data points? Draft instructions that tell the writer the tone, length, and audience? If any of these are missing, add them now and save the updated brief.

Stage 2: Draft

The draft stage takes the brief and produces a complete article. This is the stage where model choice matters most. Use deepseek-chat for drafting. It produces clean, direct prose at roughly 10x the cost-efficiency of Claude Sonnet for writing tasks, and the quality gap is small for structured content.

Create a cron job that runs every day at 8 AM. It should: read /home/node/.openclaw/workspace/pipeline/CONTENT-QUEUE.md, find the first RESEARCHED topic, read the brief at pipeline/briefs/[ID]-brief.md, and write a draft article to pipeline/drafts/[ID]-draft.md. The draft should follow the brief’s instructions exactly. Use the core claim as the opening. Work through the supporting points in order. End with a clear conclusion. Target the specified length. Write in a direct, practical voice. No hedging, no filler phrases, no AI-isms. Use deepseek/deepseek-chat for this task. After writing, update the queue status to DRAFTED and send me a Telegram message with the topic and draft location.

The timing matters: research at 6 AM, draft at 8 AM. This gives the research cron job two hours to complete before the draft cron fires. If research takes longer (deep topics, slow APIs), adjust the gap.

Voice consistency

The hardest part of automated drafting is voice consistency. Without explicit guidance, deepseek-chat defaults to a generic AI writing voice: hedged, over-qualified, and stuffed with transitional filler. You can prevent this by putting voice instructions in the cron job prompt:

Add voice instructions to the drafting cron job prompt: “Write like a sharp practitioner who knows the subject and respects the reader’s time. Short sentences. No em dashes. No phrases like ‘it’s worth noting’, ‘let’s explore’, or ‘in today’s landscape’. No passive constructions where active is possible. If a sentence can be cut without losing meaning, cut it. The goal is density: maximum information per sentence, minimum friction.”

Add your own specific voice notes. If you write in a particular style, document it here. The cron job will apply it consistently across every draft.

Draft length targeting

Most content pipelines produce drafts that are either too short (the model runs out of steam) or too long (the model pads to hit a target). The fix is to specify length in terms of structure, not word count:

Update the drafting prompt to specify structure instead of word count: “The article should have: one opening paragraph that states the core claim, 4-6 H2 sections each covering one supporting point, one closing section that tells the reader what to do next, and a 5-question FAQ section covering the most likely reader questions. Do not add padding. Do not repeat points. If a section runs under 150 words, expand it with a concrete example. If a section runs over 400 words, cut redundancy.”

Stage 3: Review

The review stage checks the draft against quality criteria and fixes what fails. This is where most pipelines break down. They either skip review entirely (producing inconsistent quality) or run a review that’s too generic to catch real problems.

A useful review has specific criteria, not general ones. “Is this good?” is not a criterion. “Does the opening state the core claim in the first sentence?” is a criterion.

Create a cron job that runs every day at 10 AM. It should: find the first DRAFTED article, read the draft, and check it against these criteria: (1) Does the opening state the core claim? (2) Are there any em dashes, AI-isms (delve, dive deep, it’s worth noting), or passive constructions? (3) Does each H2 section have at least one concrete example? (4) Is the FAQ present with at least 5 questions? (5) Are there any factual claims that are vague or unverifiable? For each failure: fix it directly in the draft file. After all fixes: write a QA report to pipeline/qa/[ID]-qa.md listing what was checked, what passed, and what was fixed. Update the queue to REVIEWED. Send me a Telegram message with the QA summary. Use ollama/phi4:latest for this task.

The QA report is important. It creates an audit trail that lets you improve the pipeline over time. If the same issue keeps appearing in QA reports (e.g., weak FAQ sections), you know to fix the drafting prompt, not just patch each article individually.

Adding a human review step

Fully automated review works for high-volume, lower-stakes content. For anything going out under your name, add a human review step between Stage 3 and Stage 4:

After the QA cron runs, send me a Telegram message that says: “Draft ready for human review: [topic]. QA passed. Draft is at pipeline/drafts/[ID]-draft.md. Reply APPROVE to publish or REJECT with feedback to revise.” Wait for my reply before running Stage 4. If I reply REJECT, read my feedback, revise the draft, and send another APPROVE/REJECT message. If I don’t reply within 24 hours, send a reminder. If I still don’t reply after 48 hours, mark the topic as PAUSED.

This keeps you in the loop without requiring you to be in the loop on every step. The pipeline handles research, drafting, and QA. You only see the output once it’s already good.

Stage 4: Publish

The publish stage takes a reviewed draft and delivers it to the publishing platform. The exact implementation depends on your platform, but the pattern is the same everywhere: read the draft, format it for the platform, post it via API, update the queue.

Publishing to WordPress

Create a cron job that runs every day at 2 PM. It should: find the first REVIEWED article with APPROVED status (or REVIEWED if you skipped human review). Read the draft. Convert the markdown to HTML (wrap paragraphs in p tags, headings in h2/h3, lists in ul/li). Post to WordPress using the REST API at [your WordPress URL]/wp-json/wp/v2/posts with status “publish”, the title from the queue, and the converted HTML as the content. Save the returned post URL. Update the queue with the published URL and status PUBLISHED. Send me a Telegram message with the title and URL. Use ollama/phi4:latest for the formatting; use no model for the API call (just curl).

Publishing to Beehiiv

Beehiiv has a publications API that accepts HTML content. The pattern is similar:

I use Beehiiv for my newsletter. Set up a publish cron job that posts drafted articles to Beehiiv as drafts (not published yet). Use. Use the Beehiiv API at https://api.beehiiv.com/v2/publications/[pub_id]/posts. Save the draft URL and send it to me via Telegram. Mark the queue entry as BEEHIIV_DRAFT.

Publishing to markdown files (no CMS)

If you’re not using a CMS, the simplest publish stage saves the reviewed draft to a specific directory and optionally commits it to git:

Create a publish cron that copies reviewed drafts to /home/node/.openclaw/workspace/published/[YYYY-MM-DD]-[slug].md and commits them to git with the message “publish: [topic]”. Send me the git commit URL via Telegram.

Wiring the four stages together

Each stage runs on its own cron schedule. The queue file is the handoff mechanism. Each stage reads the queue to find its input and writes the queue to signal completion. Here’s the full schedule:

• 6:00 AM: Research cron: picks PENDING topic, produces brief, marks RESEARCHED
• 8:00 AM: Draft cron: picks RESEARCHED topic, produces draft, marks DRAFTED
• 10:00 AM: Review cron: picks DRAFTED topic, runs QA, marks REVIEWED and sends Telegram for human approval
• 2:00 PM: Publish cron: picks APPROVED topic, posts to platform, marks PUBLISHED

One topic moves through the pipeline per day. If you have five topics in the queue, you get five published pieces over five days. If you want to run faster, add more topics and shorten the gaps.

Set up all four cron jobs now. Use the schedule above. After creating each one, tell me its cron ID so I can track them. Then run the research cron manually against the first topic in my queue and show me the output brief.

Handling failures gracefully

The pipeline will fail. Web searches return nothing. APIs time out. Drafts miss the mark. Building failure handling in from the start prevents a single failure from silently blocking the whole queue.

Add failure handling to each cron job: if a stage fails for any reason, mark the topic as FAILED in the queue with the error message in the Notes column, and send me a Telegram message with the topic ID and error. Do not retry automatically. I will review failed topics manually and either fix the issue and mark them PENDING again, or archive them.

Manual failure review sounds tedious but it’s the right call for a personal pipeline. Automatic retries can loop, produce duplicate work, or compound errors. A Telegram message when something fails means you catch problems without babysitting the cron jobs.

Cost breakdown (March 2026 pricing)

A content pipeline should cost less than your coffee habit. Here’s the breakdown for one article through the full pipeline using the model routing in this guide:

• Research (phi4:latest): $0.00 (local model, zero API cost)
• Draft (deepseek-chat): ~$0.04 for a 1,200-word article at current pricing (~$0.50/M input tokens, ~$2/M output tokens)
• Review (phi4:latest): $0.00 (local model)
• Publish (curl, no model): $0.00

Total cost per article: approximately $0.04. That’s $1.20/month for a daily publishing schedule. If you add a human review Telegram exchange (a few back-and-forth messages through your agent), add another $0.01-0.02. Still under $2/month for 30 pieces.

Compare this to hiring a freelance writer ($50-200/piece), using a content platform subscription ($50-300/month), or running the same pipeline through Claude Sonnet (~$0.40/article at 10x the cost).

Improving quality over time

The first ten articles from an automated pipeline are usually the worst. The pipeline improves when you feed your feedback back into the prompts. Here’s how to do it systematically:

Create a file at /home/node/.openclaw/workspace/pipeline/VOICE-NOTES.md. After each published article, add one note: what I liked about this piece, and one thing I’d change. After every 5 articles, read VOICE-NOTES.md and update the drafting cron job prompt to incorporate the patterns I keep flagging. Tell me when you’ve updated the prompt and summarize the changes.

This creates a feedback loop. The pipeline gets better at your specific voice over time. After 20-30 articles, the drafts will require fewer human review changes. After 50, many pieces can go straight from QA to publish.

Troubleshooting common pipeline problems

The research cron finds no relevant sources

This usually means the search query is too broad or the angle is too narrow to have much coverage. First, check how the research cron is constructing its search query:

Show me the exact search queries you ran for the last failed research task. What search terms did you use, and how many results did each return?

If the queries are too specific, broaden them. If they’re too broad, narrow them. The sweet spot is 3-5 search queries per topic, each targeting a different aspect of the angle. If searches return zero results across all queries, the angle may be too niche for current web coverage. Consider revising it in the queue.

The draft doesn’t match the brief

If the draft agent is consistently ignoring parts of the brief, the brief format is probably the problem. Agents read briefs better when key instructions are at the top, not buried in a long document. Restructure your brief template:

Update the brief template so the structure is: (1) WRITE THIS FIRST: [core claim, one sentence], (2) MUST INCLUDE: [required points as bullet list], (3) MUST NOT INCLUDE: [things to avoid], (4) AUDIENCE: [who this is for], (5) FORMAT: [structure instructions], (6) SOURCES AND CONTEXT: [research from web search]. Put instructions before context, not after.

The QA cron marks everything as passing but quality is still low

The QA criteria are too loose. “Does each section have a concrete example?” is a criterion a mediocre agent can fake by including a vague reference. Sharpen the criteria:

Update the QA cron with sharper criteria: for each concrete example, it must include a specific number, name, date, or command. Not a generic reference. For each factual claim, the source URL must be cited. For each H2 section, the last sentence must either give the reader something to do or state a direct consequence. Flag any section that fails these specific tests.

The pipeline runs but nothing publishes

Usually a status mismatch. The publish cron looks for APPROVED status but the human review step is marking things differently, or the human review Telegram message got lost. Run a diagnostic:

Read the CONTENT-QUEUE.md file. Show me the current status of every topic in the queue. For any topic that has been in REVIEWED status for more than 24 hours without an APPROVED or REJECTED status, what happened? Did you send a Telegram notification asking for approval? If not, send it now.

The draft stage is slow and times out

deepseek-chat is generally fast, but 1,200-word drafts can take 30-60 seconds. If your cron timeout is shorter, the job appears to fail even though the draft was written. Check the cron timeout setting:

Check the draft cron job settings. What is the current timeout? If it is less than 300 seconds, update it to 300. Show me the updated cron job configuration.

Advanced patterns: scaling and specializing the pipeline

Running multiple topics in parallel

The basic pipeline runs one topic per day through the queue sequentially. To increase throughput, you can run multiple topics in parallel by adding topic IDs to each stage’s scope:

Update the research cron to pick the first 3 PENDING topics instead of just one. Research all three in sequence (not in parallel, one at a time), writing a brief for each. Mark each as RESEARCHED after its brief is written. This runs 3 topics per day through the research stage, so the drafting and review stages will also need to handle multiple inputs. Update those crons to process up to 3 RESEARCHED/DRAFTED items per run respectively.

Topic-specific voice profiles

Different topics sometimes need different tones. Technical tutorials call for precision and brevity. Opinion pieces need a stronger point of view. Listicles need punchy, scannable structure. You can add a “voice profile” column to your queue and have the draft cron apply different instructions per profile:

Add a “voice_profile” column to CONTENT-QUEUE.md with these options: technical (precise, command-heavy, minimal prose), conversational (direct but warmer, more examples), and listicle (numbered, each item standalone, punchy). Update the draft cron to read the voice_profile for each topic and apply the corresponding style instructions. Show me the updated prompt for each voice profile.

SEO-optimized drafts

If your content pipeline feeds a public website, adding keyword targeting to the brief-to-draft flow costs nothing and improves organic reach. The research stage is where this belongs:

Add a “primary_keyword” and “secondary_keywords” field to the CONTENT-QUEUE.md schema. When writing the brief, include a “SEO target” section that lists the primary keyword, 2-3 secondary keywords, and the recommended H2 structure based on what ranking articles are using for this topic. Pass these targets to the draft cron, which should use the primary keyword naturally in the first paragraph and at least one H2 heading, and include the secondary keywords at least once each.

Content repurposing from a single draft

One well-researched draft can produce multiple pieces. Adding a repurposing stage after publish extracts more value from each research cycle:

After an article publishes, create a repurposing cron that runs 1 hour after publish. It should read the published article and produce: (1) a 300-word summary version suitable for a newsletter section, (2) a 5-tweet thread of the key points, and (3) a 150-word LinkedIn post with the article link. Save each to pipeline/repurposed/[ID]-newsletter.md, [ID]-thread.md, and [ID]-linkedin.md. Send me the three outputs via Telegram for review. Use phi4:latest for this since it’s summarization, not original writing.

Building a topic suggestion system

Running out of topics is a common pipeline problem. You can have your agent suggest new topics based on what’s performing well and what gaps exist in your current content:

Every Sunday at 9 AM, read CONTENT-QUEUE.md. Look at the PUBLISHED entries and identify which topic categories appear most often. Then search the web for trending topics in those categories that I haven’t written about yet. Suggest 5 new topics with specific angles, formatted as queue rows ready to add to the PENDING section. Send the suggestions to Telegram. Wait for my approval before adding any to the queue.

Integrating the pipeline with your existing writing workflow

Most people who build a content pipeline don’t replace their existing writing workflow overnight. They run the pipeline in parallel for lower-stakes content while continuing to write high-stakes pieces manually. Here’s how to structure that hybrid approach:

• Tier 1 (manual): Flagship pieces, opinion content, anything going out under your byline with high stakes
• Tier 2 (pipeline with human review): Regular content, tutorials, explainers. Pipeline drafts, you review and approve
• Tier 3 (fully automated): High-volume, lower-stakes content like social posts, newsletter summaries, roundups

Add a “tier” column to your queue and configure the review step to skip human approval for Tier 3 topics. This gives you control where it matters while letting the pipeline run autonomously where it doesn’t.

Add a “tier” column to CONTENT-QUEUE.md (values: 1, 2, or 3). Update the review cron to check the tier before sending a Telegram approval request: Tier 1: always require approval; Tier 2: require approval; Tier 3: auto-approve and proceed directly to publish. Show me the updated review cron logic.

Using your own past writing as a voice reference

The clearest way to lock in your voice is to give the draft cron examples of writing you like. This is more reliable than describing your voice in abstract terms:

Create a file at pipeline/VOICE-SAMPLES.md. I’ll paste 3-5 excerpts of writing I’ve done that I consider representative of my voice. After I add the samples, update the draft cron to read VOICE-SAMPLES.md before drafting and include this instruction: “Write in a voice consistent with the samples in VOICE-SAMPLES.md. Match the sentence length patterns, vocabulary level, and level of directness. Do not copy sentences. Match the style.”

Measuring pipeline output quality over time

Without measurement, you don’t know whether the pipeline is improving. A simple quality log gives you the data to improve the prompts:

After each article publishes, add a row to pipeline/QUALITY-LOG.md with: the article ID, publication date, how many revision passes it needed before I approved it, one specific strength, and one specific weakness. At the end of each month, read the log and identify the top 3 recurring weaknesses. Suggest updates to the drafting or review prompts to address them. Send the analysis to Telegram.

Adding a social media distribution stage

Once your core four-stage pipeline is running, adding a fifth stage for social distribution is straightforward. The article is already written and reviewed. The social stage just extracts the key points and reformats them for each platform. This is the kind of task phi4 handles well, so the distribution stage costs nothing in API fees.

Social distribution is also where compound returns show up. An article that gets published once reaches the people who find it. An article that gets distributed as a thread, a LinkedIn post, and a newsletter excerpt reaches three different audiences who might never have found the article directly. The pipeline does the work; you get the reach.

After an article publishes, create a fifth cron job that runs 30 minutes after the publish cron. It should: read the published article title and first paragraph, write a Twitter/X thread (3-5 tweets) based on the article’s key points, write a LinkedIn post (150-200 words, professional tone, link to article), and send both drafts to me via Telegram for approval. After I approve, post the thread and LinkedIn post. Use deepseek-chat for writing; use the relevant platform APIs for posting.

What the pipeline looks like once it’s running

After the setup is complete and you’ve run one full cycle, the pipeline becomes invisible. You add a topic to the queue on Monday. Tuesday morning you wake up to a Telegram message with the research brief. Wednesday the draft arrives. Thursday the QA report clears. You approve it via Telegram reply. Friday the article is live. The whole week required less than five minutes of your attention.

That’s the point. Not to eliminate your involvement, but to compress it. You make the decisions that matter (what to write, whether the draft is good enough to publish) and the pipeline handles everything else. The research, the drafting, the formatting, the QA, the API call to publish.

After 30 days, you have a month of consistent publishing. After 90 days, you have a body of work that would have taken a full-time content writer to produce. The cost difference is significant: a full-time content writer in the US runs $50,000-80,000/year. This pipeline runs under $30/year at current API pricing with the model routing in this guide. The quality gap closes faster than most people expect. So does the time savings.

Frequently asked questions

How long does the full pipeline take to set up?

Two to three hours for the initial setup if you follow this guide. Most of that time is configuring the cron jobs and testing each stage end-to-end. Once the four jobs are running and you’ve confirmed a full cycle (research through publish) works, ongoing maintenance is minimal: add topics to the queue, review Telegram notifications, occasionally update prompts based on quality feedback.

Do I need to know how to code?

No. Every step in this guide is done by pasting a prompt into your OpenClaw agent. The agent writes the scripts, creates the cron jobs, and handles the API calls. Your job is to describe what you want and review the output.

What if my publishing platform doesn’t have an API?

Use the markdown file publishing option and copy-paste manually. The pipeline still saves you all the research and drafting time. The only manual step is the final copy-paste. For most publishing platforms that matter (WordPress, Ghost CMS, Beehiiv, Substack, Medium), APIs are available.

How do I prevent the agent from writing about the same topics twice?

The queue file handles this. Once a topic is marked PUBLISHED, the pipeline won’t pick it up again. For topic suggestions that might overlap with existing content, add a check: before marking a topic PENDING, have your agent search the published folder for similar topics and flag potential duplicates.

Can I run the pipeline faster than one article per day?

Yes. Run the cron jobs every 6 hours instead of once daily. With a 6-hour schedule, you can produce 4 articles per day. The cost stays under $0.20/day. Watch for API rate limits on your web search tool if you’re running high volume.

What topics work best for an automated pipeline?

Topics that are informational and specific. “How to do X in OpenClaw” works well. “Opinion piece on the future of AI” works poorly. Automated drafts of opinion pieces sound like AI. The pipeline is best suited for practical, factual, instructional content. Save the opinion writing for when you write it yourself.

How do I keep the research fresh for topics that change quickly?

Add a date filter to your research brief: “Only include sources published in the last 30 days.” This keeps the brief current. For evergreen topics, remove the date filter and let the agent find the best sources regardless of date. The distinction between time-sensitive and evergreen content belongs in your queue. Add a column for “freshness” and configure the research cron to apply the date filter accordingly.

What if the draft stage produces something completely wrong?

The human review step catches this before it publishes. If you’re not using human review, the QA stage should catch factual issues through its “vague or unverifiable claims” criterion. When a draft comes back completely off-target, read the brief. The brief is usually the problem. Improve the brief and requeue the topic.

Keep Reading: