The Multi-Agent Workflow Mini-Guide

A multi-agent pipeline is a sequence of AI agents, each assigned one job, where the output of one becomes the input of the next. The researcher gathers and organises information. The writer turns that information into a draft. The reviewer checks the draft against a set of rules and flags what needs fixing. You sit at the start and the end, not in the middle. This matters because general-purpose prompting asks one model to do everything at once: research, write, check, format. That is like asking one person to be your researcher, copywriter and editor simultaneously. The work degrades. Splitting the roles out, even within a single tool, produces noticeably better output because each agent can be given a narrow, clear instruction set and judged against it. You do not need expensive enterprise software to run this. You can build a working three-agent pipeline using tools you already have access to, including Claude, ChatGPT with custom instructions, or any platform that lets you save and chain prompts. The architecture is what matters, not the brand.

The researcher agent has one job: gather relevant, factual, organised information on a topic and return it in a structured format the writer can use. It does not write. It does not editorialize. It does not decide what angle the piece should take. Its output is a structured brief. Set up your researcher prompt to specify the exact output format you want. A good researcher output includes: the core topic and why it matters to your target reader, three to five factual points with any supporting data, common questions or objections your reader has about this topic, and any terms or phrases your reader uses. That structure gives the writer everything it needs without flooding it with noise. One practical constraint to build in: tell the researcher to flag any claim it is uncertain about rather than state it as fact. This single instruction eliminates the most damaging failure mode in AI pipelines, which is confident hallucination passing through unchallenged into a published draft. Uncertainty flags are your quality gate before the writer even starts.

The writer agent receives the researcher output and turns it into a first draft. Its system prompt should contain three things: the output format (word count, structure, heading style), the voice rules (tone, banned words, sentence length preference, point of view), and a clear instruction to use only what the researcher provided and not to invent additional claims. Voice rules are the most important part of the writer prompt and the part most people skip. If you want content that sounds like you, not like a generic AI, you need to give the writer explicit instructions: write in short declarative sentences, use contractions, avoid jargon, never open with a question, always speak directly to the reader as a practitioner not a beginner. The more specific these rules are, the less editing you will do on the other side. The instruction to use only what the researcher provided is not a creativity constraint. It is a quality control mechanism. When the writer invents beyond the brief, you get confident, plausible-sounding content that may be factually wrong. Keeping the writer inside the brief keeps the output accurate. You can always extend later. You cannot easily retract a mistake that has already been published.

The reviewer agent reads the writer's draft and checks it against a checklist. Its job is not to rewrite. Its job is to return a structured list of issues with the line number or section and a specific fix recommendation. The distinction matters because a reviewer that rewrites becomes a second writer, which destroys the pipeline structure and makes outputs unpredictable. Build your reviewer checklist around your most common failure modes. For most service businesses, that list includes: does the opening sentence earn the read or start with a platitude, are there any unsupported claims the researcher did not include, does the piece end with a specific action or does it trail off, are there any words on the banned list, and is the piece the right length. Five to eight checks is enough. More than that and the reviewer starts generating noise. The reviewer should also return a pass or revise verdict at the top. If the draft passes, it goes to you for a final read. If it needs revision, the specific flags go back to the writer agent for a second pass. You set the threshold: one or two minor flags can be a pass, structural problems are always a revise. Having a clear verdict stops the pipeline from producing an endless stream of small improvements and keeps turnaround time fast.

The simplest way to wire agents together without writing code is to use a single document as the baton. The researcher writes its output into a structured section of that document. You copy that section and paste it into the writer prompt. The writer adds its draft below. You copy the draft and paste it into the reviewer prompt. The reviewer adds its verdict and flags. That is a working pipeline. It is manual in one sense, but the cognitive load on you is near zero because you are moving text, not making decisions. If you want to reduce even that manual step, tools like Make (formerly Integromat), Zapier, or a simple Python script can pass output between prompts automatically. You trigger the researcher with a topic, it writes its output to a Google Doc or Notion page, a trigger fires the writer with that output as context, and the reviewer runs when the writer finishes. None of this requires a developer if you use a visual automation tool and pre-written prompt templates. The critical wiring decision is what format you use to pass data between agents. Plain text with clear section labels works reliably. JSON works if your agents are running inside a system that can parse it. Avoid passing raw, unstructured prose between agents because the receiving agent will spend processing capacity trying to figure out what is brief and what is content. Structure the handoff and the pipeline becomes predictable.

Here is how the pipeline runs in practice. You give the researcher one sentence: research what service business owners most commonly ask about AI automation and return a structured brief in the format below. The researcher returns five factual points, three common questions, two relevant examples, and one uncertainty flag about a statistic it found but could not verify. You remove the uncertain statistic and pass the rest to the writer. The writer receives the brief, applies your voice rules, and returns a 600-word draft with an opening that goes straight to the reader's problem, three short sections each covering one factual point, and a closing paragraph that names one specific action. The draft takes two minutes to generate. You paste it into the reviewer prompt. The reviewer checks against the checklist and returns: verdict REVISE, one flag. The opening sentence starts with the word 'Many' which is on your vague language list. It recommends replacing it with a specific statement. You pass that one flag back to the writer, which returns a corrected draft in under a minute. The reviewer reads the corrected draft and returns PASS. Total time from your initial input to a reviewable draft: under ten minutes. Your editing time drops to five minutes because the structural and voice work is already done.

The most common reason pipelines produce bad output is vague prompts at the researcher stage. If you give the researcher a broad topic without specifying your reader, their knowledge level, the format of the output, or the scope of the brief, it returns a general summary that gives the writer nothing specific to work with. The writer then fills gaps with generic content, the reviewer flags it, and you end up editing more than if you had written the piece yourself. The fix is to front-load specificity in the researcher prompt every time, even when the topic feels obvious to you. The second common mistake is using the reviewer as a rewriter. When the reviewer is prompted to 'improve the draft' rather than 'check the draft against this list and flag issues', it starts making stylistic choices that drift away from your voice rules. Over multiple pieces, your content becomes inconsistent. The fix is to keep the reviewer's job description narrow: check, flag, return verdict. Rewriting is the writer's job on the revision pass. The third mistake is skipping the human final read. The pipeline reduces your involvement, but it does not eliminate it. A final read before anything goes out is your quality gate. It takes three minutes. It catches the rare cases where the pipeline has produced something technically correct but tonally off. The goal is to reduce your time investment from forty-five minutes to eight minutes, not to remove your judgement entirely. That distinction is what separates a reliable pipeline from one that occasionally embarrasses you.