How to Build an AI Pipeline: Draft, Critique, Revise

A Pipeline runs several AI models in sequence, where each stage works on the output of the stage before it. Instead of asking one model to write, check, and fix everything in a single reply, you split the work into stages: Draft, Critique, Revise, and optionally Polish. Each stage has one job, so the result improves step by step instead of all at once.

This guide shows what a Pipeline is, when it beats a single prompt, how to set one up stage by stage, and how it differs from Team and Judge.

What is an AI Pipeline?

A Pipeline is a sequential workflow. You assign a model to each stage, and the output of one stage becomes the input to the next. A typical chain is Draft to Critique to Revise, with an optional Polish stage at the end.

Think of it like an editorial desk. One model writes the first version. A second model reads that version and lists what is weak, missing, or wrong. A third model takes both the draft and the critique and produces an improved version. A final stage can clean up tone and formatting. Each handoff carries the work forward, so quality compounds.

This is different from sending the same prompt to several models at once. In a Pipeline, the models do not compete or run in parallel. They cooperate in order, each picking up where the last left off.

When does a Pipeline beat a single prompt?

Use a Pipeline when the task naturally has more than one step and the first attempt is rarely the final answer. A single prompt asks one model to do everything in one pass, which mixes drafting and self-correction into the same reply. That works for short, simple asks. It struggles when the work needs real revision.

A Pipeline wins in three common cases:

• Writing. Draft an article or email, critique it for clarity and gaps, then revise. The critique stage catches the vague claims and missing context the draft stage glossed over.
• Code. Draft a function, critique it for edge cases and security, then revise to harden it. Separating "write it" from "break it" surfaces bugs a single pass tends to skip.
• Analysis. Draft a summary or recommendation, critique the reasoning and assumptions, then revise into a tighter conclusion.

The common thread is that the critique step is doing work the draft model would not do well on itself. Asking a model to find faults in its own fresh output in the same breath is weaker than giving a separate stage one job: tear it apart.

How to build a Pipeline step by step

In aiDex you open aiDex and launch a Pipeline. The order you pick the models in maps to the stages. Here is how to set up each role.

1. Choose a model for Draft. This stage produces the first version. Pick a strong generator with good range. For writing, a capable frontier model gives you a rich first pass to work from. For code, pick a model with strong coding ability. The draft does not need to be perfect, it needs to be complete enough to critique.

2. Choose a model for Critique. This stage reads the draft and lists problems. It does not rewrite anything. A good critique model is sharp at reasoning and willing to be blunt. Using a different model here is the whole point: a second set of weights notices things the first model accepted. If you are unsure which model reasons best for your task, our guide on Which AI Model for Which Task? helps you match models to roles.

3. Choose a model for Revise. This stage takes the draft and the critique and produces an improved version. Pick a model that follows instructions closely and writes cleanly, since its job is to apply the fixes faithfully rather than invent a new direction.

4. Optionally add a Polish stage. Use a final model to tidy tone, formatting, and consistency without changing substance. A fast, inexpensive model is often enough here.

Then type your prompt, send it, and watch the output get refined down the chain. You can use OpenAI, Anthropic (Claude), Google (Gemini), DeepSeek, or a local model through Ollama at any stage. Use your own provider keys or the ones we manage, and pick the models you want.

Why use different models per stage?

Mixing models is a feature, not a complication. Each model has its own strengths and its own blind spots. A model that drafts beautifully may be too agreeable to critique its own style. A model that reasons hard about edge cases may write stiff prose. By assigning different models to Draft, Critique, and Revise, you get the strength of each where it matters and avoid one model's weakness dominating the whole result.

Using one model for every stage still works, and it is a fine place to start. But the critique stage gets noticeably more useful when a fresh model reads the draft, because it has no attachment to the choices the draft model made.

Worked example: harden a piece of code

Say you want a reliable input-validation function.

• Draft: "Write a function that validates and normalizes a user email address." The draft model returns a working first version.
• Critique: the next model reads that function and lists issues: it misses internationalized domains, it does not trim whitespace, it has no length cap, it lacks tests.
• Revise: the third model takes the function plus that list and returns a hardened version that addresses each point.
• Polish (optional): a final model adds doc comments and consistent naming.

You end with code that has already survived a review pass, without you writing the review yourself. The same pattern works for prose: draft the essay, critique it for weak arguments, revise it into something tighter.

Tips for strong stage roles

• Give each stage one job. Do not ask the critique stage to also rewrite. Keeping roles clean is what makes the chain work.
• Make the critique stage harsh. A polite critique produces a lazy revision. You want the weak spots named plainly.
• Match the model to the role, not just the task. The best drafter is not always the best critic.
• Keep Polish light. If your Polish stage is rewriting substance, the Revise stage did not finish its job.

Pipeline vs Team vs Judge: which should you use?

These three modes all use more than one model, but they differ in how the models relate to each other.

• Pipeline is sequential refinement. Models run in order and each one improves the last one's output. Use it when the work needs steps: draft, then critique, then revise.
• Team is a roundtable. Named personas discuss together with a moderator watching for consensus. Use it when you want models reacting to each other in conversation rather than handing work down a line. See How to Create a Multi-AI Team.
• Judge fans one prompt out to a panel and then synthesizes the answers into one best result. Use it when you want several independent attempts merged, not refined in stages.

If your goal is a polished final artifact built through revision, reach for Pipeline. If your goal is debate or one synthesized answer, reach for Team or Judge. For a fuller map of when to combine models, see Multi-Model AI Workflows.