Two agents can shorten a task only if their work can be checked and combined. Before opening another tab, define each result, checkout, and reviewer. Then inspect attention, running services, and the final diff as the work moves through the project.
Give each agent a different deliverable
Imagine a settings form that fails after an API timeout. Agent A owns the form's retry behavior on a feature branch. Agent B investigates the API failure path and reports a testable finding without editing Agent A's form files. A person owns the acceptance decision: a failed save shows an error and allows retry, a successful retry persists after reload, and existing profile data remains unchanged. If both agents need to redesign the same API contract, pause the second job until that decision has one owner. Two sessions that race to change the same behavior usually add review work rather than parallel progress.
| Owner | Checkout | Output | Stop point |
|---|---|---|---|
| Agent A | feature/settings-retry worktree | Form fix and focused UI test | Show running retry flow and diff |
| Agent B | Separate investigation checkout | Cited API finding and failing-path test idea | Report evidence before changing shared API code |
| Human reviewer | Final integration branch or PR | Accepted behavior and merge decision | Check latest diff, tests, and live result |
Check the real checkout before either agent edits
Open a separate Git worktree and branch for each independent code change. Git's worktree manual defines these as separate working directories attached to the same repository; a second terminal tab alone does not isolate files. In Canopy, confirm the project component, working directory, and branch for each session before sending the task. If a session is read-only, say that explicitly. Worktrees prevent accidental overwrites in one working directory, but they do not prevent conflicting decisions or a later merge conflict. Use the worktree guide for exact setup and cleanup commands.
Separate communication from authority
Canopy's current-main documentation describes supported shared project context and direct agent messages. Use them to pass a bounded fact, such as 'the API returns 409 when the token expired' or 'I changed only the retry state in Form.tsx.' Verify delivery in the exact CLI and release you use; the agent integration audit shows that resume, events, context, and attribution differ across CLIs. A message does not merge the agents' private conversations, change their branches, or grant a teammate another provider's model account. Keep the task brief and acceptance criteria in a place both sessions can inspect.
Watch attention and services while they work
When several sessions are live, check which one is actually waiting for a decision, which one is running a command, and which one has finished. Match the prompt to the project, branch, and last output before replying. If both worktrees run a website, assign distinct ports and identify the preview URL for each checkout; a successful browser tab pointing at the wrong branch is misleading evidence. Canopy's Agents rail and Servers/Preview surfaces help connect those signals, but a status badge alone does not prove the app behavior is correct.
Integrate once, then review the combined result
Open each agent's workspace to inspect its files, commits, diff, and PR context. Bring the investigation finding to the implementation owner; decide whether it requires another focused change. Merge or cherry-pick through your normal Git process only after the branches are stable. Run the settings success and timeout/retry paths against the integrated checkout, then inspect the latest diff and checks. Worktree isolation is an editing boundary, not a proof that the combined product works. Resolve overlapping edits by intended behavior, not by accepting whichever conflict side is easier.
Use model choice to support the jobs
A smaller model may be enough to classify an error or gather a bounded codebase finding. A stronger model or separate reviewer may help with a risky implementation, but compare completed outcomes rather than assuming one route is cheaper. Each CLI chooses its own model and retains its own account and limits; Canopy can display supported usage signals but does not pool billing. Record attempts, human review time, and accepted result if you want to judge whether two agents improved the workflow.
Copyable resources
Two-agent task board
Fill this before launching the second session; use one card per independent output.
Shared acceptance: [observable success and error paths]
Agent A: [output], [checkout/branch], [files or behavior owned], [stop point]
Agent B: [output], [checkout/branch], [read-only or edit scope], [stop point]
Shared API or design decision owner: [person]
Service and preview for each checkout: [command, port, URL]
Attention check: [project, branch, exact question, next owner]
Integration order: [ ]
Final evidence: [combined diff], [tests with results], [running success/error paths], [PR decision]Frequently asked questions
Can two agents edit the same repository?
Yes, but isolated Git worktrees are the safer choice for independent code changes. Review file claims and the final integration before merging.
Can agents use different models?
Supported CLIs can run in separate sessions and each CLI controls its own model selection. Canopy shows supported usage signals together; it does not route or bill models itself.