Run a three-agent report pipeline and break it on purpose
A researcher, a writer and a reviewer pass work to each other. You add limits and test the failures.
What you will have at the end
A written orchestration design, a run log of a three-agent pipeline, three failure tests and a short report on cost, steps and fixes. You can explain it in an interview.
What you need
- Any chat AI tool (three chat windows or three saved prompts)
- A document or spreadsheet for the shared state
All names, numbers and data in this lab are made up for practice. Never use real customer or personal data. Your ticks are saved in this browser.
The scenario
A small company wants a one-page briefing on a topic every Monday. You will build a pipeline of three agents: a researcher, a writer and a reviewer.
You will run it by hand. You are the orchestrator. You copy each agent's output to the next one using a fixed handoff form.
The learning comes from adding limits and breaking the pipeline on purpose. Real systems fail in exactly these ways.
Starter material
Copy these into your own files or chat. Change anything you like.
Paste each prompt into its own chat window.
RESEARCHER
You gather facts on the topic I give you. Return only: 5 to 8 facts, each with a source name and a date.
Mark any fact you are not sure about with [UNSURE]. Do not write prose. Do not give opinions.
WRITER
You turn a fact list into a one-page briefing for busy managers. Use only the facts you are given.
If a fact is marked [UNSURE], leave it out or flag it. Keep it under 250 words. End with "Open questions".
REVIEWER
You check a briefing against its fact list. Return JSON only:
{"verdict": "pass" or "fix", "problems": ["..."], "unsupported_claims": ["..."]}
Pass only if every claim in the briefing appears in the fact list.Fill this in each time one agent passes work to the next.
FROM: {{agent}} TO: {{agent}} RUN: {{number}} STEP: {{number}}
GOAL OF THE WHOLE JOB: {{one line}}
WHAT YOU ARE GIVING: {{the output, pasted}}
WHAT THE NEXT AGENT MUST DO: {{one line}}
WHAT THE NEXT AGENT MUST NOT DO: {{one line}}
OPEN QUESTIONS / UNSURE ITEMS: {{list}}
LIMITS: max 2 retries, max 3 steps per agent, stop and ask a person if still failingOne document that always holds the current state.
JOB: {{topic}} STATUS: {{researching / writing / reviewing / done / stuck}}
FACTS (latest version):
DRAFT (latest version):
REVIEW (latest verdict and problems):
STEPS USED: {{n}} of {{max}} RETRIES USED: {{n}} of {{max}}
PROBLEMS SEEN: {{list}}Three ways to break the pipeline.
FAILURE 1 BAD INPUT Give the researcher a topic that is too vague: "AI". FAILURE 2 WRONG FACT Edit one fact in the list so it is false, then let the writer use it. FAILURE 3 NO ENDING Tell the reviewer to always answer "fix". Does the loop stop? For each: what happened, what should have happened, what limit or check would catch it.
The steps
Do them in order. Each step says how you know it is done.
- 1
Write the design in one page
- Draw the three agents as boxes with arrows. Add the shared state and the person who can stop the run.
- For each agent, write its one job, its input and its output.
- Write why three agents instead of one, and where one agent would have been enough.
Done when: A one-page design with a diagram and one honest sentence on whether you really need three agents.
- 2
Define the handoffs
- Use the handoff form between each pair of agents.
- Decide what the next agent must receive and what it must never receive.
- Decide where state lives, and who may change it.
Done when: You can say in one sentence what each agent receives and returns.
- 3
Run the happy path
- Pick a topic you know, such as the latest development in a field you follow.
- Run researcher, then writer, then reviewer. Fill in the shared state after each step.
- Count steps and estimate tokens used by each agent.
Done when: A complete run log with the final briefing and the reviewer's verdict.
- 4
Add limits
- Set a maximum of 3 steps per agent and 2 retries for the whole job.
- Decide what happens at the limit: stop and ask a person, with a summary.
- Add a rule that the reviewer can only send work back twice.
Done when: The limits are written on the shared state form, and a run stops when it hits them.
- 5
Break it on purpose
- Run the three failure tests.
- For each, record what happened. Did the pipeline notice? Did it stop? Did it pass a false claim to the end?
- Write which check or limit would have caught it.
Done when: Three short failure write-ups, each naming one fix.
- 6
Fix and run again
- Add the fixes: a rule to reject vague topics, a check that the reviewer compares claims with sources, a retry limit.
- Re-run the three failure tests.
- Compare cost: steps and tokens before and after.
Done when: At least two of three failure tests are now caught, with the evidence in your log.
- 7
Write the report
- Write one page: the design, the limits, the failures, the fixes and the cost.
- Say what you would monitor in production: steps, retries, cost, verdicts and stuck jobs.
- Say when you would use one agent instead.
Done when: A one-page report that ends with a monitoring list.
Success checklist
How to know the lab is really done
Show it in an interview
- Explain why you chose three agents, and what would make you choose one.
- Walk through a failure you caused, how it showed, and the check that caught it.
- Describe what you would log and alert on in production.
Common mistakes
- Giving every agent the whole history
- No limit on retries
- A reviewer that only agrees
- No place for state, so facts get lost between agents
Want a bigger challenge?
- Add a fourth agent that checks sources, and measure whether it helps.
- Run the same job with one agent and compare quality and cost.
- Write the same design as a durable workflow with checkpoints.
Next step: practice the interview questions for this role →
Other labs
A small agent that looks up orders and opens tickets, with checks, limits and a test set.
Play the forward deployed engineer for a fictional clinic: discover, scope, prototype, test and hand over.
Score ideas, build a business case, list the risks and plan a pilot for Riverside Logistics.