Planner–worker–reviewer pattern

In this pattern three roles share a task. The planner reads the goal and the context and produces an ordered list of steps with the inputs each needs. Workers take one step each, using only the tools that step requires: a look-up worker with read access, an action worker with a write tool behind a policy gate. The reviewer receives the workers' outputs and judges them against the original goal, the business rules and the quality bar; it can approve, send a step back with a reason, or escalate to a person.

The value is separation. The planner never touches systems, so a bad plan costs nothing until a worker acts. Workers have small prompts and narrow permissions, so each is easy to evaluate on its own. The reviewer is a different model call with a different prompt, and often a different model, so it is not simply agreeing with itself.

It is not required for every agent. A single-step task with one tool does not need a planner or a reviewer; adding them only adds cost and latency. It is also not a substitute for human review on high-stakes actions; the reviewer reduces errors reaching a person, it does not remove the person from decisions that need one.

• CTO / Head of Engineering: it is a proven structure that keeps each agent small enough to test and small enough to trust with limited permissions.
• Compliance officer: a reviewer step produces a recorded second opinion on every action, which is useful evidence of control.
• Product manager: the reviewer's rejections are the best source of edge cases and product rules you had not written down.
• CFO: three roles mean more model calls; routing the planner and reviewer to cheaper models keeps cost proportionate.

One agent that plans, acts and judges its own work has nobody to catch its mistakes. The pattern exists to put distance between deciding, doing and checking, so an error in one role is caught by another before it reaches a customer or a system of record. It mirrors how careful teams already work. The trade-off is latency and cost from extra calls, and some engineering to pass context between roles cleanly. For low-risk, single-step tasks it is overkill; for multi-step tasks that touch money, customer data or records, it is usually the cheapest way to make the system reliable.

• A refund-handling system where the planner determines what to check, workers fetch order and policy data, and the reviewer confirms the refund is within rules before it is issued.
• A loan-file preparation pipeline where workers extract and verify documents and the reviewer checks completeness before an underwriter sees it.
• A discharge-summary assistant where a worker drafts from clinical notes and a reviewer checks against protocol before a clinician signs off.
• A delivery-exception system where a planner decides whether to rebook, re-route or refund and a reviewer validates against dispatch rules.
• A marketing content pipeline where workers draft variants and a reviewer enforces brand and regulatory wording.

Technique / practiceA design technique Eazyware uses as the default structure in multi-agent systems work, with each role evaluated separately and the reviewer's rejection reasons fed back into the golden dataset.

Eazyware service that covers it: Multi-Agent Systems & Workflow Orchestration. Starting prices are on the pricing page.