Worked Example: A Multi-Agent Build

The task

Imagine a team needs to add a customer-facing export feature to a web product. The feature touches product requirements, API behavior, frontend states, authorization rules, analytics, and release notes. A single agent can do it, but it is likely to carry too much context in one trace and under-invest in independent verification.

This is a plausible multi-agent build because several parts can proceed in parallel after a shared plan exists. Research can inspect current product behavior and docs. Implementation can modify scoped files. Verification can run tests and browser checks. Editorial review can check release copy and user-facing language. The coordinator owns the final merge decision.

The agents

The system uses five roles. The lead orchestrator receives the user request, writes the initial task brief, and maintains the acceptance checklist. The researcher gathers product facts, existing patterns, and external constraints. The implementer changes code. The verifier runs tests, inspects behavior, and records failures. The editor reviews user-facing copy and final summary.

The important constraint is that agents do not own vague domains forever. They own a specific artifact for this task. The researcher owns a notes file. The implementer owns a patch. The verifier owns a test report. The editor owns copy comments. The orchestrator owns the final decision log.

The execution trace

1. Plan: The orchestrator writes the scope, non-goals, acceptance criteria, and expected artifacts.
2. Research: The researcher reads existing routes, API contracts, permissions, and relevant product docs, then records claims with file links and source URLs.
3. Implement: The implementer edits only files named in scope or justified by the research artifact.
4. Verify: The verifier runs targeted tests, browser checks, and failure reproduction, then writes exact commands and results.
5. Synthesize: The orchestrator compares the artifacts against the acceptance checklist and either requests a focused fix or prepares the final handoff.

Notice what is absent: no agent is asked to "think about the whole thing" in parallel with every other agent. The split happens after the initial plan and through typed artifacts. That is how the design avoids the context-fragmentation problem described by Cognition.

Artifact contracts

Each artifact has a contract. Research notes include claim, evidence, location, confidence, and open questions. The patch includes changed files and why each change belongs in scope. The test report includes commands, environment, pass or fail result, and remaining risk. The editor's comments include exact text and the user-facing principle behind the edit.

These artifacts let later agents inspect decisions without replaying every subagent token. They also make review possible for humans. A human can ask whether the research supports the implementation, whether the verifier tested the promised behavior, and whether the final summary honestly states residual risk.

Gates and stop conditions

The build has four gates. The plan gate blocks work until scope and artifacts are defined. The implementation gate blocks broad edits unless research shows they are needed. The verification gate blocks final summary while tests are missing or failing. The risk gate requires a human if the feature touches irreversible actions, payments, data deletion, or compliance language.

This system is not a swarm because "swarm" would obscure the control model. It is an orchestrator-worker workflow with fixed gates. It uses multiple agents where they add independent labor, then returns to a single accountable lead for synthesis.

The final question is the same as on the rest of this site: did the split create more verified signal than overhead? If the answer is not measurable, collapse the design back into one agent or a simpler workflow.