Eduard

Posted on Sep 22

The Iterative Creation Loop: How to Build Better with Plan Mode, Multi-Agent Dialogues, and Verification

#ai #agents #webdev #productivity

A practical 2026 field guide for coding, research, content, products, knowledge systems, and AI-native workflows

There is a point where adding more intelligence to an AI workflow stops helping.

Not because the model is weak.

Because the workflow is weak.

You can give one agent a huge context window, a dozen tools, a long instruction, and a carefully engineered prompt. It can still misunderstand the target, over-trust an assumption, duplicate research, change something that was supposed to stay untouched, or declare success before anyone has actually checked the result.

The instinctive answer is often:

Add another agent.

Then another.

Then a reviewer.

Then a “senior architect.”

Then a final editor.

Eventually you have built a tiny artificial company that spends more time coordinating than doing the work.

That is not the goal.

The more useful idea is simpler:

Do not optimize for the number of agents. Optimize for the quality of state transitions between intention, evidence, action, and verified completion.

This guide calls that system the Iterative Creation Loop.

OBSERVE → CONTRACT → PLAN → CHALLENGE → SPECIALIZE
        → REFINE → APPROVE → EXECUTE → VERIFY → LEARN ↺

The agents are optional.

The loop is not.

For some tasks, one strong agent should run most of the loop. For others, independent researchers, critics, specialists, and verifiers deserve their own contexts. The architecture should follow the shape of the work.

The result is not a “swarm.” It is something more useful: a repeatable process for turning uncertain work into checked work.

TL;DR

The useful shift is from answer generation to artifact progression.

Instead of:

Human → Prompt → Model → Answer

use:

Goal Contract
     ↓
Observe real evidence
     ↓
Create a falsifiable plan
     ↓
Attack the plan
     ↓
Delegate only real uncertainties
     ↓
Execute in checkpoints
     ↓
Verify independently
     ↓
Record what was learned

A few current findings explain why this is worth taking seriously without turning the article into hype.

Current evidence	What it actually supports
Anthropic reported a 90.2% improvement over its single-agent baseline on one internal research evaluation	Multi-agent research can produce large gains on the right task class. It is not a universal benchmark for all agent workloads.
Anthropic reported roughly 15× the token usage of normal chat for its multi-agent Research system	Coordination buys capacity, but the cost is real. The task has to justify it.
The 2026 PACT paper reported substantially lower communication cost when agent outputs are projected into compact action-state records	Communication design is part of agent architecture; forwarding full transcripts is not the only option.
MAST research identified 14 failure modes in multi-agent systems, spanning system design, inter-agent misalignment, and task verification	Adding agents introduces new failure surfaces instead of removing all failure.
A September 2026 study argues that multi-agent gains are strongest on long-horizon, sparse-dependency work and can diminish on tightly coupled sequential tasks	Task topology matters more than agent count.

Primary sources: Anthropic, PACT, MAST, Rethinking Multi-Agent Collaboration.

Practical rule: start with one agent, find the bottleneck, add the smallest amount of coordination that removes it, and measure whether the extra complexity pays for itself.

The core idea: build a loop, not a council
When multi-agent actually helps — and when it makes things worse
Plan Mode: the boundary between thinking and changing the world
The artifact-first architecture
Roles and topologies: choose structure from the task
The dialogue protocol: Action, State, Result
The complete Iterative Creation Loop
How to run the loop today: Cursor, Claude Code, SDKs, and custom harnesses
What the 2025–2026 evidence actually tells us
Four practical playbooks: software, research, content, and products
Verification and measurement: make “done” observable
Failure modes: how good-looking agent systems break
SEO, GEO, and AI-readable publishing without the folklore
The reusable operating kit

1. The core idea: build a loop, not a council

The phrase “multi-agent system” makes the agents sound like the main object.

They are not.

The main object is the workflow state.

A specialist agent is simply a temporary context boundary. A critic is a role with an adversarial objective. A verifier is a gate that requires evidence. A manager is a routing mechanism.

What survives from one stage to the next should be the state of the work.

INTENTION
   ↓
OBSERVED STATE
   ↓
HYPOTHESIS / PLAN
   ↓
CHALLENGE
   ↓
ACTION
   ↓
NEW OBSERVATION
   ↓
VERIFICATION
   ↓
LEARNING

That pattern is not new. Software engineering has tests and code review. Science has hypotheses and experiments. Operations has incident response and postmortems. Product teams prototype, observe, and iterate.

Agentic systems make one part of the loop dramatically cheaper: you can run more investigation, criticism, synthesis, and verification without having a human perform every intermediate step.

The hard problem therefore moves from “Can a model generate something impressive?” to:

Can the system preserve the right state while moving from uncertain intent to checked outcome?

1.1 Answer generation vs artifact progression

A chat answer is a terminal object. An artifact can be inspected, changed, versioned, tested, and reused.

Compare:

Question → Answer

with:

Goal Contract
→ Plan
→ Evidence Ledger
→ Decision Log
→ Implementation / Draft
→ Verification Report

The second pipeline creates objects that future agents and humans can work with.

That is the key design shift.

1.2 The three questions every stage must answer

At any point in the loop, the next participant should be able to answer:

What are we trying to achieve?
What do we currently know?
What is the next justified action?

Most bad agent workflows fail because one of those becomes implicit.

The goal gets lost in a long context.

The evidence gets mixed with speculation.

The next action is chosen because the previous model sounded confident.

The loop exists to keep those three questions explicit.

1.3 Why “more agents” is the wrong objective

Suppose one agent can solve a task in eight tool calls.

You create four agents:

Planner
Researcher
Critic
Verifier

Now you have:

five contexts instead of one,
more routing,
more state transfer,
more tokens,
more latency,
more opportunities for contradiction.

Unless those extra contexts buy something real — independent evidence, parallel work, specialized tools, better verification, or useful isolation — you have increased complexity without increasing capability.

That is why the architecture should be demand-driven.

2. When multi-agent actually helps — and when it makes things worse

The question is not whether multi-agent systems are powerful.

They are.

The question is where the power comes from.

A useful model is:

Multi-agent benefit
≈
parallelism
+ context isolation
+ specialization
+ independent criticism
+ additional tool capacity
− coordination cost
− token cost
− latency
− new failure modes

There is no universal numeric formula. The point is architectural: every additional agent introduces a cost that should have a reason to exist.

2.1 The task topology test

Before creating a team, classify the task.

