The Editor’s Stack is an architecture for B2B content operations that runs AI agents through a human review gate. Work moves through five stages: research that surfaces the topic, a brief that encodes voice and positioning, a writer agent that executes the brief, a human gate that decides what ships, and a pipeline that deploys only what the gate approved.
That is the direct answer. Here is the part that makes it worth understanding.
The terms “content engine” and “content factory” have been in circulation for years, and they share a hidden assumption: that volume is the point. The engine runs faster. The factory produces more units. Both treat content as the thing you are trying to maximise, and throughput as the signal that it is working.
Add AI to that frame and you get faster volume. Which is useful, right up until you notice what got lost. The reason the content exists. The argument it is supposed to make. The reader it is trying to reach, and what you want them to do when they arrive.
That is not an execution problem. It is an architecture problem. It is why most AI-assisted content operations produce copy that is technically competent and strategically inert. The tools are running. The thinking is missing.
The Editor’s Stack is an architecture, not a template. The Blueprint documents the agents that run it. This article is about the five stages the work itself moves through, which stay constant across implementations. What changes is how each is configured for the specific brand, audience, and commercial goal it is serving. The system holds when the context changes because the underlying logic stays fixed.
Here is how each stage works, and why it matters in that position in the sequence.
The Research Agent: Where the System Is Pointed
Most content operations have a topic problem. Someone monitors keyword tools. Someone chairs a planning meeting. Someone forwards the article the CEO shared on LinkedIn. The output is a list of ideas that optimise for what is easiest to find, not what is genuinely valuable to write.
A research agent changes the shape of that process. Pointed at the right data sources, it surfaces bottom-of-funnel keyword opportunities where the brand should have authority but does not yet appear. It monitors which questions are showing up in AI-generated answers but are not answered well on the site. It flags citation gaps: the content types that earn reference from other publishers that the brand could be producing and is not.
The research agent is not the intelligent part of the system. It is the targeting mechanism. It keeps the brief and the writer pointed at the right problems. Without it, the system can execute well on the wrong topics. With it, the effort concentrates where it has the highest chance of producing something that ranks, gets cited, and converts.
The output is not a finished idea. It is a brief waiting to be written. That distinction matters, because the research agent does not decide what to say. It identifies where the brand has something useful to say that no one else is saying well yet.
The Brief: The Control Surface
This is the stage most people underestimate, which is also the reason most AI-assisted content feels interchangeable. The brief is not a prompt. It is not a style guide. It is the document the writer agent consults to decide what to produce, in what voice, for whom, and toward which commercial goal.
A working brief for a content operation has three layers. A voice document captures tone, register, sentence rhythm, and the specific phrases the brand must never use, written precisely enough that an AI cannot substitute a generic alternative without violating an explicit rule. A positioning document defines the audience specifically enough that the writer agent can self-correct when copy starts to sound like it could have been written for anyone. And a job brief for each article names the primary keyword, the search intent, the structural requirements, and the conversion goal.
The reason this matters is that brief writing is now a technical skill. Every major AI marketing platform now executes against briefs rather than manual configurations. The quality of the output is bounded entirely by the quality of the brief. There is no workaround for vague positioning. The agent is precise. The brief has to be too.
The most common failure mode I see is teams treating the brief as a prompt, handing the agent a paragraph of rough instructions and wondering why the output is rough. A brief is not a message to the agent. It is the permanent operating context the agent lives inside every time it runs.
The Writer Agent: Controlled Execution
The writer agent executes the brief. It reads the voice document, checks the positioning, takes the article job brief, and produces a draft. It does not brainstorm. It does not decide what to cover. It does not choose the CTA. Those decisions were made upstream.
The writer agent’s job is controlled execution: direct-answer opening, structured argument, no banned phrases, internal links to the correct pages, the right conversion goal at the end. The output is markdown. It is not a strategic draft that needs reconsidering. It is an editorial draft that needs reviewing.
This constraint is intentional. The agent is capable of producing almost anything. Constraining it to the brief is what makes the output worth reading rather than discarding. The strategic intelligence lives in the brief. The execution intelligence lives in the agent. The quality gate lives at the next stage.
The separation also makes the system diagnosable. When the output is wrong, the question is never “the agent went rogue.” The question is always “which instruction in the brief was unclear.” That is a manageable problem with a fixable answer.
The Review Gate: The Part You Cannot Automate
The review gate is where a human reads the draft and decides whether it ships. This is not the automation stopping. It is the system working.
The gate is where the brief meets reality. It is where you discover that the agent interpreted an instruction correctly but produced something that lands wrong in context. Where you catch the half-accurate claim that technically passes the voice rules but reads as hollow. Where you find the internal link that makes sense mechanically but feels like a plug rather than a reference.
Without the gate, the system drifts. Not immediately. One article at a time, the brand voice shifts slightly. The argument becomes a little blunter. The positioning becomes a little vaguer. By the time anyone notices, thirty published articles no longer quite sound like the brand they were written for.
With the gate, the system learns. Every intervention is data. The brief gets sharper because the reviewer can see exactly which instruction was ambiguous. The writer agent’s next run is tighter because the edge case has been documented. Over time, the volume of revisions drops. Not because the agent improved, but because the brief absorbed the corrections.
The review gate is not a cost. It is the mechanism by which the system earns the right to keep running. Strip it out and you do not have an efficient content operation. You have an efficient noise machine.
The Publish Pipeline: Enforcement at the Boundary
The publish pipeline enforces what the review gate approved. Nothing ships until it passes the gate. Nothing bypasses the pipeline. The pipeline does not negotiate.
In a working implementation, this is a version-controlled deploy workflow. The writer agent commits a draft to a branch and opens a pull request. The human reviewer reads the pull request, checks how the article will render, and either merges or closes it. If merged, the pipeline deploys automatically. If closed, the draft is discarded and nothing reaches the public site.
This separation matters because it removes the human from the deployment step while keeping the human in the approval step. There is no “I’ll just push this one directly.” There is no deadline shortcut that skips the gate. The pipeline is the trust mechanism: it demonstrates that every article on the site cleared human editorial judgement before it went live.
The infrastructure gap that trips most teams when they first try to give an AI agent publishing access is exactly this one. They either hand the agent too much control, or they preserve so much manual work in the loop that the automation saves nothing. The pipeline pattern threads that needle by separating approval from deployment. The human makes the call. The machine executes it.
How the Pattern Flexes
The five stages stay constant. What changes is how they are configured for the brand and the scale they are serving.
For a B2B SaaS, the research agent monitors competitor citation gaps and product-adjacent keyword clusters. The brief carries formal positioning documents and ICP definitions that read closer to a sales playbook than a blog guide. The writer agent targets long-form, bottom-of-funnel content with a specific conversion goal at the end of each piece. The review gate includes a second pass for technical accuracy before anything goes live. The pipeline deploys to a staging environment so internal teams can read the article before it reaches the public site.
For a personal brand, the research agent surfaces newsletter topics and thought-leadership angles alongside article briefs. The voice brief is tighter and more idiosyncratic, written in first person with specific reference to the creator’s actual opinions and the phrases they would never use. The writer produces a draft the creator substantially rewrites rather than approves as-is. The review gate is faster because the creator is the reviewer and the audience in one.
Working out which configuration a particular team needs is most of the job, and it is what an AI marketing workshop session is spent on: the team’s own briefs and campaigns rather than a generic curriculum.
Different configurations. The same five stages. The architecture holds when the context changes because the principles stay fixed: brief as control surface, human gate at the boundary, enforced pipeline as the trust mechanism.
That is the distinction between an architecture and a workflow. Workflows get rebuilt for each project. Architectures get extended.
The full system, including the standing brief documents, the agents that run each stage, the file handoffs between them, and the deploy pattern that keeps editorial control where it belongs, is covered in the Blueprint. If you want to build this on your own content operation, that is where to start.