Agentic Coding Best Practices for Multi-Agent Development

• Give every unit of work a scope, a done state a script can check, and a named person who accepts it.

• Record decisions in committed files, because an agent's context window does not survive a handoff.

• Run parallel agents in separate git worktrees so two sessions never edit the same file at once.

• Point automated checks at correctness and human reviewers at intent, since a passing test suite cannot prove a change was worth making.

• BAND keeps ownership, handoffs, and approvals in one shared room, so coordination survives a closed coding session.

A vague unit of work produces two agents solving the same problem and nobody solving the third. Most agentic AI coding best practices start at the prompt. Start at the unit instead.

A unit needs three things: a scope, a checkable done state, and a named person who accepts the result. The second is where teams cut corners. Anthropic's Claude Code documentation puts the cost plainly: "Claude stops when the work looks done. Without a check, it can run; 'looks done' is the only signal available, and you become the verification loop: every mistake waits for you to notice it." A test suite, a build exit code, or a linter all close that loop.

In a payments API change, one agent owns the charge endpoint's idempotency key, another the retry handler, a third the webhook signature check. Each unit has a test that proves it works and an engineer responsible for accepting it.

Code review and CI handle part of this well. Neither decides which agent owns a unit, and neither tells you a unit was never picked up.

• Write the acceptance check before you assign the unit.

• Keep one owner per file path throughout the life of a change.

• Plan when the approach is unclear, or the change spans several files. Skip it when you could describe the diff in one sentence.

• Ask for evidence: the command the agent ran and what it returned.

Context is the binding constraint, and it does not travel. The Claude Code documentation is explicit: the context window fills fast, and performance degrades as it fills. A decision from session one is gone by session three unless somebody wrote it down.

Context needs three homes. Rules that apply to every task go in the project instructions file loaded each session. Domain knowledge that applies only sometimes goes in on-demand files. The plan and the reasoning behind it go in a written artifact that outlives the session, so the next agent reads the decision instead of re-deriving it.

The pruning rule runs against instinct. For each line in the instructions file, ask whether removing it would cause mistakes, and cut it if not. Bloated files make the agent ignore the instructions that matter. Tweag's open Agentic Coding Handbook, written by a software engineering firm rather than a tool vendor, lands in the same place: smaller steps, spec-first work, and review discipline.

• Check what actually loaded at session start before blaming the prompt.

• End planning with a spec naming the files, interfaces, and what is out of scope.

• Clear context between units and start the next one in a clean session.

Two agents editing the same file is the first thing that breaks at scale. Most agentic coding workflow best practices assume one session in one working tree, and that assumption breaks down. Four mechanisms handle it, in rising order of setup cost.

Start with isolated checkouts. Git worktrees run separate CLI sessions in isolated git checkouts so edits do not collide - one agent per worktree, one unit per agent.

Then scope by path. When two agents work inside one service, assign directories, because feature boundaries rarely align cleanly with file boundaries. Then keep a record of what is in flight outside the agents, since an agent that cannot see what its peers claimed will claim it again.

Finally, drive fan-out from a written task list. The documented pattern has the model write the list of files needing changes to a file, loop over that list, and refine the prompt on two or three files before running the full set. Claude Code's batch command does the same at a larger scale, splitting a change "across 5 to 30 subagents", each in its own worktree opening a pull request.

• Use one worktree per agent, including for short fixes.

• Assign directories to agents when they share a service.

• Keep the in-flight list outside the agents so nothing is claimed twice.

Review either becomes the bottleneck or quietly disappears, and both look like speed for a few weeks. Separate the check the agent runs from the judgment a person makes, then put the person where the check cannot reach: intent rather than correctness.

An adversarial review step handles the correctness half. Per the Claude Code documentation, "a reviewer running in a fresh subagent context sees only the diff and the criteria you give it, not the reasoning that produced the change, so it evaluates the result on its own terms." It adds the caveat: "a reviewer prompted to find gaps will usually report some, even when the work is sound, because that is what it was asked to do." Tell it to flag only gaps affecting correctness or the stated requirements.

The human half is harder to delegate. On the payments change, the check proves the retry handler is idempotent. A person still decides whether the business wants to retry that charge. For the full taxonomy, see human in the loop for multi-agent systems and human in the loop vs human on the loop.

• Let the automated check gate the agent's stop and the human gate the merge.

• Ask for the test output alongside the diff.

• Require a named approver on changes touching money, identity, or customer data.

The four practices create a coordination problem of their own. Ownership sits in a task file, in-flight work sits with whoever started it, decisions sit in a spec, and approvals sit in a terminal somebody must watch. None of it survives a closed window.

BAND is the communication layer underneath those agents. They join a shared chat room that holds the goal, constraints, owners, and decisions, making the first practice’s scoping visible to every participant. Messages route on mentions, so an agent acts only when addressed, and parallel agents stay off each other's units. Each agent holds a peer identity on the account, so a closed session rebinds to the same peer without creating a new one. Approvals surface in the room, so the fourth practice's decision point lands where the work is.

BAND for coding agents runs this with Claude Code, Codex, and Cursor sessions in one workspace. BAND Desktop for coding agents adds a work board with per-agent swim lanes, built on a chat task API that BAND documents as beta. One limit is worth naming. The BAND platform carries the work, the routing, and the record. It does not verify the change, so the check that tells an agent it is finished is still yours to write.

If more than two coding agents already touch your repository, book a demo and bring the repository.