Task characteristic	Single agent	Multi-agent
Short and self-contained	Usually sufficient	Often unnecessary
Tightly coupled sequence	Often preferable	Can add synchronization cost
Many independent research branches	Limited by sequential time/context	Strong fit
Different domains/tools	Possible but context-heavy	Strong fit when boundaries are real
Need independent adversarial review	Self-review possible	Separate critic can help
High-risk execution	Needs gates	Separate verifier/HITL can help
Large context exceeds one useful working set	Harder	Context partitioning can help
Deterministic pipeline	Usually better in code	Multi-agent may be overkill

The September 2026 paper Rethinking Multi-Agent Collaboration: When More Is Less makes this same distinction more formally: benefits are strongest on long-horizon tasks with sparse dependencies, while tightly coupled sequential workflows can favor single-agent systems because coordination overhead becomes dominant.

Source: Rethinking Multi-Agent Collaboration: When More Is Less.

2.2 Sparse dependency vs dense dependency

This distinction is one of the fastest ways to decide.

Sparse dependency

A ───┐
B ───┼──→ synthesis
C ───┤
D ───┘

A, B, C, and D can work independently.

Multi-agent is attractive.

Dense dependency

A → B → C → D
    ↑   ↓
    └───┘

Each stage depends on details from the previous one.

A single agent or deterministic workflow may be easier to manage.

2.3 The independence test

Before spawning a specialist, ask:

Could this person work independently for ten minutes and return something another person can actually consume?

If the answer is no, it probably is not a good parallel subtask.

2.4 The context test

Ask:

Does the specialist need the whole conversation?

If not, isolate it.

A performance researcher probably does not need the entire product brief.

A fact checker probably does not need the entire brainstorming transcript.

A security specialist may need the architecture and changed files, but not the marketing discussion.

Context isolation is not just a cost optimization. It is often a quality optimization.

2.5 The “do not spawn” rule

Create no extra agent when:

- the task is simple,
- there is no meaningful parallelism,
- all stages need the same context,
- deterministic tools already solve the verification problem,
- or the expected benefit is purely stylistic.

A good orchestrator can say:

No specialist required.
Proceed with single-agent execution.

That is mature orchestration.

3. Plan Mode: the boundary between thinking and changing the world

Plan Mode is useful for a deceptively simple reason: it makes the plan visible before the implementation becomes expensive to undo.

Cursor describes Plan Mode as a flow in which the agent researches the codebase, asks questions, creates a detailed plan, lets you review or edit it, and then builds from that plan. Plans can be saved to the workspace. Cursor's CLI also exposes plan mode through commands such as /plan and --mode=plan.

Claude Code similarly supports a plan permission mode, as well as subagents and agent teams for more involved workflows.

Sources:

3.1 Reversible reasoning vs irreversible action

Without a planning boundary:

request
  ↓
agent edits
  ↓
discovers constraint
  ↓
edits again
  ↓
discovers dependency
  ↓
repairs previous edit
  ↓
human untangles diff

With one:

request
  ↓
inspect
  ↓
identify constraints
  ↓
compare approaches
  ↓
plan
  ↓
review
  ↓
execute

The model did not become smarter.

The workflow became safer.

3.2 The Goal Contract

Before the plan, freeze the problem.

goal: "Refactor the authorization layer without changing behavior"
constraints:
  - "preserve public API"
  - "preserve current authorization semantics"
  - "keep existing tests passing"
forbidden:
  - "framework migration"
  - "database schema change"
acceptance:
  - "all existing tests pass"
  - "new regression tests pass"
  - "duplicate authorization branches removed"
unknowns:
  - "legacy route behavior"

The contract should be easy to quote and hard to misinterpret.

3.3 A plan should predict the future

Weak:

Improve architecture and reliability.

Falsifiable:

Replace duplicated permission resolution in modules A and B with the existing canonical resolver, preserve public signatures, add regression coverage for guest/admin boundaries, then compare the approved file scope against the final diff.

The second version can fail.

That is precisely why it is useful.

3.4 Planning anti-patterns

The architecture fan fiction problem

The agent assumes abstractions exist because they would be sensible.

Fix:

Inspect first.
If a component is not found, mark it UNKNOWN.
Do not invent it.

The “everything is in scope” problem

The user asks for a refactor. The agent silently redesigns three systems.

Fix:

approved files
approved services
forbidden changes

The plan that cannot be tested

If you cannot explain how a step will be verified, the step is not ready.

4. The artifact-first architecture

The most important design decision is to make the shared state visible.

Do not design around “who talks to whom.”

Design around what artifacts move through the system.

I recommend five canonical artifacts:

1. Goal Contract
2. Plan
3. Evidence Ledger
4. Decision Log
5. Verification Report

4.1 Goal Contract

It is the stable definition of success.

# Goal Contract

Goal:
Refactor the reporting module without changing public behavior.

Constraints:
- preserve API
- preserve error semantics
- preserve current output format

Forbidden:
- schema migration
- framework replacement
- unrelated cleanup

Definition of done:
- existing tests pass
- regression suite passes
- public API diff is zero
- performance remains within target

4.2 Plan

The plan is a hypothesis, not a promise that reality will obey it.

It should contain:

observed locations,
dependencies,
assumptions,
sequence,
risks,
acceptance tests,
rollback/recovery path.

When new evidence invalidates the plan, revise the plan instead of pretending the old one still describes reality.

4.3 Evidence Ledger

This is the artifact that prevents repetition from turning into truth.

Field	Purpose
Claim	The exact statement being asserted
Source	URL, file, test, benchmark, tool result
Source type	Official docs / code / experiment / research / secondary
Published / observed	Freshness
Evidence	What the source actually establishes
State	VERIFIED / SUPPORTED / PLAUSIBLE / UNKNOWN
Conflicts	Contradictory evidence
Used for	Decision or plan step

Example:

claim: "OAI-SearchBot is relevant to OpenAI web search discovery"
source: "OpenAI Publishers and Developers FAQ"
source_type: "official-documentation"
state: "VERIFIED"
used_for: "AI crawler preflight"

The source can support the claim without supporting a much stronger claim such as “this guarantees citation.”

That distinction is the entire point of an evidence ledger.

4.4 Evidence states

Use a small vocabulary.

State	Meaning	Allowed use
VERIFIED	Directly observed, mechanically tested, or clearly established by a primary source for the exact claim	Can drive decisions
SUPPORTED	Strong evidence, but not fully reproduced or narrower than the claim	Can inform decisions
PLAUSIBLE	Reasonable interpretation	Must remain labeled
UNKNOWN	Evidence is missing	Must not silently become fact

