Series II: From infrastructure to agentic projects in production. Episode 09 of 20.
In the previous episode, we chose where a coding agent works: IDE, terminal, or cloud. Now we must decide how many agents work on the same change and who integrates the results. Running multiple sessions at once may look like a shortcut, but two changes that work separately may be incompatible together. For an SME, the practical choice is to start with one agent and add parallel work only when tasks have clear boundaries and a common integration point.
Start with a verifiable change
Consider a hypothetical scenario from this series’ B2B portal for requests and documents. After adding PDF upload validation, the team wants a workflow in which an employee approves a document and the customer sees its status. The change spans the API contract, state logic, interface, tests, and error messages. It is not a real client project or result.
One agent can implement an initial version on a separate branch. It receives acceptance criteria, repository rules, and the test commands described in the previous episode on preparing the code. The team evaluates the diff, tests, and remaining questions. If the task fits in an easy-to-follow context, there is no need for an automated coordinator or parallel sessions.
When is dividing the work worthwhile?
Separation becomes useful when one part can be described and verified without constantly waiting for another. In our example, the team first defines the contract between API and interface: status values, error responses, and transition rules. Only then can agent A implement server-side logic while agent B builds the interface against the same contract. Integration tests check whether their assumptions meet.
This is sequential execution followed by parallel work. A shared step resolves the dependency, after which relatively independent parts move at the same time. A human or software coordinator distributes tasks and synthesizes results; this activity is called orchestration. The coordinator is not necessarily the final code approver. If one change touches the same functions, database schema, or business rules as another, working sequentially or redefining the task boundaries is safer.
Research on multiple agents shows that isolation and structured integration can help in certain software engineering evaluations, but published results do not guarantee gains for our portal. Even an industrial example of multi-agent research warns that coding often has fewer truly parallel tasks than research. The useful measure is accepted work, not the number of agents started.
Separate workspaces, shared contract
In Git, a branch is a line of changes starting from a base revision. A worktree is an additional working directory linked to the same repository, allowing multiple branches to be used at once without agents writing into the same copy of the files. An isolated cloud environment may provide similar separation, depending on the platform.
In our example, each agent starts from the same known commit and gets its own branch and workspace. A temporarily owns the state-logic files, and B owns interface components. “Ownership” is a coordination responsibility, not a restriction guaranteed by Git: an agent can edit other files if it has permission. Instructions should require it to stop and report when a needed change falls within the other agent’s area.
Physical isolation prevents accidental overwrites in a shared directory, but does not resolve semantic conflicts. Two branches can merge without a textual conflict even though one changes the meaning of a field used by the other. Do not copy credentials into worktrees just to run tests; use synthetic data and the minimum necessary access under project rules.
Handoff means more than “done”
A handoff passes a result between agents or to the integration owner. Require the same short report for each task:
- Objective, base commit, branch, and changed files.
- Implemented behaviour and covered acceptance criteria.
- Commands run and their outcomes, including failed or unrun tests.
- Assumptions about the shared contract, changes outside the assigned area, and observed risks.
- Open questions and steps needed for integration or rollback.
The report alone is insufficient evidence. The integration owner reads the actual diff, runs checks on the combined code, and compares behaviour with the requirement. If agent B assumed a status named “approved” while the API returns “accepted”, resolve the mismatch before merging rather than concealing it with a superficial test change.
Who integrates and who approves?
Assign one owner for technical integration, usually a developer or a supervised coordinating agent. That owner sets the branch order, resolves conflicts, and reruns tests after each relevant integration. A passing check on branch A and another on branch B do not automatically mean that A+B works.
A pull request is a reviewed request to integrate code; it keeps the diff and discussion together. Branch protection can require review and automated checks before merging. A person designated by the team accepts the final behaviour and remaining risk. Agents can propose code, tests, and observations, but this does not make them the owners of the release decision.
Keep a stop condition: if two tasks start editing the same contract or integrated tests fail, pause parallel work, update the specification, and restart from a shared base. Avoid resolving conflicts automatically merely to obtain a mergeable commit.
A selection rule for tomorrow
For every change, record dependencies and the person who accepts the result. Use one agent when the problem has one outcome and tightly coupled changes. Add a second agent for a part with a stable interface, separate workspace, and its own tests. Introduce explicit coordination when several deliverables must be combined, rather than simply because the tool can launch more sessions.
Compare time to an accepted change, integration interventions, regressions, and resource use with a single-agent approach on similar tasks. The output of this episode is a handoff contract and an integration rule that the team can add to the repository. The next episode will address what information can persist and be shared across sessions, with provenance and access limits.
Here we discuss agents developing the portal. An agent embedded in the portal to process customer documents has a different identity, data, and approvals; it does not automatically get access to the repository or the development team’s tools.
Sources
- Anthropic, Building effective agents, 19 December 2024, for delegation patterns and the simplicity principle; the article itself notes that the tooling landscape has since changed.
- Anthropic, How we built our multi-agent research system, 13 June 2025, for coordination costs and the limits of transferring research findings to coding.
- Git, git-worktree documentation and GitHub Docs, protected branches, for workspaces and integration checks.
- Geng and Neubig, Effective Strategies for Asynchronous Software Engineering Agents, arXiv, revision of 8 July 2026, for an evaluation of isolation, delegation, and integration; its findings apply to the studied tasks.
Want to define agent tasks and retain control over code integration? Talk to the i8 team.
