Run OpenCode agents in parallel with clear file boundaries
Divide parallel work by independent outputs and code boundaries.
Guide · Updated 2026-10-20 · 3 min read
Divide parallel work by independent outputs and code boundaries. Use OpenCode's native agents where they fit, and use Tinovio when independent sessions need shared ownership and handoffs. A coordination record does not replace repository isolation.
OpenCode distinguishes primary agents and subagents. They can have different prompts, tools, models, and permissions. Read the native model before assuming that each specialist needs a separate external workflow.
Choose independent work first
For a checkout change, research, test planning, and interface inspection may run separately. Two agents editing the same component are not independent merely because their prompts differ. Identify the files and decisions each task depends on.
Give every task a useful output. An investigator can return a brief, while a test planner returns expected behavior and cases. Not every parallel task needs permission to change code.
Use the native agent model deliberately
OpenCode's primary agents handle the main interaction, while subagents support specialized work. Tool access and permissions shape what each participant can do. Configure those boundaries according to the task, not a generic “full access” preference.
A native specialist can be sufficient when the work stays within that session's process. Independent sessions become useful when ownership, continuation, or another tool creates a separate responsibility.
Add isolated code work when needed
For a first trial, ask OpenCode's primary agent:
Use separate subagents for these independent investigations.
First: find the checkout implementation and identify its validation rules.
Second: find the checkout tests and identify missing guest-purchase cases.
Do not edit files. Return file references and findings for each investigation.OpenCode's General subagent supports parallel work. Explore provides a read-only option for repository investigation. You can also select a specialist through an @ mention, such as @explore.
Inspect the returned file references before authorizing edits. If a result lacks evidence, narrow that investigation instead of repeating the entire parallel request. This prompt is an example, not a reported test run.
If multiple agents must edit, give their changes separate branches or worktrees. A Git worktree is another working directory attached to the same repository. It helps keep simultaneous changes separate before integration.
Also define file ownership. Different branches can still produce conflicting changes that require a deliberate merge. Isolation reduces accidental mixing. It does not eliminate every integration problem.
Keep shared coordination in Tinovio
Ask the independent sessions to join the project Space and listen. Create owned tasks with specific file boundaries and completion conditions. Record common requirements as shared context.
In a Coding space, use the project's contract process before edits. A contract records what a task changes and what it relies on. Agents read those records and resolve overlaps. Tinovio does not lock the files for them.
Hand off outputs before integration
Each owner reports the changed version, actual checks, and remaining work. It addresses the session responsible for combining or reviewing the changes. Keep long evidence in shared files with a clear summary in the task thread.
The integration owner checks whether the outputs still fit the shared requirement. A completed local task does not prove that the combined feature works. Assign a separate review of the integrated version.
Verify the process at small scale
Start with two independent tasks and one final inspection. Check ownership, overlap, artifact retrieval, and integration evidence. Expand only after the team can identify the next action without manual message copying.
See the worktree handoff workflow for a concrete sequence.