A downstream agent should never be able to transform UNKNOWN into VERIFIED merely by repeating it.

4.5 Decision Log

Record choices and rejected alternatives.

Decision: Use manager + specialist-as-tool orchestration.

Rejected: unrestricted peer handoffs.

Reason: final synthesis needs one owner and specialists have bounded tasks.

Evidence: OpenAI Agents SDK manager-style orchestration guidance.

Decision logs become more valuable over time because they explain not just the current architecture, but why it exists.

4.6 Verification Report

The final report should read like a proof, not a celebration.

Criterion 1 — PASS
Evidence: 128/128 tests passed.

Criterion 2 — PASS
Evidence: public API snapshot unchanged.

Criterion 3 — FAIL
Evidence: duplicate branch remains in module C.

Decision: NO-GO
Repair: remove duplication and rerun targeted suite.

That document is reusable by the next agent, reviewer, or human.

5. Roles and topologies: choose structure from the task

Roles are useful as long as they represent different responsibilities, context, or authority.

The classic four-role model is a good starting point, not a law:

Role	Primary job	Input	Output	Authority boundary
Planner	Decompose goal and propose sequence	Goal + evidence	Plan + risks + criteria	Cannot silently redefine goal
Critic	Attack assumptions and plan	Goal + plan	Failure modes + evidence	Cannot rewrite requirements
Specialist	Resolve a narrow uncertainty	Question + scoped context	Evidence-backed recommendation	Cannot expand scope
Executor	Make approved changes	Approved plan	Implementation/draft	Cannot redefine contract
Verifier	Test the result against contract	Goal + result + raw evidence	PASS/FAIL/UNKNOWN	Cannot silently waive criteria
Human	Final authority on ambiguous or high-impact decisions	Full relevant state	Binding decision	—

5.1 Sequential orchestration

Planner → Specialist → Executor → Verifier

Use it when each step depends on the prior output.

5.2 Concurrent orchestration

        ┌→ Research A ─┐
Planner ┼→ Research B ─┼→ Synthesizer
        └→ Research C ─┘

Use it when branches are independent.

5.3 Handoff

Triage → specialist

Use it when a specialist should take over the active context or user interaction.

5.4 Manager + agents-as-tools

                 ┌→ Specialist A
Manager ─────────┼→ Specialist B
                 └→ Specialist C
                     ↓
                 final synthesis

Use it when one agent should own the final answer and decide when specialists are needed.

OpenAI's Agents SDK explicitly documents both manager-style “agents as tools” and handoff patterns, as well as code-driven orchestration where the application owns the workflow.

Source: OpenAI Agents SDK — Agent orchestration.

5.5 Group chat

A ↔ B ↔ C ↔ Manager

Group chat can work for genuine deliberation, but it has a nasty failure mode: everyone keeps talking because nobody owns stopping.

Use explicit round limits and a decision owner.

5.6 Dynamic / magentic orchestration

Microsoft's Agent Framework describes magentic orchestration as a manager coordinating specialized agents dynamically based on evolving task state.

That is useful when the path is not known in advance.

It is not automatically better than a simpler pipeline.

Source: Microsoft — Magentic orchestration.

5.7 The topology decision matrix

Question	If YES	If NO
Can branches run independently?	Consider concurrent agents	Prefer sequential/single-agent
Does a specialist need unique context/tools?	Isolate the specialist	Keep context unified
Must one agent own the final answer?	Manager + agents-as-tools	Handoff/peer topology possible
Can the next step be coded deterministically?	Orchestrate in code	LLM can help route
Is open-ended planning unavoidable?	Dynamic manager may fit	Simpler topology is preferable
Can a test answer the question?	Use deterministic verification	Model/human evaluation may be needed

6. The dialogue protocol: Action, State, Result

A multi-agent system can fail even when every individual model response looks good.

Why?

Because communication itself is a system resource.

Consider:

Agent A → 2,000-word explanation
Agent B reads it and writes 1,800 words
Agent C receives A+B and writes 1,500 words
Agent D receives everything and decides what matters

Much of that text is explanation of reasoning history, not state required to continue.

A June 2026 paper, What Should Agents Say? Action-state Communication for Efficient Multi-Agent Systems, introduces PACT — Protocolized Action-state Communication and Transmission. The paper studies several communication strategies and argues that useful inter-agent messages should preserve action-centered state rather than blindly forwarding free-form outputs. Its experiments report a substantially better performance-cost trade-off and reduced token consumption in tested settings. The paper also emphasizes that no single fixed communication strategy is optimal everywhere.

Source: PACT.

The part worth stealing is straightforward:

Pass the state needed to continue, not the transcript that produced it.

6.1 The Action-State-Result message

A practical handoff record:

### Action-State Message

From: Critic
To: Planner

Action:
Reject plan step 3.2.

State:
The plan assumes generated routes are all crawlable. Repository inspection shows that one route family can produce orphaned URLs without canonical links.

Result:
Add a route-crawlability acceptance test and an explicit canonical URL requirement.

Evidence:
route manifest + crawler output + relevant source file.

Confidence:
High.

Next needed:
Revise step 3.2 before execution.

6.2 Why “Result” is useful

“Action” says what happened.

“State” says why.

“Result” says what artifact or decision the receiver should carry forward.

Without Result, the next agent has to reconstruct the intended handoff.

6.3 Keep messages receiver-oriented

A sender may care about fifty details.

The receiver may need five.

A good message answers:

What changed?
Why does it matter?
What should I use?
What remains unresolved?

6.4 Do not pass private chain-of-thought

Structured coordination does not require passing hidden reasoning traces.

Pass:

observations,
tool outputs,
conclusions,
evidence,
decisions,
unresolved questions,
next actions.

That is enough to coordinate.

6.5 A compact JSON form

When you need machine-readable handoffs:

{
  "action": "reject_plan_step",
  "state": "route family can produce orphaned URLs",
  "result": "add crawlability + canonical acceptance test",
  "evidence": [
    "route-manifest.json",
    "crawler-output.json"
  ],
  "confidence": "high",
  "next_needed": "revise_plan"
}

This is especially useful when the orchestrator is code-driven.

7. The complete Iterative Creation Loop

The loop is a sequence of gates, not a ritual for its own sake.

7.1 Step 0 — Freeze the contract

Write:

Goal
Constraints
Forbidden changes
Definition of done
Unknowns

Do this before the team gets creative.

7.2 Step 1 — Observe

Rule:

No invention where inspection is possible.

For software, inspect:

source tree,
relevant files,
dependencies,
tests,
configuration,
current abstractions,
recent changes.

For research, inspect:

primary sources,
official documentation,
current product behavior,
research papers,
contradictory evidence.

For content, inspect:

search intent,
authoritative references,
terminology,
competing interpretations,
audience questions.

The output should begin with Observed Facts.

7.3 Step 2 — Plan

The Planner produces:

observed facts
assumptions
proposed sequence
dependencies
risks
acceptance tests
rollback path

Anything unverified stays labeled.

7.4 Step 3 — Challenge

The Critic gets one instruction:

Assume the plan is wrong. Find the smallest number of high-impact reasons it can fail.

Prioritize:

goal violations
wrong assumptions
hidden dependencies
missing tests
security/reliability risks
scope creep
unnecessary complexity

Do not ask the Critic to rewrite the plan.

Ask it to break the plan.

7.5 Step 4 — Specialize

Spawn specialists only for unresolved uncertainty.

Examples:

Performance question
Security question
Framework compatibility question
Research evidence question
Accessibility question
Crawler behavior question

A specialist assignment should be narrow enough to fit in one sentence.

7.6 Step 5 — Resolve disagreements

Do not use:

latest response wins

Use an evidence priority ladder:

1. direct mechanical evidence
2. reproducible experiment
3. official / primary documentation
4. source-code inspection
5. peer-reviewed or clearly identified research
6. strong secondary analysis
7. expert judgment
8. model intuition

This is a practical heuristic, not a universal scientific ranking. Its job is to stop rhetorical confidence from outranking evidence.

7.7 Step 6 — Refine the canonical plan

Do not append more debate to a giant transcript.

Update the Plan.

The plan should remain the canonical current state.

7.8 Step 7 — Approve a checkpoint

Do not approve an entire risky implementation as one atomic promise.

Approve a small unit:

Checkpoint 1
→ execute
→ verify
→ update state

Checkpoint 2
→ execute
→ verify
→ update state

7.9 Step 8 — Execute

Execution should now have a contract, scope, and test conditions.

7.10 Step 9 — Verify

The verifier should see:

Goal Contract,
acceptance criteria,
resulting artifact,
relevant raw evidence,
deterministic test output.

It should not be told the conclusion in advance.

7.11 Step 10 — Learn

Record:

what failed
which assumption was wrong
which test caught it
which communication was wasteful
whether the specialist was necessary
whether the overall topology paid off

That becomes future organizational memory.

7.12 The complete state diagram

┌──────────┐
│  OBSERVE │
└────┬─────┘
     ↓
┌──────────┐
│ CONTRACT │
└────┬─────┘
     ↓
┌──────────┐
│   PLAN   │
└────┬─────┘
     ↓
┌──────────┐
│ CHALLENGE│
└────┬─────┘
     ↓
┌──────────┐
│SPECIALIZE│  only where needed
└────┬─────┘
     ↓
┌──────────┐
│  REFINE  │
└────┬─────┘
     ↓
┌──────────┐
│ APPROVE  │
└────┬─────┘
     ↓
┌──────────┐
│ EXECUTE  │
└────┬─────┘
     ↓
┌──────────┐
│ VERIFY   │
└────┬─────┘
     ↓
┌──────────┐
│  LEARN   │
└────┬─────┘
     │
     └────────────→ OBSERVE

8. How to run the loop today: Cursor, Claude Code, SDKs, and custom harnesses

The framework should come after the workflow.

8.1 Cursor

Cursor's Plan Mode is a natural home for the first half of the loop:

Plan Mode
→ inspect repository
→ ask questions
→ create/edit Markdown plan
→ review
→ build
→ review diff
→ run checks

Cursor's documentation specifically recommends Plan Mode for complex features, multi-file changes, uncertain requirements, and architecture decisions. For small familiar edits, it says Agent mode can be appropriate instead.

Useful references:

Practical setup

1. Write Goal Contract.
2. Enter Plan Mode.
3. Ask for observed facts first.
4. Ask for plan + acceptance tests.
5. Run a fresh-context Critic pass.
6. Revise the plan.
7. Build one checkpoint.
8. Run deterministic checks.
9. Run verifier.

8.2 Claude Code

Claude Code supports plan-oriented permission control, subagents with separate working contexts, and agent teams for more independent coordination.

The useful distinction is:

Subagent
= isolated worker for a bounded task

Agent team
= multiple independent sessions coordinating on a broader problem

Use subagents when the intermediate work is large but only the result needs to return to the main context.

Use teams when independent workers need to coordinate around a shared task.

Useful references:

8.3 OpenAI Agents SDK

OpenAI's current SDK docs describe two broad orchestration strategies:

LLM-driven: the model decides which agents/tools to invoke.

Code-driven: application logic determines the flow.

It also distinguishes:

Agents as tools: manager retains control.

Handoffs: specialist takes over.

The same docs describe chaining, evaluator loops, and parallel agent execution as common code-driven patterns.

That gives you a straightforward implementation of the Iterative Creation Loop:

planner
→ critic
→ refiner
→ executor
→ evaluator
→ repair/replan

References:

8.4 LangChain and LangGraph

LangChain's current documentation explicitly treats multi-agent design as a context-engineering problem and documents patterns such as:

subagents,
handoffs,
routers,
skills.

LangGraph gives more explicit graph/state control for applications that need persistent, inspectable workflow transitions.

References:

8.5 CrewAI

CrewAI is a role-and-task-oriented way to prototype crew workflows.

The important question is not whether the framework calls your process a “crew.” The important question is whether you can represent:

Goal
→ task decomposition
→ ownership
→ dependencies
→ outputs
→ verification

Reference: CrewAI documentation.

8.6 Microsoft Agent Framework

Microsoft's current Agent Framework documentation exposes several orchestration patterns:

Sequential
Concurrent
Handoff
Group Chat
Magentic

It also supports human-in-the-loop workflow interactions.

This vocabulary is useful even if you never use the framework because it gives you names for different coordination shapes.

References:

8.7 Framework selection table

Need	Reasonable starting point	Core strength
Interactive coding + planning	Cursor	Plan → Build workflow
Terminal-first coding + workers	Claude Code	Subagents / teams / permission controls
Lightweight custom Python agent workflow	OpenAI Agents SDK	Small primitives + tracing/orchestration
Stateful workflow graph	LangGraph	Explicit transitions and state
Crew-style rapid prototype	CrewAI	Role/task abstraction
Enterprise orchestration patterns	Microsoft Agent Framework	Rich topology vocabulary + HITL

This is not a ranking. It is a fit map.

9. What the 2025–2026 evidence actually tells us

The multi-agent field has accumulated enough evidence that “more agents = smarter” is no longer a serious design principle.

The interesting question is where the gains come from and where they disappear.

9.1 Anthropic: more compute can buy more research capacity

Anthropic's engineering report on its multi-agent Research system is one of the clearest public examples.

The architecture uses a lead agent to plan research and delegates directions to subagents that investigate in parallel.

Anthropic reports:

90.2% improvement over its single-agent baseline on its internal BrowseComp evaluation,
roughly 15× the token usage of ordinary chat,
major gains from parallelization and additional context capacity,
poor fit for some tightly coupled tasks where agents need heavy shared context.

The right lesson is not “use many agents.”

It is:

When a task has high value, lots of parallelizable information gathering, and a bottleneck in one context, multi-agent execution can buy useful additional reasoning capacity.

Source: Anthropic — How we built our multi-agent Research system.

9.2 PACT: communication is an optimization surface

PACT asks a narrower question:

What should agents actually say to each other?

The answer is not “send everything.”

The paper evaluates multiple strategies and proposes Action-State communication as a way to preserve decision-relevant information while reducing unnecessary context transfer. It reports substantial token savings in its experiments, including improvements on evaluated coding harnesses.

The most transferable idea is:

public state update
> conversation transcript

Source: PACT.

9.3 MAST: coordination creates failure modes

The paper Why Do Multi-Agent LLM Systems Fail? analyzed more than 150 traces in detail to build a taxonomy of 14 failure modes grouped into:

specification and system design,
inter-agent misalignment,
task verification and termination.

The project later made a larger annotated trace dataset available for broader evaluation.

The important point is architectural:

A multi-agent system is a new system. It needs its own reliability engineering.

Source: MAST.

9.4 MultiAgentBench: coordination itself can be measured

The ACL 2025 MultiAgentBench work evaluates not only task completion but also coordination behavior. It studies star, chain, tree, and graph coordination protocols and uses milestone-oriented metrics.

That is useful because final accuracy alone hides system behavior.

A workflow can produce the right answer for the wrong reasons.

It can also spend enormous resources to produce a modest result.

Source: MultiAgentBench.

9.5 September 2026: “when more is less” becomes the central question

The September 2026 study Rethinking Multi-Agent Collaboration: When More Is Less directly examines scaling agent pools and recursion depth.

Its key message is that task structure defines the capability boundary. More agents do not consistently create better outcomes.

That is almost exactly the reason this guide refuses to make “four agents” or “ten agents” into a universal recipe.

Source: Rethinking Multi-Agent Collaboration.

9.6 The evidence pattern

Across these sources, a coherent engineering picture emerges:

Multi-agent helps when:
+ work can be decomposed
+ branches are reasonably independent
+ contexts benefit from isolation
+ additional tool capacity matters
+ independent checking has real value

Multi-agent hurts when:
− dependencies are dense
− everyone needs the same context
− communication dominates work
− verification is weak
− agents duplicate each other
− the task is too small to justify the overhead

That is a much more useful conclusion than “multi-agent is the future.”

10. Four practical playbooks: software, research, content, and products

The loop is abstract. These playbooks make it concrete.

10.1 Software: refactor without behavioral drift

Goal

Split a large reporting module without changing its public behavior.

Planner

Inspect:

public exports,
callers,
shared state,
tests,
performance-sensitive paths,
configuration.

Output:

current boundaries
candidate extraction points
dependency order
regression tests
rollback path

Critic

Attack:

hidden coupling
changed error behavior
circular dependencies
performance regressions
snapshot drift
unapproved files

Specialist

Performance specialist gets one question:

Does extracting the formatter move work onto a hot path or duplicate serialization?

Executor

Changes only approved files.

Verifier

Prefer deterministic gates:

unit tests
integration tests
type checking
lint
build
API snapshot
benchmark
diff scope

Example verification record

PASS — 128/128 unit tests
PASS — 24/24 integration tests
PASS — 0 type errors
PASS — public API unchanged
PASS — benchmark within target
PASS — changed files within approved scope

The LLM is not the whole verifier.

It is the layer that interprets results the deterministic tools cannot fully interpret.

10.2 Research: build an evidence map instead of a pile of summaries

Question:

How do current AI search systems discover and use web sources?

Do not launch six generic “researchers.”

Partition the uncertainty:

Worker	Question
A	What do official search/platform docs say?
B	What do primary academic studies measure?
C	What current crawler/access controls exist?
D	What contradicts the optimistic interpretation?
E	How should citation visibility actually be measured?

Each worker returns structured records:

claim: "X"
source: "https://example.com/source"
source_type: "official-docs"
published: "2026-08-12"
evidence: "exact observation"
state: "SUPPORTED"
limitations:
  - "platform-specific"

The most valuable research role is often not another researcher.

It is the disconfirmation researcher.

Give one worker this job:

Find evidence that would make the emerging conclusion wrong or materially weaker.

That reduces confirmation cascades.

10.3 Content: separate epistemic work from style work

A strong technical article can use this pipeline:

Question map
    ↓
Evidence map
    ↓
Argument map
    ↓
Outline
    ↓
Draft
    ↓
Fact check
    ↓
Human-voice edit
    ↓
SEO/GEO preflight

The bad pipeline is:

SEO agent
→ writer
→ humanizer
→ GEO agent
→ headline agent
→ final polish agent

Why?

Because every agent is optimizing surface form. Nobody is clearly responsible for epistemic truth.

Content claim labels

A useful internal label set:

FACT
REPORTED RESULT
OBSERVATION
INTERPRETATION
OPINION
PROPOSAL
UNKNOWN

The published article does not need to display every label. The internal workflow should know them.

10.4 Product creation: give each role a different failure target

Use four perspectives:

Role	Question
Planner	What should exist?
User Advocate	Where will users misunderstand or abandon it?
Technical Specialist	What is expensive, risky, or fragile?
Verifier	What evidence proves the product solved the stated problem?

The User Advocate should have a concrete assignment:

Find every place where the product asks the user to understand our internal architecture instead of understanding their own job.

That produces much more actionable feedback than “review UX.”

11. Verification and measurement: make “done” observable

A workflow becomes an engineering system when it can explain why it believes it is complete.

11.1 Verification hierarchy

Use the cheapest reliable gate first.

LEVEL 1 — Mechanical
schema validation
unit tests
type checks
lint
HTTP checks
file existence

LEVEL 2 — Deterministic comparison
snapshots
diffs
benchmarks
invariants
regression datasets

LEVEL 3 — Model evaluation
semantic quality
classification
summarization fidelity
comparative judgment
style compliance

LEVEL 4 — Human review
high-stakes decisions
ambiguous interpretation
final publication
material production changes

Do not use a model to answer a question a compiler can answer.

11.2 Criterion-by-criterion verification

Bad:

Everything looks good.

Good:

Criterion: Preserve public API
Status: PASS
Evidence: API snapshot diff = 0

Criterion: Remove duplication
Status: FAIL
Evidence: legacy branch remains in src/auth/legacy.ts

Criterion: Existing tests pass
Status: PASS
Evidence: 128/128

11.3 PASS / FAIL / UNKNOWN

UNKNOWN is important.

A verifier should be allowed to say:

I could not establish this criterion.

That is better than a fabricated PASS.

11.4 Fresh context does not automatically mean independence

A fresh verifier can still be biased if you feed it the creator's conclusion.

Avoid:

The implementation succeeded. Please verify it.

Prefer:

Original goal:
...

Acceptance criteria:
...

Result:
...

Raw test evidence:
...

Determine PASS / FAIL / UNKNOWN.

The verifier gets evidence, not the verdict.

11.5 Core metrics

Metric	Definition	Why it matters
First-pass success	Verified successes on first major execution	Planning quality
Rework ratio	Reworked changes / total changes	Downstream waste
Verification catch rate	Defects found by verification / defects discovered later	Value of verification
Tokens per successful task	Total tokens / verified successes	Economics
Time to verified result	Start → verification pass	Real speed
Human escalation rate	Human interventions / tasks	Autonomy and ambiguity
Scope violation rate	Out-of-contract changes / tasks	Particularly important for coding
Evidence coverage	Sourced material claims / material claims	Research/content quality

11.6 Run an A/B test on your workflow

Instead of debating whether multi-agent is “better,” compare:

A — one agent
B — planner + critic
C — planner + critic + specialist

For the same task class, measure:

cost
latency
pass/fail
rework
defects
verification catches
human interventions

Keep additional coordination only if it improves the verified outcome enough to justify its cost.

12. Failure modes: how good-looking agent systems break

Adding agents creates a new system. New systems create new failure modes.

MAST formalized this problem with 14 failure modes across specification/system design, inter-agent misalignment, and task verification/termination.

Source: Why Do Multi-Agent LLM Systems Fail?.

The following operational table turns that research into engineering checks.

Failure mode	Typical symptom	Prevention
Infinite dialogue	Agents keep discussing after information stops changing	Hard round cap + stop condition
Role collapse	Every agent produces the same generic review	Narrow objectives + authority boundaries
Duplicate research	Multiple workers investigate the same thing	Explicit research partitions
Context leakage	Agents lose focus in irrelevant history	Scoped context + structured handoffs
Consensus theater	Agents agree because previous text sounded confident	Adversarial critic + evidence hierarchy
Plan drift	Goal changes silently during implementation	Immutable Goal Contract
Hallucination propagation	Unsupported claim becomes accepted downstream	Evidence states
LLM-only verification	Fluent “PASS” with no real test evidence	Deterministic gates
Tool hallucination	Agent invents or misuses tools	Closed-world tool registry
Shared-state corruption	Multiple workers overwrite canonical artifacts	Ownership / single-writer rule
Token explosion	Communication costs exceed useful work	Action-State compression
Latency cascade	Sequential workers multiply wait time	Parallelize independent tasks
Premature termination	Manager stops before criteria are met	Explicit acceptance tests
Framework gravity	Workflow infrastructure exceeds task complexity	Start simpler

12.1 Infinite dialogue

Set:

max_rounds = 3

Then:

if no acceptance-blocking issue remains:
    approve
else:
    escalate

Do not let the system invent reasons to keep debating.

12.2 Consensus theater

A critic should be allowed to reject a plan.

But the Planner should be allowed to reject the Critic too when the objection is unsupported.

Good adversarial collaboration is not “everyone disagrees.”

It is:

claim
→ evidence
→ challenge
→ resolution

12.3 Hallucination cascades

One unsupported claim becomes dangerous when it passes through multiple agents:

UNKNOWN
 ↓
plausible
 ↓
supported-sounding
 ↓
“fact”
 ↓
implementation decision

Your state model should make that conversion explicit.

12.4 Shared-state corruption

For important artifacts, use a single canonical writer.

Critic      → proposes change
Specialist  → proposes evidence
Planner     → updates canonical plan
Verifier    → updates verification report
Human       → approves/rejects high-impact decisions

Others propose. One owner commits.

12.5 Tool hallucination

Maintain a closed-world registry:

tool: run_tests
description: "Runs the repository's configured test suite"
permissions: [read, execute]
side_effects: "may create temporary files"

Do not let an agent assume that “there must be a tool for that.”

12.6 Token economics

A workflow can be technically successful and economically absurd.

Anthropic's published 15× token figure for multi-agent Research is a useful warning, even though it is specific to Anthropic's architecture and evaluation.

Measure:

cost per verified success

not merely:

cost per run

13. SEO, GEO, and AI-readable publishing without the folklore

Agent-created work increasingly becomes public content.

That creates a second problem: once the workflow produces a great article, how do you make it easy for people, search engines, and AI systems to discover and understand without turning the article into “SEO soup”?

The answer starts with a distinction:

Machine-readable information architecture is useful. Magic GEO hacks are not a substitute for it.

13.1 What Google actually says in 2026

Google's current guidance on AI features is unusually direct:

existing SEO best practices remain relevant,
pages need to be indexed and eligible for Search to be supporting links in AI Overviews or AI Mode,
there are no extra technical requirements specifically required for those AI features,
important content should be available in textual form,
internal links, crawlability, page experience, and useful original content remain important,
there is no special schema.org markup required for AI Overviews or AI Mode.

Google also says meeting best practices does not guarantee crawling, indexing, or serving.

Sources:

That last point matters because it kills one of the worst forms of AI-search marketing:

“Do these three things and Google AI will cite you.”

There is no such universal guarantee.

13.2 Search Console now gives a better measurement layer

Google introduced Search Generative AI performance reporting in June 2026 and said it had rolled those insights out worldwide by August 31, 2026.

The reports expose visibility within generative AI features on Search, including AI Overviews and AI Mode, inside Search Console's performance reporting system.

That is a major practical improvement because it gives publishers a first-party measurement surface rather than forcing all AI-search analysis into third-party guesses.

Source: Google Search Central — Search Generative AI performance reports.

Use that data where available.

13.3 What “AI-readable” should mean

A useful page should let a machine answer:

What is this page about?
Who wrote it?
When was it published/updated?
What are the major claims?
What evidence supports them?
Which sections answer which questions?
Which parts are facts versus interpretations?
Where are the primary sources?
What is the canonical version?

That is not special AI formatting.

It is good information architecture.

13.4 Structure for long-form reference content

A durable article structure:

Title
↓
TL;DR
↓
Table of Contents
↓
Definition / thesis
↓
Evidence
↓
Counterexamples
↓
Architecture
↓
Implementation
↓
Examples
↓
Failure modes
↓
Measurement
↓
Limitations
↓
Templates
↓
Sources

That structure helps humans and retrieval systems for the same underlying reason: it reduces ambiguity.

13.5 Structured data: useful, not magical

For an article, relevant Schema.org properties may include:

Article
author
datePublished
dateModified
headline
image
mainEntityOfPage

But the markup should describe the visible content accurately.

Do not claim that Article schema guarantees AI citations or rankings.

Google's structured-data documentation explicitly says structured data helps it understand content, while eligibility and appearance depend on additional systems and requirements.

Sources:

13.6 robots.txt is one layer, not the whole stack

Google says robots.txt controls crawler access; it is not a general noindex mechanism.

To keep pages out of Google Search, Google points to noindex or authentication rather than relying on robots.txt alone.

Sources:

For AI crawlers, the same practical truth applies: the page can be allowed by robots.txt and still fail through other infrastructure.

Think in layers:

robots.txt
   ↓
WAF / CDN
   ↓
bot mitigation
   ↓
authentication
   ↓
rate limiting
   ↓
JavaScript challenges
   ↓
HTTP response
   ↓
rendering / retrieval

OpenAI documents OAI-SearchBot for web search-related discovery and provides publisher guidance about allowing access. Anthropic documents separate crawler identities such as ClaudeBot, Claude-User, and Claude-SearchBot.

Sources:

13.7 `llms.txt`: reasonable experiment, not magic SEO

The llms.txt project is a community proposal for presenting curated machine-oriented information about a site.

It can be useful as documentation.

It is not a universal Google requirement.

Google's current generative AI guidance explicitly says you do not need to create special AI text files such as llms.txt to appear in its generative AI search features.

Sources:

Use it because it serves a clear information-architecture purpose, not because someone sold it as a ranking switch.

13.8 GEO measurement is more than citation count

Recent 2026 research is pushing toward a more precise model of AI-search visibility.

One April 2026 study separates:

citation selection
≠
citation absorption

A page can be retrieved and cited without materially contributing to the generated answer.

A July 2026 survey similarly describes GEO as a multistage process involving discoverability, retrieval, reranking, citation, prominence, factual absorption, and downstream user behavior.

Sources:

This suggests a better measurement stack:

Discoverability
↓
Retrieval
↓
Citation
↓
Citation position / prominence
↓
Answer contribution
↓
Factual fidelity
↓
Traffic / conversions

That is much more informative than “AI visibility score = 83.”

13.9 What recent GEO research suggests — carefully

2026 studies are finding associations and controlled effects involving factors such as topical relevance, context position, explicit factual information, structure, and evidence richness. One competitive GEO study evaluated 252,000 controlled trials across six LLMs; another large ACL 2026 study explores latent user-demand alignment; a separate framework studies how citation influence differs from citation selection.

These are valuable research directions.

But they should not be flattened into universal advice such as:

“Write exactly X words, add Y headings, and every AI will cite you.”

The stronger practical claim is safer:

Make important information explicit, relevant, well-supported, easy to retrieve, and faithful to the source material.

Sources:

13.10 Practical GEO/SEO preflight

TECHNICAL
[ ] Crawlable when intended
[ ] Indexable when intended
[ ] Canonical URL is correct
[ ] Important text is accessible
[ ] No accidental noindex
[ ] Internal links are present
[ ] HTTP responses are healthy

CONTENT
[ ] Clear title
[ ] One clear H1
[ ] Coherent heading hierarchy
[ ] Direct answers to major questions
[ ] Definitions before jargon
[ ] Material claims supported by sources
[ ] Facts separated from interpretation
[ ] Publication/update date
[ ] Author / provenance

AI ACCESS
[ ] Intended AI crawler policy is deliberate
[ ] WAF/CDN does not silently block intended access
[ ] Authentication is understood
[ ] Rate limits are sane
[ ] JavaScript challenges are not accidental blockers

STRUCTURE
[ ] Accurate Article/Organization/etc. structured data where appropriate
[ ] Structured data matches visible content
[ ] Stable URLs
[ ] Duplicate versions controlled
[ ] Sources are easy to follow

For a practical public-page preflight, AuditMe's Website SEO Checker can inspect a URL and surface issues across technical SEO, content structure, schema, performance, and related readiness dimensions.

That makes it useful as a diagnostic pass.

It is not proof that an AI system will cite the page.

AuditMe links for the workflow

The right way to use an audit tool in this process is as preflight evidence: find technical and structural problems before asking a search engine or AI system to discover the page.

14. The reusable operating kit

This section is designed to be copied.

You can put the templates in a repository, a knowledge base, a prompt library, or a workflow engine.

14.1 Goal Contract template

# Goal Contract

## Goal
[One precise sentence]

## Why
[Why the work matters]

## Constraints
- [constraint]
- [constraint]

## Forbidden Changes
- [forbidden change]
- [forbidden change]

## Definition of Done
- [measurable criterion]
- [measurable criterion]

## Unknowns
- [unknown]
- [unknown]

14.2 Planner prompt

You are the Planner.

Goal:
[goal]

Constraints:
[list]

Forbidden changes:
[list]

Definition of done:
[criteria]

First inspect the real evidence available to you.
Do not execute implementation.
Do not invent architecture.
Mark assumptions and unknowns explicitly.

