Parallel Coding Agents Need Handoffs, Not More Terminals

Coding agents working in parallel present challenges that go beyond merely running multiple sessions. Knowing when their work can be safely merged is the hard part. Each session may make independent changes like altering an API, crafting regression tests, or tweaking configuration files. Git worktrees can prevent immediate filesystem clashes, but they don't reveal the underlying task dependencies, assumptions, or alert that two agents are targeting incompatible problem versions.

Developers end up acting as human message buses, manually checking terminals, copying commit IDs, relaying context, and deciding which session should pause. As agents gain more capability, a terminal wall becomes an increasingly ineffective coordination tool.

Claude Code now offers messaging between sessions on the same machine, complete with session discovery, plain-text messages, and a local messaging socket. This exposes background-session states, worktree statuses, pull-request conditions, and a JSON representation for scripts. Hooks allow monitoring tool input and halting calls before they execute.

While this proves the technical feasibility, a new product is still needed to handle handoffs and visibility. The primitives exist, but the workflow problems around dependencies and conflict negotiation remain.

RayTally's Hacker News snapshot from August 9 indicates that cross-session messaging discussions garnered 50 points and 26 comments, ranking 18th in that moment. However, these metrics only reflect historical interest and not actual user adoption or market validation. The envisioned product is not just another chat interface; it's a localized control center.

Each session should declare four key details: its objective, the worktree it occupies, the files it plans to modify, and the outcome another session is awaiting. Upon the API session completing, the test session should receive a concise handoff containing the commit, altered contract, verification target, and any unresolved assumptions.

If the tests cannot start yet, that dependency should be clearly marked as a blocked edge rather than hidden in text. Successful completion should be reflected in a review queue, complete with test output and a diff summary, rather than vanishing into terminal scrollbacks.

The implementation could start with a single developer, one repository, Claude Code, and Git worktrees. A local daemon would read the session list, assign roles via session-start hooks, and compile commits along with test results upon completion. Cross-session messages would transmit only structured handoffs: producer, consumer, dependency, commit, expected behavior, and open questions.

To prevent conflicts, an initial approach would involve advisory file leases. Before any editing tool runs, a hook would verify if another active session has claimed the same file. If so, it would return the owner, task, and suggested actions: wait, negotiate ownership, or work on a distinct file. The first demo should be deliberately modest, involving one session modifying an endpoint, another refining its tests, and a third adjusting shared configuration.

The product will be considered successful if the developer can identify the dependency, transfer the API result once, and catch any shared-file collisions before the review stage.

An open-source local dashboard presents an obvious distribution mechanism, while hosted features, custom coordination rules, and team permissions can be added later. However, the core product needs to demonstrate that explicit dependencies and reviewable handoffs actually save time compared to the time they consume. Advisory file leases, while simple, are not without issues.

Two agents could safely edit different sections of a single file, while changes across different files might still conflict semantically. Strict blocking could hamper parallel progress; loose warnings might be disregarded. Generated files, renames, and formatter passes further complicate ownership. Ultimately, the reliability of a coordination layer hinges on maintaining up-to-date state.

If a session crashes, shifts tasks, or operates outside its declared boundaries, the board may appear orderly while the repository reality is different. Developers may simply disregard the tool after a few false blocks. It's possible that a straightforward convention using worktrees and handoff files could be just as effective and more transparent.

The key question for developers is: when running coding agents in parallel, which stage fails first—transferring context, tracking dependencies, or detecting overlapping edits—and what evidence would persuade them that a coordination layer is worthwhile?