Synergised Consulting
Method

One Agent Writes, Another Tries to Prove It Wrong: The Multi-Agent Pattern Explained

Synergised Consulting Ltd

6 min read
Title card reading one agent writes, another tries to prove it wrong, on the multi-agent sceptic pattern

Last Updated: 25 September 2026

Multi-agent AI means several AI assistants working the same job with separate roles: one orchestrates, others do the legwork, and at least one exists purely to try to prove the others wrong. Anthropic's own engineering data found a multi-agent system outperformed a single agent by 90.2% on its internal research evaluation [1], and small businesses are now running versions of this pattern on ordinary work. The part worth copying is not the scale. It is the sceptic step, and it costs one extra agent.

What Multi-Agent AI Actually Is

A multi-agent system is a way of dividing AI work between several assistants, each running in its own context window with its own instructions and tools, coordinated by a lead agent that hands out tasks and collects results. According to Anthropic's engineering write-up of its own research system [1], the lead agent spins up three to five subagents in parallel rather than running them one after another, which cut research time by up to 90% for complex queries. Each subagent works in its own context and returns only a summary, which is what stops a long job from drowning one very long conversation.

In practice, a subagent is exactly what it sounds like: a specialised assistant with its own prompt, its own tools and its own window of working memory. Anthropic's Claude Code documentation describes them as assistants that handle a defined type of task and return only the summary to the main conversation [3]. The pattern has been available to any business for well over a year: custom subagents shipped in Claude Code version 1.0.60 on 24 July 2025 [4]. This is not a fresh experiment at the frontier. It is a production pattern with a track record.

A worked example makes the shape concrete. Say a new owner wants their website's service pages audited for claims that would not survive a diligent customer. One agent, given the whole job, reads its own work and agrees with itself. Split the job instead: one agent audits the pages and lists findings, a second agent is instructed only to disprove those findings, and a third sweeps for what both missed. The findings that survive the second agent are the ones worth acting on.

The Sceptic Step Is the Cheap Part

The step that does the most work in these systems costs the least to copy: a separate agent whose only instruction is to attack the first agent's conclusions. Anthropic's researchers credit much of their system's accuracy to this division of labour, with subagents pursuing independent lines of enquiry and the lead agent judging the results [1]. The reason it works is uncomfortable but simple: an agent asked to check its own output has every incentive to agree with itself. A second agent, pointed at the same material with a different job, has no such loyalty.

The distinction matters for anyone commissioning this work. There is a difference between a verification step and a summary step. Ask one agent to "review and summarise" and you will get a tidy document that repeats the first agent's claims in new words. Ask a second agent to "prove these findings wrong" and you get a different thing entirely: a list of claims that collapsed and a shorter list that held. In discovery workshops, the list of what to automate gets built in conversation, and the appetite owners bring is for capability: more produced, faster. Verification is the ask nobody makes unprompted, which is exactly why it has to be designed in from the start rather than bolted on after the first bad audit.

How to Commission a Sceptic Run

The commissioning question is one sentence: which of these findings would a sceptical customer disprove first? An AI audit of your own site or operations is only as good as the pressure applied to it, and pressure is a prompt, not a headcount. You do not need a research budget to run one agent against another. You need the discipline to give the second agent a job description that is the opposite of the first.

What It Costs, and Where It Breaks

Multi-agent work spends tokens the way a team spends hours: quickly, and in parallel. In Anthropic's own usage data, a single agent typically uses about four times the tokens of a chat interaction, and a multi-agent system uses about fifteen times [1]. Anthropic is blunt about the consequence: the economics only work where the task's value justifies the token spend, and the company notes its pricing reflects per-token costs, with its Opus 4.5 model priced at $5 per million input tokens and $25 per million output tokens [2]. Caching changes that arithmetic for repeated runs, with writes priced one-to-one and reads at a tenth [2], but the direction of travel is unchanged: verification has a bill attached.

The other failure mode is interruption. Long parallel runs hit usage limits mid-flight, and a system has to be designed to resume: finished subagents reused from cache, the run restarted where it stopped. Any business running these workflows should plan for limits from the first day rather than discovering them mid-project. A run that cannot resume is a run that cannot be budgeted, because the interruption is not an edge case; it is a normal Tuesday. The operational answer is unglamorous: split large jobs into smaller stages, keep each stage's output, and treat a limit hit as a pause rather than a failure.

Reading the Bill

Token counts look abstract until you convert them. Fifteen times the token usage of a chat session is not fifteen times the cost of a chat session, because cached reads price at a tenth [2] and the models doing the legwork can be cheaper than the one orchestrating. But the order of magnitude is the point: multi-agent work is a project expense, not a subscription footnote, and it belongs in the budget next to the task it replaces, not in a general "AI" line where nobody can tell what it bought.

Where the Human Stays in the Loop

The roles that cannot be delegated are judgement roles: approving the direction, deciding what may honestly be claimed, choosing which option matches the business the owner actually runs. Anthropic's own account of its research system notes that evaluation remained a human-led activity even as the agents automated the searching [1]. That is the right reading of the whole pattern. Agents are good at producing options and checking each other's facts. They are not the right judge of what a business can honestly claim, because that question depends on context no agent holds.

This is where the pattern earns trust rather than merely spending it. The verification log itself becomes the artefact: which claims were made, which the sceptic refuted, which survived, and what the human approved. For a buyer or a customer, that log answers a question no polished output can: not "is this well written?" but "was anyone, human or machine, actually checking?"

Sources

  1. [1] Anthropic Engineering, "How we built our multi-agent research system":
  2. [2] Anthropic, "Claude Opus 4.5" model page:
  3. [3] Claude Code documentation, "Create custom subagents":
  4. [4] Claude Code CHANGELOG, anthropics/claude-code on GitHub: