Squad-Level Thinking Applied to Multi-Agent Systems

Squad-level planning offers an analogy for defining roles and handoffs in an AI workflow. It does not mean software agents behave like trained people, or that military experience establishes the quality of a technical design. Evaluate the actual system and its failures.

Start with one workflow before adding agents

Write down the input, required output, tools and acceptance check. Ask whether a fixed sequence or one bounded model call can do the job. Additional agents add coordination, latency, cost and more places for a handoff to fail.

Anthropic's building effective agents guidance distinguishes defined workflows from more autonomous agents and recommends adding complexity only when needed. Treat a multi-agent arrangement as a design to compare with a simpler baseline, not a default upgrade.

Define a handoff contract

For each role, specify what it receives, what it returns, which evidence it must preserve and which actions it may take. Give failures an explicit representation. A missing source is different from a successful result containing no relevant information.

Example handoff fields:

task_id
input_record_ids_and_versions
requested_output
permitted_tools_and_actions
result_or_failure_reason
supporting_source_locations
unresolved_questions
next_owner

These are suggested fields for a design exercise, not a claim that a particular agent framework implements them automatically.

Worked example: a draft knowledge-base answer

Use fictional documents for this example. A requester asks a question about an expense policy.

The retrieval step returns permitted passages with document versions and source locations. The drafting step produces an answer using those passages and marks gaps. A review step compares the draft with the evidence. A designated person decides whether the answer is ready for the intended use.

If the retrieval step returns no applicable current policy, the workflow should report that gap. It should not ask another agent to invent a policy. If two sources conflict, preserve both for review rather than resolving the conflict by a vote among models.

A second model is not independent assurance

Several agents can share the same missing context, model limitations or misleading source. A reviewer prompt can catch some errors, but agreement between agents does not establish truth.

Test with a wrong citation, a superseded document and an instruction embedded in a source that tries to redirect the task. Check the evidence and final behavior. An agent should not gain permission to contact someone or change a record because another agent told it to.

Make failure and recovery concrete

Keep a stable task identifier and record which step completed. Bound retries and escalation so two agents cannot hand the same unresolved task back and forth indefinitely. If a step can write or send something, define how a retry avoids duplicating that action.

A fallback model is another output to evaluate, not an automatic substitute for the approved workflow. A manual fallback should identify the person or queue responsible and what context will be available. Do not describe “human in the loop” as complete until that path has been exercised.

Compare the design on the same cases

Run the simpler workflow and the proposed multi-agent workflow against the same permitted inputs. Compare accepted task results, unsupported statements, missed evidence, latency, cost, handoff failures and reviewer effort.

Use held-out cases after making changes, and record the versions and assumptions. Do not turn one successful demonstration into an invented throughput or accuracy claim. More agents can be worthwhile when their distinct work resolves a measured limitation, but the architecture itself is not evidence of an improvement.

The embedding retrieval example provides a small source-and-permission test. The after-action review worksheet records failures and verifies follow-up changes.