Uncoordinated coding agents can turn a small change into conflicting patches and a longer review queue. A multi-agent system in software engineering coordinates distinct agent contexts toward a shared change, using explicit ownership, returned artifacts and verification to decide what proceeds.
Start with one coding agent and add delegation when a task needs separate context, independently testable work or a focused reviewer. Agentic coding describes a tool-using process that can inspect, edit and test code; it can use one agent or several. Multi-agent orchestration adds decisions about who does which work, what each worker may change, and how the combined result is accepted. This guide supplies a pattern matrix and a handoff example for engineering leads changing their SDLC.
Separate work environments still need a shared integration decision. Plan the handoffs before multiplying the workers.
Choose a pattern from the dependency graph
Use a fixed sequence when the next task depends on the previous artifact. Use parallel workers when their inputs are available and their changes can be validated independently. If investigation determines the subtasks, let a planner propose the decomposition, then check ownership before work begins.
Anthropic's Building effective agents distinguishes predefined workflows from model-directed agents and describes chaining, parallelization, orchestrator-workers and evaluator-optimizer patterns. These describe control flow; they do not establish that more agents improve a particular repository's delivery.
| Pattern | Choose it when | Dominant failure mode & prevention |
|---|---|---|
| PatternSingle agent with tools | Choose it when A bounded change fits one context and one owner. | Dominant failure mode & prevention Missed repository constraints: provide acceptance criteria and require test evidence. |
| PatternFixed chain | Choose it when A validated requirement must precede design, implementation or migration planning. | Dominant failure mode & prevention A bad intermediate artifact propagates: validate each handoff before the next stage. |
| PatternParallel specialists | Choose it when Independent changes or read-only investigations can start from the same baseline. | Dominant failure mode & prevention Conflicting assumptions or edits: agree interfaces, isolate writes and retest the integrated result. |
| PatternPlanner and workers | Choose it when The changed components emerge during investigation. | Dominant failure mode & prevention Duplicate work or missing dependencies: inspect the proposed task graph and assign a final integrator. |
| PatternEvaluator and implementer | Choose it when A clear criterion lets feedback improve a candidate patch. | Dominant failure mode & prevention Circular approval or endless revisions: require executable checks, a stopping budget and an escalation owner. |
These patterns can be combined. A planner can identify independent workers and send their results through a fixed integration gate. A reviewer may inspect code without receiving permission to edit it.
Proposed parallel implementation flow. The integrator tests the combined patch; passing checks on each branch does not establish that both changes work together.
A useful decision boundary is whether each task can pass its acceptance criteria without waiting for another worker's unfinished change. If it cannot, complete the shared dependency first or keep that portion serial. Different file paths alone do not prove independence: two workers can disagree about the same API contract without editing the same file.
VS Code's two-task delegation guide makes task briefs, separate worktrees and combined retesting explicit. It also warns that a worktree isolates working files, not access to the machine or external services. Treat tool credentials, network access and deployment authority as separate controls.
Make the handoff an inspectable record
Give a worker enough information to return a reviewable artifact. A useful handoff identifies the baseline, allowed changes, observable outcome and unresolved decisions. A chat transcript alone is difficult for an integrator to audit after several workers finish.
VS Code's subagent documentation describes separate contexts returning focused results and emphasizes that invocation and configuration depend on the harness. Do not assume every subagent inherits the full conversation or supports the same follow-up behavior.
The following filled record is a hypothetical authentication change, not a completed project:
| Handoff field | Example record |
|---|---|
| Handoff fieldOutcome and baseline | Example record On the recorded base commit, expired credentials must return the existing unauthenticated response. Save the exact commit hash in the task record. |
| Handoff fieldOwnership | Example record Worker A changes the token parser and its unit tests. Worker B changes the independent sign-in help text and its view test. The integrator owns shared contracts. |
| Handoff fieldInterface and exclusions | Example record Preserve the response schema; do not change refresh behavior, dependencies, database schema or deployment configuration. Escalate if the fix requires those changes. |
| Handoff fieldAcceptance evidence | Example record Return the changed-file list, patch or commit, commands run, exit status and relevant test output. State skipped or failing checks explicitly. |
| Handoff fieldReturn and stop | Example record Return unresolved assumptions and side effects. Stop on a shared-contract conflict or exhausted iteration budget; the named maintainer decides the next step. |
For this example, the parser and copy changes may run together only after confirming that the copy test does not depend on a new parser response. If both require a new response field, design that contract first. The worker's permission to propose a change does not give it authority to approve or release it.
Keep repository content and external tool output in their evidence role. Instructions found in an issue, dependency document or fetched page should not expand a worker's allowed actions. Scope credentials to the task and keep production release authority with its designated owner.
Rebuild the SDLC around artifacts and decisions
An AI-native SDLC needs a record of validated intent that survives the move from planning to coding and operations. Adding a reviewer after a large patch arrives leaves earlier architectural assumptions unchecked.
AWS's AI-DLC methodology proposes Inception, Construction and Operations, with AI-generated plans, clarifications and human validation. It describes storing requirements, plans and design artifacts in the repository for continuity. That is a process proposal, not a universal productivity result.
A proposed checkpoint design for the SDLC. The named owners accept decisions; an agent-produced artifact is input to a gate, not evidence that the gate passed.
| Stage | Artifact to retain | Acceptance decision |
|---|---|---|
| StageIntent and design | Artifact to retain Requirement, acceptance examples, relevant constraints and design rationale. | Acceptance decision Product and engineering owners resolve ambiguity and accept the proposed boundaries. |
| StageConstruction | Artifact to retain Task graph, owned patches, test output and unresolved assumptions. | Acceptance decision Integrator checks contracts and runs relevant checks on the combined revision. |
| StageRelease and operations | Artifact to retain Approved revision, deployment plan, monitoring signals and rollback procedure. | Acceptance decision Release owner authorizes the actual target and checks operational readiness; a coding worker does not self-promote its patch. |
Keep decisions attached to a revision. If integration changes an interface, invalidate evidence that depended on the old interface and rerun the affected checks. Preserve the reason for a rejected design so that a later worker does not repeat it. An automated code review can help locate defects; it cannot by itself establish authorization, complete requirement coverage or a successful production rollout.
Budget coordination before increasing concurrency
Compare elapsed time and total effort separately. For independent tasks starting together, a simple planning model is:
Parallel elapsed time = planning + longest worker duration + integration + verification
Serial elapsed time = planning + sum of worker durations + integration + verification
For assumed inputs of 10 minutes planning, two 30-minute tasks, 15 minutes integration and 20 minutes verification, parallel elapsed time is 10 + 30 + 15 + 20 = 75 minutes; serial elapsed time is 10 + 60 + 15 + 20 = 105 minutes. The illustrative reduction is 105 - 75 = 30 minutes. This assumes identical integration and verification effort and no resource contention. It is scheduling arithmetic, not a measured agent speedup.
If coordination or rework grows by more than that 30-minute margin, this example loses its elapsed-time advantage. Parallel workers may also consume more model usage even when the wait becomes shorter. Track these costs over the same delivery period:
| Cost or outcome | Record on the same scope |
|---|---|
| Cost or outcomeModel and execution usage | Record on the same scope Planner, worker and reviewer usage, including retries and discarded branches; retain model/harness versions. |
| Cost or outcomeHuman effort | Record on the same scope Briefing, review, conflict resolution and defect rework, in person-hours. Do not add concurrent worker minutes to wall-clock time. |
| Cost or outcomeDelivery outcome | Record on the same scope Accepted changes, elapsed time to acceptance and defects found after integration. Compare changes of similar risk and size. |
| Cost or outcomeOperating overhead | Record on the same scope Sandbox provisioning, dependency setup, storage and maintenance of test/evaluation infrastructure. |
Use the measured queue and rework data to choose the next experiment. For a tiny edit, delegation can cost more than it saves. For a tightly coupled change, a single owner with read-only specialist advice may preserve the context better than parallel implementation.
Follow the four summit records with a specific question
The AI software development topic collects the broader discussion. These existing records connect the architecture choices to the assigned summit sessions; each record links to its original publisher video and timestamps. Treat session examples as context for investigation, not a controlled comparison of coding assistants.
- Four Agent Workflows Compared Live: Multi-Agent Patterns at Build 2026: use the original demonstration to examine how a brief becomes separate work, and what an integrator would need returned.
- Where Agentic Coding Actually Breaks: Russinovich and Hanselman at Build 2026: use the record's verification discussion to challenge what counts as completion in your acceptance criteria.
- The AI-driven development lifecycle session at AWS re:Invent 2025: compare the lifecycle discussion with the planning, construction and operations artifacts above.
- The Ericsson AI-native SDLC record at AWS re:Invent 2025: examine the organizational handoffs and ownership questions before assuming a tooling purchase changes the process.
Method, sources and corrections
Compiled from primary engineering documentation retrieved 19 October 2026. The pattern taxonomy comes from Anthropic's architecture essay, published 19 December 2024; its current page warns that tooling has since changed. The VS Code guides were checked in their current form, with 14 October 2026 page dates. AWS supplies the lifecycle methodology. The handoff, checkpoint design and arithmetic here are editorial planning aids, with hypothetical inputs wherever numbers appear.
The four talk pages are existing, AI-assisted source records with their own verification states. This guide adds no independent performance measurement or new session-date claims. Recheck current harness documentation before choosing permissions or configuration.
Report a correction with the disputed passage, primary source/date, harness version and relevant task or test evidence, excluding secrets and private code. Our methodology explains source handling. Use the topic page to continue to the underlying talk records.