When dividing work between agents earns its cost

Before enabling an integration, a team needs to inspect API compatibility, access controls and failure recovery. Some of that inspection can run concurrently. The release decision still requires someone to combine the findings against the same system version.

This hypothetical example gives multi-agent design a concrete test. Identify work that can proceed independently and assign responsibility for integrating it. Naming one agent after each business department does not establish that the work is separable.

Find independent work in an existing run

Examine how the current system completes a representative task. Look for branches that can start from the same information and finish without waiting for each other. Independent source searches and reviews of different aspects of a change are possible candidates.

Preserve genuine dependencies. Checking inventory before reserving it is a sequence, regardless of how many agent names appear in the diagram. Application code can coordinate a fixed sequence without introducing several autonomous workers.

Anthropic distinguishes parallel work from dynamic delegation in Building effective agents. This is useful vocabulary for describing the execution plan. Adding model instances does not automatically improve that plan.

Give each worker a bounded contract

For the integration review, one worker could inspect the API contract while another checks access controls. Both need a recorded code version and a way to return verifiable findings, including limitations.

Specify the question each worker owns and its stopping condition. Define the sources it may read and the tools it may use. Its result format should support an incomplete or failed outcome. Assign a person or application component to integrate the result.

Enforce tool permissions in application code. Different role prompts do not create different credential scopes. Read-only access may be sufficient for an investigation; applying corrections can be a separate authorised phase.

The useful unit of delegation is a result that another component can check. A statement such as “everything looks fine” discards the scope and evidence needed to make a release decision.

Treat integration as engineering work

The coordinator must account for every assigned branch. If a worker times out, its area remains unreviewed. Preserve disagreements and request a targeted check rather than silently selecting the more confident report. Repeating a judgment with the same model and evidence does not establish independent agreement.

Assign ownership of writes as well. Concurrent workers can overwrite each other or duplicate a business action. Separate write scopes where possible and introduce an explicit integration step. Isolated worktrees help keep code changes apart, but they do not resolve behavioural conflicts without review and tests.

Keep references to source versions through handoffs. A compressed summary that drops an exception may change the meaning of a finding. Test what the integrating component does when an intermediate result lacks evidence or refers to a different version.

Measure elapsed time across the whole run

For two independent tasks, a simple model is:

T_sequential = T_shared + T_a + T_b + T_merge
T_parallel = T_shared + max(T_a, T_b) + T_merge + T_coordination

This model excludes queues and retries. Replace its terms with observed durations and include failure recovery when assessing the complete system. The slowest branch can determine the waiting time even when the others finish quickly.

Anthropic's multi-agent research report describes separate contexts supporting exploration in several directions. It also discusses token consumption and difficulties with tightly dependent work. Those findings belong to a particular research workload, rather than providing a universal performance gain for business software.

The extra cost includes duplicated context, intermediate output and the work required to check the combined result. Measure that cost per accepted task so incomplete or rejected results do not appear artificially efficient.

Compare against a credible simpler system

Fix the current system's tools and instructions before using it as the comparison. Evaluate a fixed division of tasks, and introduce dynamic delegation only when the input requires it. Keep input cases, versions and acceptance criteria consistent.

Track final quality alongside duplicated work and information lost during handoffs. Measure total elapsed time and the human review needed to make the result usable. A partial answer should remain a partial result in the evaluation record.

Test missing sources, failed tools and conflicting findings. Conventional contract, permission and integration tests still apply. Model evaluations add coverage for routing, task completion and output quality. Neither type of test replaces the other.

Define the reason to keep it

Continue with the more complex design when it fixes a relevant failure or improves an agreed measure while preserving safety and operational requirements. Remove it if the benefit disappears after retries or review effort are included. The maintaining team should be able to explain what each worker contributes and how its failure affects the user.

Multi-agent systems consulting can scope that comparison. The single-agent runtime guide helps define a simpler starting point with explicit execution controls.

Share one workflow and the reason you want to divide it. A technical review can identify independent branches and design a limited experiment before the team commits to additional coordination machinery.