Return:
1. Observed facts
2. Assumptions
3. Proposed plan
4. Dependencies
5. Risks
6. Acceptance tests
7. Rollback/recovery path

14.3 Critic prompt

You are the Critic.

Assume the current plan is wrong.
Find the smallest number of high-impact reasons it could fail.

Prioritize:
- goal violations
- incorrect assumptions
- hidden dependencies
- missing tests
- security/reliability risks
- unnecessary complexity
- scope creep

Do not rewrite the plan.
Return each issue as:

Action:
State:
Result:
Evidence:
Confidence:
Next needed:

14.4 Specialist prompt

You are a domain specialist.

Question to resolve:
[one specific question]

Do not review the entire project.
Do not redesign unrelated systems.
Prefer primary documentation, code inspection, tests, or reproducible measurements.

Return:
Action:
State:
Result:
Evidence:
Confidence:
Open questions:

14.5 Verifier prompt

You are the Verifier.

Original Goal:
[goal]

Definition of Done:
[criteria]

Inspect the result independently.
Do not rely on the creator's explanation.
Prefer deterministic evidence whenever available.

For every criterion return:
PASS / FAIL / UNKNOWN

For each result include:
- evidence
- blockers
- defects found
- repair needed

Final decision:
GO / CONDITIONAL GO / NO-GO

14.6 Human-voice editor prompt

You are the final human-voice editor.

Do not make the article more enthusiastic.
Make it more credible and authored.

Remove:
- generic AI transitions
- inflated adjectives
- repeated conclusions
- fake certainty
- unnecessary headings
- repetitive sentence rhythms

Preserve:
- technical specificity
- source attribution
- disagreement
- uncertainty
- concrete examples
- author judgment

Do not invent personal experience, clients, benchmarks, or case studies.

14.7 Agent handoff schema

from: "critic"
to: "planner"
action: "reject_plan_step"
state: "orphaned routes are possible"
result: "add crawlability and canonical acceptance test"
evidence:
  - "route-manifest.json"
  - "crawler-output.json"
confidence: "high"
next_needed: "revise_plan"

14.8 Suggested repository layout

.agent/
├── goal-contract.md
├── plan.md
├── evidence-ledger.md
├── decisions.md
├── verification.md
├── prompts/
│   ├── planner.md
│   ├── critic.md
│   ├── specialist.md
│   ├── verifier.md
│   └── human-voice-editor.md
└── runs/
    ├── 2026-09-22-run-001.md
    └── 2026-09-23-run-002.md

The exact directory does not matter.

The separation does.

14.9 Minimum Viable Loop — 15 to 30 minutes

0–5 minutes

Write:

Goal
Constraints
Forbidden changes
Definition of done
Unknowns

5–10 minutes

Plan Mode / planner pass.

10–15 minutes

Fresh-context Critic.

15–20 minutes

Resolve evidence-backed corrections.

20–25 minutes

Execute one checkpoint.

25–30 minutes

Verify against the original contract.

That is enough to start.

You do not need a distributed orchestration platform to get the core benefit.

14.10 Compact checklist

Before execution

[ ] Goal Contract exists
[ ] Constraints explicit
[ ] Forbidden changes explicit
[ ] Definition of done measurable
[ ] Real evidence inspected
[ ] Unknowns labeled
[ ] Plan falsifiable
[ ] Critic allowed to reject
[ ] Specialists have narrow assignments
[ ] Canonical plan has one owner

During execution

[ ] Independent work parallelized only where useful
[ ] Handoffs pass state, not speeches
[ ] Evidence provenance preserved
[ ] Tool permissions scoped
[ ] Checkpoints explicit
[ ] Scope remains inside contract
[ ] Raw test outputs retained

Before shipping

[ ] Deterministic checks passed
[ ] Material claims verified
[ ] Contradictions resolved or labeled
[ ] Final artifact matches Goal Contract
[ ] Unknowns documented
[ ] Verification is independent enough to matter
[ ] Cost / latency / rework measured
[ ] Final artifact is reusable

14.11 The 12 rules worth remembering

1. Start with one agent.

Do not architect a council before you can name the bottleneck.

2. Split by uncertainty, not by job title.

A specialist exists because something requires different context, tools, expertise, or independent judgment.

3. Parallelize independent work.

That is one of the clearest reasons to use multiple agents.

4. Keep the Goal Contract stable.

Otherwise the system can “succeed” by changing the problem.

5. Make the plan canonical.

Do not make chat history your database.

6. Pass state, not speeches.

Action + State + Result is a practical default.

7. Attack before executing.

A wrong assumption in Markdown is cheap. A wrong assumption inside a production diff is not.

8. Verify with the cheapest reliable method.

Compiler over conversation. Test over opinion. Source over memory.

9. Treat UNKNOWN as a valid state.

Missing evidence is information.

10. Measure verified outcomes.

Tool calls are activity. A passing acceptance test is evidence of progress.

11. Keep the framework smaller than the problem.

If orchestration is harder than the underlying task, simplify.

12. Stop when the goal is met.

More dialogue is not automatically more quality.

14.12 Final thought

The agent era will produce a lot of spectacular demos.

Some of them will be useful.

A lot of them will also confuse activity with progress.

Ten agents can talk for twenty minutes and produce nothing that a human can safely ship.

One agent can solve a hard problem with a good plan and a real test.

The interesting engineering problem is therefore not:

How many agents can I make collaborate?

It is:

What information must survive from one stage to the next so that the system can move from intention to evidence-backed action and finally to verified completion?

That is the Iterative Creation Loop.

The simplest implementation is still often the best:

Goal Contract
→ Plan
→ Adversarial Critique
→ Narrow Specialist when needed
→ Checkpoint
→ Deterministic Verification
→ Independent Review
→ Learn

Start there.

Measure it against the single-agent version.

Add complexity only when it buys something you can observe.

That is the part worth scaling.

Not the number of agents.

The quality of the loop.

Editorial note

This guide intentionally separates vendor-reported engineering results, academic findings, official product documentation, and practical heuristics.

Vendor metrics are not universal benchmarks. Academic results depend on benchmark design and experimental conditions. Product documentation describes the publisher's current stated behavior, not every possible real-world outcome. GEO measurements can vary by query, engine, source set, retrieval process, model, and time.

The most useful experiment remains the least glamorous one:

Run the same class of task with and without additional coordination. Measure the verified outcome. Keep only the complexity that actually improves it.