Evaluator, optimiser, and how many agents
By the end: Apply the evaluator–optimiser loop, and apply an honest test before adding a second agent.
The last pattern is a loop between two roles: one produces, the other critiques against explicit criteria, and the producer revises. It works well where quality is genuinely improved by iteration and where you can say what good looks like — translation with a style guide, writing against a brief, code against tests.
Two conditions make it worth the cost. A person doing this task would improve it on a second pass, and the criteria can be stated well enough that the critique is about the work rather than about taste. Without both, you get expensive churn: two calls per round producing changes that are different rather than better.
Which brings us to multi-agent systems generally. There is real enthusiasm for teams of agents, and there are problems where a genuinely independent sub-task with its own clean context is the right answer. But every additional agent adds coordination, context handoff, more places to fail, and cost that multiplies rather than adds.
The honest test: could one agent with these tools do this? If yes, use one. Reach for a second when a sub-task needs a genuinely different context, a different set of tools or a different trust level — not because the diagram looks better with more boxes on it.