An AI content workflow on Claude Code has four parts: a brief that tells the agent how to write and what to publish next, a queue it reads in priority order, a scheduled job that runs Claude Code and commits one article per run, and a pull request a human approves before anything goes live.
Most people experiment with AI content by asking Claude to write a blog post. They paste a topic in, get something back, edit it, and publish. That works once. It does not work forty times at consistent quality, because what they are doing is prompting, not building.
The difference between prompting and building is structure. A prompting workflow lives in the conversation window. A content workflow lives in the repository. The system is persistent, the brief is the fixed point, and the human is at exactly the right place in the loop: the end, where it matters, not distributed through every step where it slows things down.
Here is how to build it.
Step 1: The Repository Is the Spine
The workflow lives in a git repository. That is not an architectural preference. It is how the review gate works.
Every article the agent writes lands in a feature branch. Every branch becomes a pull request. Every pull request is reviewable, line-by-line, before anything reaches production. Git gives you something a document tool or a CMS cannot: a complete audit trail of what the agent wrote, when, and what changed before it shipped.
The repository needs four things in place before the agent can run usefully.
A content directory the agent writes into. For an Astro site this is src/content/blog/. For a Next.js site it might be content/posts/. The agent needs the path specified in its instructions, not left to infer.
A planning directory for the brief files and the queue. Keeping these in version control means the agent always reads the current instructions. The humans managing the pipeline can update the queue or refine the voice rules with a simple commit, and the change takes effect on the next run.
A CLAUDE.md file at the root with the agent’s operating instructions. This is Claude Code’s native instruction mechanism. The agent reads it at the start of every session. It is where the brief, the queue reference, and the workflow steps live.
A GitHub Actions workflow that triggers on a schedule. A cron expression like 0 8 * * 1-5 runs the pipeline at 8am UTC on weekdays. The workflow authenticates Claude Code, runs the agent, and opens a draft PR. That is the mechanism. Nothing fancier is needed.
Step 2: The Brief Is the Fixed Point
The brief is a markdown file the agent reads before doing anything else. It is where the entire editorial identity of the content operation lives.
A brief that works needs to tell the agent five things: who it is writing as (tone, rhythm, specific phrases it must never use, which variant of English), who it is writing for (the reader, their intent, what they know, what they want to do after reading), what the site is trying to do commercially (which CTA to use when, what the product is, what has been retired and must not be mentioned), what has already been published (a log of live slugs so the agent never duplicates), and what to write next.
That last part is the queue: a prioritised list of article briefs, each containing the slug, the primary keyword, the argument the article should make, the target word count, and the CTA to close with. The agent reads from the top and picks the first unpublished item.
This is the part most people skip when they try to build an AI content pipeline. They write a long system prompt and wonder why the output drifts after a few weeks. The brief is what prevents drift. It is the stable point the agent returns to every run, regardless of how the model or the tooling changes underneath it.
The brief as control surface piece covers the structural reason this matters. The principle there is about AI marketing platforms; the same principle applies to agent-driven content pipelines. The brief is not a prompt. It is an operating document. Prompts are one-off. Operating documents compound.
A good brief also captures what the site is not. The things the agent should never say, never link to, never mention. Those negative constraints are often more important than the positive ones. The positive case fills itself in from the queue. The negative case is what stops the agent from producing something plausible-sounding but wrong.
Step 3: The Scheduled Agent
The agent runs via a GitHub Actions cron job. The job calls Claude Code through the CLI, passes the repository and the CLAUDE.md instructions, and runs the full workflow from reading the brief to committing the article.
What happens in one run:
The agent reads the brief files and the queue. It identifies the first unpublished item. It writes the article body following the structure and voice rules in the brief. It commits the file with a descriptive commit message. It updates the tracking log to mark the item as done. Then it opens a draft PR for human review.
Each run produces one article and one commit. Not a batch. The design choice matters: batching articles into a single PR feels efficient but breaks the review gate. A PR containing eight articles is difficult to review properly. Reviewers skip sections, defer difficult calls, and end up approving more than they have actually checked. A PR containing one article takes two minutes to review correctly.
The commit message format should be fixed and machine-generated, something like content: publish [slug]: [primary keyword]. This makes the PR list readable at a glance. When you are managing a daily pipeline, you want to open the PR list and know immediately what is in each one.
The agent does not push to main. It commits to a branch, opens a draft PR, and stops. Production waits for a human.
This is the same pattern used to rebuild this site with Claude Code: the agent does the mechanical work, produces a reviewable diff, and then steps back. The merge decision is always a human call.
Step 4: The PR Review Gate
The pull request is where human judgement re-enters the loop. The agent writes the article. A human reads it, checks it against the brief, and decides whether it meets the quality bar before it goes to production.
This step is not optional. The PR gate is what makes the pipeline publishable rather than merely generatable. Without it, you have a system that produces content at scale. With it, you have a system that produces content you have actually stood behind.
The review is fast when the brief is good. The brief determines the ceiling. If an article lands badly, the brief is almost always where the problem is. Wrong tone, wrong structure, wrong CTA: all of these trace back to something the brief left ambiguous or left out. Fix the brief, re-run. The article improves. The pipeline gets better without anything being retrained.
A few things that make the review gate work well in practice.
The PR description should include the primary keyword, the word count, and the CTA. These are the three things a reviewer checks first. If the PR carries them in the description, the review starts in thirty seconds.
The diff should be clean. One article per PR means one markdown file in the diff. The reviewer can read the whole thing in the GitHub diff view. No tab-switching, no CMS navigation.
The draft PR status is a clear signal: ready for review, not ready for production. Nothing merges automatically. Nothing ships to the live site until a human clicks the button.
The Cost Cap Pattern
A content pipeline running daily can spend unpredictably if the agent is not constrained. An agent on a research-heavy brief that starts opening pages and running search queries can reach ten or fifteen pounds per run before anyone notices. Over a month of daily runs, that is a significant and entirely avoidable cost.
The cost cap pattern solves this by building hard limits into the brief itself.
The brief specifies a maximum number of web searches per run, typically around five, and a maximum number of page fetches, typically around three. When the agent hits those limits, it stops researching and writes the article with what it has. The quality ceiling on research-heavy topics drops slightly. The cost stays predictable.
The right way to think about this: the cap is a constraint on research, not on writing quality. Writing quality is determined by the brief. A well-specified brief produces a good article with zero external research. The search and fetch calls are for fresh data points and third-party citations, which most briefs do not need.
Logging the approximate cost per run in the agent’s output means you know immediately when something has gone wrong. A typical run should land under fifty pence. A four-pound run is a signal to investigate.
The target for a daily pipeline on weekdays only is under ten to fifteen pounds a month. That is achievable with the caps in place and a brief specific enough that the agent rarely needs to reach outside the repository.
The System Is the Point
The question worth asking is: why build all of this rather than just asking Claude to write articles on demand?
The answer is consistency, not throughput.
A prompted workflow produces good articles when you give it good prompts on a good day. A pipeline workflow produces consistently adequate-to-good articles because the brief is always there, always current, and the agent always reads it before writing. The quality floor is higher because the operating conditions are more stable. You are not relying on having the right context loaded each time.
It also means the editorial identity accumulates in a place you can maintain. Each brief update is a commit. Each voice refinement is in version control. The system gets better over time and none of that improvement lives in someone’s head or in a conversation window that will eventually be cleared.
The Blueprint covers the five-agent version of this architecture: a separate voice brief, an identity brief, a job brief, a dedicated SEO agent that feeds the queue, and a social agent that adapts each piece for LinkedIn. Each agent reads the same core briefs and hands off cleanly to the next. It is the same four-stage pipeline described here, scaled to a full content operation.
The single-agent version in this article is the right place to start.