Every agent needs to be told what it does not do

Every agent needs to be told what it does not do#

Guides on multi-agent systems talk about assigning roles. Give one agent the role of analyst, another the role of reviewer, a third the role of adjudicator, and trust that the division of labour will sort itself out.

It does not. An agent with a role but no boundary will do the entire task by itself and return something that looks complete. Three analysts with roles will write three variations on the same opinion, and the adjudicator will add a fourth.

We have three workflows built on this pattern, each a different shape. When we put their prompts side by side, what they had in common turned out not to be the division of roles. It was something else: every prompt contains an explicit sentence about what that particular agent must not do.

Three shapes of the same idea#

:::

The third shape is iteration: one agent invoked repeatedly over the items of a list. That is how the contract review works — the same agent assesses clause after clause, while aggregation and the decision happen outside it, in code.

Worth noticing, because "multi-agent" does not have to mean "several different agents". It can mean one agent with a narrow job, called as many times as there are items.

Boundary, not role#

Put the opening lines of the prompts side by side.

You read ONE ticket and classify it. You do NOT answer it — a later specialist agent does that.

You research a support ticket against the team's own documentation before anyone drafts a reply. You do NOT write the customer-facing answer — that is the next agent's job.

You draft a support reply. Everything factual has already been researched — your job is wording, not investigation.

You are the adjudicator. You did NOT read the company's website and you must not pretend to: your entire input is their three reports.

Each of those sentences takes away something the agent is perfectly capable of doing. Triage could answer the ticket. The researcher could write the reply. The drafter could go looking for facts. The adjudicator could visit the company's website and form its own view.

The adjudicator that never saw the source#

The most interesting case is the parallel workflow. Three reviewers read the company's site through three different lenses and each returns a report in the same structure:

Then the adjudicator runs, and here is the whole trick: its only input is those three reports. It has no access to the company's site.

That is not a token-saving measure. If the adjudicator could go and read the source, it would form its own view and the three lenses would become decoration. Cutting it off from the source means the only thing it can do is compare other people's conclusions — which is what makes disagreement between reviewers detectable at all.

Its output schema confirms this:

{
  "verdict": "...",
  "verdict_reason": "...",
  "dealbreaker_triggered": "...",
  "disagreements": [],
  "collective_blind_spots": [],
  "top_strengths": [],
  "top_risks": [],
  "open_questions": []
}

disagreements and collective_blind_spots are fields you cannot fill if you had one source and one opinion. They exist purely because the input was three independent reports.

The human gate, and where to put it#

All three workflows have a point where output waits for a person. But the point sits in a different place each time, and that is not accidental.

The rule is simple: the gate belongs where reversibility ends. A message sent to a customer is irreversible, so a human stands in front of it. A report in a spreadsheet is reversible, so nobody does.

The contract review shows the middle case. It has an auto-clear branch for clauses that breach no hard limit and fall within the standard positions. The human only sees what actually needs a decision. That is the difference between a gate and a bottleneck: a gate lets the obvious through, a bottleneck stops everything.

Configuration as a parameter, not as prompt copy#

In each of the three workflows, whatever makes it useful for a specific company lives in a Set node rather than in the body of a prompt.

productContext        what the product is and who it is for
severityDefinitions   priority definitions, verbatim

ourSide     whose side you are on
playbook    standard negotiating positions
hardLimits  clauses we do not let through

reviewPurpose   why we are looking at this company at all

The triage prompt says it outright:

SEVERITY DEFINITIONS (use these exactly, not your own intuition)

That sentence is there because without it the model applies its own sense of what "critical" means. Your priority definitions are almost certainly not the same as its. Pointing at a parameter and adding "use this, not your intuition" is cheaper and more reliable than describing your priorities in prose inside the prompt.

Code does the deterministic work#

One statistic surprised us when comparing the three files:

There are more code nodes than agents in every one, and ten times as many in the contract review. The agents do what requires understanding text. Everything else — normalising input, merging reports, counting, branching, building records, logging — is code.

That is the right split. A model called to add up a total or check a threshold is more expensive, slower and less reliable than three lines of JavaScript. And every such call is one more place where the behaviour can differ from last time.

A field for not knowing#

All three output schemas contain somewhere for the agent to admit it does not know something.

• the reviewers have could_not_verify
• the adjudicator has open_questions
• the documentation research agent has docs_gap
• the drafting agent has confidence_in_draft and confidence_reason

This is not decoration. A model with nowhere to put a gap will fill it inside a decision field — the schema demands a value there and it has no mechanism to decline. A separate, required field for uncertainty gives it somewhere to be honest instead of guessing where guessing is expensive.

docs_gap in the support workflow has a second use. Collected over a few weeks it produces a list of questions your documentation does not answer — a backlog for whoever writes it. The agent measures the quality of your own material as a side effect of answering customers.

When is it a variant and when a duplicate#

We submitted all three to the n8n template library. Two were accepted. The third came back with this:

After reviewing it, we've noticed that it's very similar to some of your other templates, with only small changes (mainly a few nodes swapped out). To keep the directory high-quality and diverse, we try to avoid publishing multiple near-duplicates.

That is worth knowing, because it is not in the official documentation: the library rejects not only for technical faults but for close resemblance to your own, previously accepted submissions. Publishing a series of workflows from one pattern means competing with yourself for shelf space.

The reviewer suggested a fix, and it is a good one outside the library context too: rather than a separate entry, build the variation into the existing template — configuration steps, or optional "floating" nodes users can plug in depending on their use case.

Limitations#

No measurement that three lenses beat one. We did not run a comparison against a single agent on the same material. The pattern is sound in theory and looks good in practice, but we have no numbers.

Cost scales linearly with agent count. Three reviewers means three full passes over the material plus a fourth for adjudication. At volume that is a real line item.

The human gate is only as good as the human behind it. If the approver clicks through without reading, the whole pattern reduces to a slower single agent. Worth measuring how many approvals come back with an edit — if the answer is none, the gate is theatre.

No handling for fundamental disagreement. The adjudicator will report a divergence, but the workflow has no escalation path to a second round with additional context.

The prompts are long, and that is debt. Each runs to several hundred words of instruction. Changing a priority definition in one place means checking it does not contradict something in another.

What it comes down to#

A multi-agent workflow does not work because it has several agents. It works because each one has a narrowly defined input, an enforced output shape, explicitly removed capabilities it is not to use, and somewhere to admit what it does not know.

Take any one of those four away and you get several agents doing the same thing slightly differently — which is a slower and more expensive way to arrive at one opinion.