An AI writing pipeline works better for me when I separate the person designing the work from the one writing it. Using one strong model for research, structure, prose, rewrites, and SEO made each draft feel costly and left me stuck in the same rewrite loop. This is Layer 4 of my Cursor workflow.
The change was not finding a perfect writing model. It was defining which parts of the job need careful judgment and which parts need clear execution. I now treat the brief and the gate as the system I want to improve.
The problem: one model doing every job
One model doing every job mixes decisions that should be separate. It has to decide what is true, choose the angle, shape the structure, write sentences, and judge those sentences afterward. When the output is weak, the obvious reaction is to ask the same chat to rewrite it again.
That loop is expensive because the stronger model spends time producing and revising every paragraph. More importantly, it does not leave behind a better process. The next draft can fail in the same way because the instructions stayed vague.
I also found that an editing request inside a writing chat often changes the prose without exposing the cause. A heading may be unclear because the audience was not defined. A claim may be too broad because the fact sheet did not set a boundary.
The result is a draft that looks improved but has no reusable lesson. I wanted failures to update the instructions, not only the current document. That requires separating the role that diagnoses a problem from the role that turns a plan into prose.
The AI writing pipeline split: editor vs writer
The split is simple: the stronger model owns the system, while the writer owns the prose. I call the first role the editor or harness, and the second role the writer. The editor can be a Fable-class or other stronger main agent.
The editor handles the decisions that should carry from one post to another:
- Write and sharpen the brief.
- Collect the fact sheet and set the structure.
- Check the draft against the brief and style guide.
- Give revision instructions and prepare publishing work.
The writer receives a constrained assignment and writes only the Markdown prose. In my setup, that writer can be gpt-5.6-terra-medium or cursor-grok-4.5-high-fast. It does not need to decide the publishing strategy while it is writing sentences.
This division gives each role a clear failure mode. If the writer misses a hard constraint, the gate catches it. If many drafts miss the same constraint, the editor changes the brief or the shared rules.
The goal is not to make the writer sound cheap or mechanical. The goal is for a lower-cost writer draft to pass the editor gate without the editor rewriting its prose. That moves the stronger model’s attention from every paragraph to the instructions that shape future paragraphs.
The brief is the product
The brief is the reusable product of this process, not a note I discard after one draft. I save it beside the draft as drafts/manual/<slug>.brief.md. That file lets me inspect what I asked for when a draft succeeds or fails.
For this kind of post, a useful brief includes:
- The audience and search intent.
- The exact title and planned structure.
- A fact sheet with allowed claims and forbidden claims.
- Hard formatting, linking, image, and keyword constraints.
- A pointer to
config/style-guide.md.
This makes the writer’s task narrower in a useful way. The writer is not asked to guess whether I want a personal essay, a comparison, or a publishing checklist. It has a defined angle, evidence boundary, and output format.
I keep the style guide separate because it is shared process knowledge. It contains rules such as short paragraphs, lists for three or more items, a keyword in the title and slug, and at least one outbound link. It also records what I deliberately ignore, including power-word prompts, a table of contents, and keyword-density pressure.
The brief and style guide answer different questions. The brief says what this post needs to say. The style guide says how every post should read and what publishing mechanics matter.
Gate failures sharpen the harness
A gate failure should improve the harness rather than trigger a quiet editor rewrite. The editor checks the draft against the brief and config/style-guide.md. It looks for missing constraints, unsupported claims, structure problems, and repeated readability issues.
When the gate finds a problem, I do not ask the editor to patch the body itself. I update the brief if the assignment was unclear. I update the style guide if the problem is recurring across posts.
Then I delegate the prose again from the improved instructions. This keeps the learning visible and reusable. It also prevents a strong model from becoming a hidden last-mile writer for every article.
This approach is more demanding at the beginning because the brief must be specific. A vague brief produces a vague draft, even from a capable writer. But a precise brief turns each correction into a change I can apply again.
I do not need every gate to be complicated. A short check can still be useful when it asks whether the draft has the required links, placeholders, structure, and fact boundaries. The important part is that the check is connected to written instructions.
What this looks like on this blog
On this blog, the manual cluster uses a small sequence that keeps authorship and publishing decisions clear. I delegate drafting through Cursor agents, while keeping the editor role responsible for the system around that delegation.
- The editor writes or sharpens the brief.
- The writer creates Markdown prose from that brief.
- The editor gates the result against the brief and style guide.
- If it fails, the editor fixes the brief or style guide and delegates again.
- Images are added and the post goes to WordPress as a draft; a human publishes it in WordPress Admin.
This is an AI writing pipeline in the practical sense: a repeatable handoff with distinct responsibilities. The pipeline does not promise that the first draft is always ready. It makes the reason for a failed draft easier to find and address.
The same general shape also supports evergreen synthesis work: collect, create facts, synthesize, gate, then create a WordPress draft. I keep that mention light here because this post is about the editor-and-writer split. For synthesis comparisons, I do not use a first-person voice that implies experience I did not have.
My own setup also benefits from keeping debugging separate from drafting. When an agent workflow behaves unexpectedly, I use AI debugging logs to inspect what happened rather than guessing from the final output. That record makes a workflow problem easier to distinguish from a weak brief.
For longer work, a session handoff can preserve the current brief, draft state, and next decision. It is another way to keep context in a visible artifact instead of relying on one long chat. The same principle applies: useful process knowledge should survive the current conversation.
Wrap-up
The model split gives me a clearer place to spend stronger-model attention: briefs and gates. The writer can concentrate on turning a bounded plan into readable prose. This AI writing pipeline is a better use of the editor role than repeatedly revising sentences after the fact.
Layer 3, AI debugging logs, helps me inspect agent behavior when the workflow needs evidence. Layer 4 separates the editor from the writer so the process itself can improve. Together, they extend the workflow described in my Cursor workflow.
For Layer 4, put smart models on briefs and gates, then let a cheaper writer type from a clear plan. The next deep dive is PortalHub / Layer 5: one hub over many project offices.