![Cover image for [Agent Design #3] Designing an AI Content Pipeline, from Generation to Publication](/assets/images/posts/1dba3ed2-79c4-4348-b5e7-3014c4d498aa/ai-content-pipeline-1.jpg)
When people talk about creating content with AI, they usually imagine a “single-shot prompt.” But one-shot results vary wildly in quality, so people end up fixing everything by hand.
What if we changed the approach and divided generation into stages like a factory line? Draft generation, quality review, image generation, and publication become independent processes, with validation inserted between them.
I summarize the design principles learned from operating a pipeline that automates blog production with this structure. The example is domain-specific, but the structure itself can be adapted to any AI automation.
This article covers the pipeline stages, the validation mechanisms between them, and failure-handling design.
Here’s the key summary first.
- The backbone of the generation pipeline is separating generation → review → asset creation → publication
- Fixing the output schema at each stage enables intermediate validation and retries
- Quality review is also an automation target. Insert a review stage with a different perspective from the generating model
- Failure is a given. The key is designing the system so the original is preserved no matter which stage fails
Stage Separation: The Decisive Difference from One-Shot Generation
This is the pipeline’s basic structure.
Keyword input → body generation → style review (editing) → image generation → storage → publication. Each stage is independent and accepts only the previous stage’s output as input.
There are three advantages over one-shot generation.
- Stage-specific retries: If image generation fails, the body remains intact. Rerun only the failed process
- Stage-specific replacement: You can replace the style-review logic without touching the generation stage
- Stage-specific measurement: You can track with metrics where quality breaks down
The cohesion and coupling principles covered in the modularization series apply directly. Group logic that changes together, and communicate between processes through schemas.
Fix the Output Schema
Stage separation requires one condition: each stage’s output must be in a verifiable form.
In this pipeline, the body-generation output has a fixed schema: “title candidate array + body + image prompt array + tag array.” Image positions in the body are marked using a convention such as [image marker].
With a fixed schema, the pipeline can validate LLM output instead of trusting it.
| Validation item | Handling on failure |
|---|---|
| Whether required fields exist | Retry generation |
| Number of image markers = number of prompts | Retry generation |
| Whether markers were damaged after review | Discard the review result and retain the original |
The moment an LLM enters the pipeline, its output is not something to “trust” but something to “validate.” The schema is the baseline for that validation.
Review Is a Separate Process
The style-review stage is especially interesting. AI-written text retains recognizable traits—uniform rhythm, translation-like phrasing, and mechanical parallel structures—so I separated the editing that removes them into a separate LLM process.
There’s a reason separation works better than simply adding “write naturally” to the generation prompt.
The generation stage focuses only on content accuracy, while the review stage focuses only on style. Packing both goals into one prompt makes both mediocre; splitting the processes lets each optimize for a single goal.
It is essentially the prompt version of the Single Responsibility Principle.
One rule applies here: the review process must never change content, numbers, or citations; it may only refine the style.
After review, we mechanically compare the image markers and key figures to confirm they were preserved. If damage is detected, we discard the review result and use the original.
Design for Failure
Every external call in the pipeline—from LLM calls and image-generation APIs to rendering tools—can fail. That makes failure handling part of the backbone, not an add-on.
There are three principles.
First, preserve the original. No process overwrites the previous stage’s output. If review fails, the original must remain unchanged.
Second, allow partial success. If one of four images fails, save the three that succeeded and record only the failure. Rolling back everything is an overreaction.
Third, make failures visible. Do not swallow errors; record them in a status field so a person can rerun only the failed process from the dashboard.
Wrap-up
In short, AI automation quality comes from process design, not the model: split the stages, validate with schemas, and design for failure.
The principles of traditional pipeline engineering remain just as valid in the LLM era.
Read this alongside the harness engineering and context engineering installments, and you’ll see the full map of “how to use models effectively.”
Continue reading
Agent Design Series
- Previous installment: [Agent Design #2] Context engineering: How to use the context window like a budget
- Previous installment: [Agent Design #1] What is harness engineering? What comes after prompts