Parallel Agents Without a Shared Checkout

OpenResearch makes parallel agent work a repository problem before it makes it a model problem. This chapter focuses on how a local dashboard, a chat session, a private Git worktree, a harness process, and an experiment branch fit together. The practical judgment is simple: isolation should prevent agents from overwriting one another, while shared history should let a research team discover what has been tried. OpenResearch achieves that balance by isolating sessions at the checkout level without turning each session into an unrelated copy of the project.

That distinction matters because “parallel” can mean two very different things. It can mean several independent researchers exploring different branches, or it can mean several processes editing the same directory at once. The first can increase exploration. The second can make provenance ambiguous even when Git eventually records a commit. OpenResearch is designed for the first arrangement: each chat session gets a place to work, while the project keeps one visible experiment history.

The session boundary is a private worktree

A session starts with local project context, but it does not simply claim the project's main checkout. OpenResearch creates or reuses a private Git worktree for that chat session. The worktree begins detached at a baseline tip so that the baseline branch itself is not claimed by the session; the agent can then check out the experiment branch it is meant to edit. This small detail protects parallelism. If every session checked out the same baseline branch, Git would correctly prevent the second session from using it, but the system would have turned a research workspace into a resource contention point.

The private worktree owns the session's edits and scratch state. A branch checked out there belongs to that session until the work is committed or the session changes to another branch under the project's rules. A second session can work on a different branch at the same time. The result is not merely a convenience for avoiding merge conflicts. It establishes a local answer to the attribution question: which session's edits were present in this branch before it was committed?

The isolation is deliberately narrower than a separate repository clone. Worktrees share the hub repository's object store and refs. A branch created by one session is visible to the other sessions, and a fetch that updates the shared repository can be seen by all of them. This shared history is what makes the sessions collaborators rather than isolated experiments that happen to use similar source. It lets one agent inspect a completed branch, compare it with a parent, or choose it as the basis for a later round.

Shared references do not mean shared files. Git's worktree rules prevent two worktrees from checking out the same branch at the same time. That protection is the interface between discovery and edit ownership. A branch can be visible globally, but its working directory is claimed locally. If two agents need to make co-equal changes, they should have two branches and two worktrees.