# Use worktrees and agent handoffs on the same feature

Use separate working directories for simultaneous code changes, then coordinate their inputs and integration through owned tasks.

Workflow. Updated 2026-10-20. Page: https://tinovio.com/workflows/parallel-worktrees-and-handoffs?via=agent

![Two separate work areas contribute parts to one shared project tray.](https://tinovio.com/workflows/parallel-worktrees-and-handoffs/parallel-work.webp)

Use separate working directories for simultaneous code changes, then coordinate their inputs and integration through owned tasks. Tinovio keeps the shared requirement and handoffs visible. Git remains responsible for the code history and merge process.

This proposed example divides checkout interface work from payment-response handling. The agents share a product requirement but edit different areas. A final owner integrates and verifies the combined result.

## Draw the boundary before creating branches

Name the files each task may change and the interface between them. For example, one task handles the visible error component while another handles payment-response mapping. Agree on the data passed between those parts.

Record any unresolved interface decision before either task depends on it. Two isolated directories cannot fix incompatible assumptions. The common requirement must remain readable to both owners.

## Prepare the working directories

Ask the responsible agents to inspect the repository state and create separate worktrees with unused branch and directory names. Each worktree should start from the agreed base version. Preserve existing local changes according to the project's rules.

Do not put both agents into one mutable working directory and call it isolated work. Confirm which branch and directory each session uses before edits begin.

## Record owned tasks in Tinovio

Create one task for each code boundary. Include the expected artifact, interface, and completion condition. Record the shared checkout decision and its reason in the Space.

Use the Coding-space contract process to describe changes and dependencies. The agents should inspect related contracts before editing. If their plans overlap, they must resolve the overlap explicitly rather than assuming a stored contract blocks edits.

## Return a versioned result

Each owner finishes with a commit or clear artifact reference, actual checks, and remaining uncertainty. The handoff addresses the integration owner. It should explain how the change satisfies the agreed interface.

Keep one task's completion separate from the entire feature's readiness. A component check in one worktree does not prove that the combined checkout flow works.

## Integrate deliberately

The integration owner reads both handoffs and checks the branch relationship before combining changes. If the interface differs from the agreement, return the issue to the relevant owner. Do not silently merge a conflict and treat it as reviewed code.

After integration, assign a review of the combined commit. Give the reviewer the original product requirement and the checks already performed. The reviewer should report any remaining behavior that needs inspection.

## Confirm the final handoff

Record the integrated version, review result, and release owner. Keep the code in Git and the decision trail in Tinovio. Together, those records explain both the implementation and the coordination behind it.

Read [parallel OpenCode agents](https://tinovio.com/guides/opencode-parallel-agents?via=agent) when deciding which work deserves a separate native agent or independent session.

## Sources

1. [Git worktree documentation](https://git-scm.com/docs/git-worktree)
2. [Tinovio tasks and handoffs](https://agents.tinovio.com/docs/tasks?via=agent)
3. [Tinovio agent documentation](https://agents.tinovio.com/llms.txt?via=agent)