Coding agent orchestration for a software team

Plan around dependencies before assigning agents

Imagine two engineers maintaining an application. They want to fix a search filter, update a payment SDK, and document a new account setting. This is an illustrative work plan. The search fix and SDK update can start separately if they use independent environments. The documentation task needs the setting's behavior confirmed before someone writes instructions for customers.

Give the search fix to one session and the SDK update to another. Put an engineer on each as the decision owner. Keep the documentation in a waiting state with a named dependency. Launching it early would produce assumptions that a reviewer later has to remove.

A task boundary should describe an outcome a reviewer can accept. Splitting by frontend and backend can work when an interface is already agreed. If the interface is still in question, have one investigation settle it before parallel implementation begins.

Give each session a useful brief

The search task needs a reproduction, expected behavior, and a limit on scope. An instruction such as "fix search" leaves the agent to invent those details. A brief can be short and still make the acceptance decision clear:

The status filter is lost when a user opens page 2 of search results.
Reproduce with status=active and at least two pages of fixture results.
Keep the chosen status when changing pages and when using Back.
Preserve the existing search API.
Add regression coverage for URL state and the browser interaction.
Return the diff, checks run, and any checks you could not complete.

Include links to current repository guidance instead of copying an old setup guide into every prompt. The task brief owns the requested behavior. Repository rules own shared conventions. A skill can own the repeatable investigation procedure. Those sources need different update schedules.

Uno's task-writing guide recommends stating the outcome, relevant context, constraints, and verification. Use separate sessions for independent goals so the work records remain understandable.

Separate execution without losing shared decisions

Independent checkouts keep patches apart. Also check the resources around them: both agents may start a development server on the same port or update the same test database. Give each attempt an environment arrangement that matches the checks it must run. A lightweight unit-test task has different needs from a browser flow with a database.

Shared context should include agreed decisions, such as the supported payment SDK version. Working notes belong to the session that produced them. Promote a note into shared guidance only after someone confirms it applies to the repository. Otherwise an agent's unfinished theory can become another agent's instruction.

When two tasks need the same shared module, resolve ownership before they edit it. You might sequence the work, agree on an interface, or combine the tasks. File isolation prevents accidental overwrites; it cannot decide which competing design the team wants. The parallel coding agents guide covers a more detailed division of work.

Keep steering and decisions in the work record

Suppose the SDK update reveals a removed method. The owner decides to preserve the customer-facing behavior through an adapter. Put that decision in the session, with the interface it applies to. A private message between teammates leaves the agent working from an outdated constraint.

Instruction delivery and completed work are separate events. After changing direction, inspect the agent's response and its final diff. If a task is interrupted, check the existing branch and outputs before starting another session for the same goal. Uno's progress and recovery guide explains these distinctions.

Define who can answer product questions while the main owner is away. That person needs the original acceptance criteria and the latest decision, not a transcript of unrelated tasks. A concise handoff helps keep the queue moving without granting agents authority to resolve a business tradeoff themselves.

Let review capacity limit work in progress

The first engineer can review the search patch while the second checks the SDK update. Starting several more implementation sessions at that moment creates a review queue. Set a work-in-progress limit the team can actually support, then adjust it using observed reviewer time.

Ask every session for evidence that fits its task. The search result should show the filter surviving pagination and Back navigation. The SDK update should show the relevant payment behavior still works. A large list of unrelated green checks makes either result harder to assess.

Review a proposed patch against the brief before merging. When a dependent change lands, update the remaining branch and rerun checks affected by that change. Two patches tested independently can conflict in behavior even when Git merges their files cleanly.

Improve the workflow from the work you accepted

Track how many started tasks reached acceptance, how long they waited for review, and where a person had to intervene. Include rejected attempts in cost calculations. Note the reason for rework: missing context, inadequate verification, overlapping scope, or an implementation error each calls for a different fix.

At the end of the trial, change one part of the process. If setup repeatedly fails, fix the environment. If reviewers keep asking the same question, add it to the task brief or evidence requirements. Increase concurrency after the existing tasks produce results your team can review without reconstructing the work.