The concrete problem
Running two or three coding-agent sessions is easy. Knowing when their work is safe to combine is not.
One session changes an API while another writes regression tests against the old shape. A third investigates a production failure and quietly edits the same configuration file. Git worktrees prevent immediate filesystem collisions, but they do not explain task dependencies, transfer assumptions, or warn that two agents are solving incompatible versions of the problem.
The developer becomes a human message bus: checking terminals, copying commit IDs, repeating context, and deciding which session should wait. The more capable each agent becomes, the less useful a wall of terminal panes is as a coordination interface.
The current signal
Claude Code now supports messaging between sessions on the same machine. Its documentation describes session discovery, plain-text messages, and a local messaging socket. Agent view separately exposes background-session state, worktrees, pull-request status, and a JSON listing suitable for scripts. Hooks can observe tool input and block a tool call before execution.
That does not prove demand for a new product. It does create a concrete implementation moment: the primitives for handoffs and visibility exist, while dependency ownership and conflict negotiation remain a workflow problem.
In RayTally's bounded Hacker News snapshot at August 9, 00:33 UTC, the cross-session messaging discussion had 50 points and 26 comments and ranked 18th. Those numbers describe that historical observation only; they are not user counts, market validation, or a prediction of lasting interest.
A product direction: a control desk for handoffs
The useful product is not another chat window. It is a small local control desk that makes each session declare four things: its goal, worktree, files it expects to touch, and the result another session is waiting for.
When the API session finishes, the testing session should receive a compact handoff containing the commit, changed contract, verification target, and unresolved assumptions. If the tests cannot proceed yet, that dependency should be visible as a blocked edge rather than buried in prose. Completed work should land in a review queue with test output and a diff summary, not disappear into a terminal scrollback.
The full RayTally product brief and four-source implementation trail cover the source boundaries, native-feature gap, and business model in more detail.
A minimal entry point
Start with one developer, one repository, Claude Code, and Git worktrees. A local daemon can read the session list, register roles through session-start hooks, and collect commits plus test output when work finishes. Cross-session messages carry only structured handoffs: producer, consumer, dependency, commit, expected behavior, and open question.
For conflict prevention, begin with advisory file leases. Before an editing tool runs, a hook checks whether another active session has declared the same file. If so, it returns the owner, task, and suggested alternatives: wait, negotiate ownership, or work on a different file. Do not attempt automatic merging or function-level locking in the first release.
The first useful demo should be deliberately small: one session changes an endpoint, one updates its tests, and one changes shared configuration. The product succeeds if the developer can see the dependency, transfer the API result once, and catch the shared-file collision before review.
An open-source local dashboard is a natural distribution wedge. Hosted history, cross-device access, custom coordination rules, and team permissions can wait until the local loop proves that it reduces terminal switching and review confusion.
The strongest case against
Claude Code already has agent view, worktrees, and cross-session messaging. A thin dashboard could be absorbed by native features quickly. The product needs to prove that explicit dependencies and reviewable handoffs save more time than they add.
File leases are also blunt. Two agents can safely edit different parts of one file, while changes in different files can still conflict semantically. Strict blocking will serialize useful work; loose warnings will be ignored. Generated files, renames, and formatter passes make ownership even noisier.
There is a deeper reliability problem: coordination state becomes harmful when it is stale. If a session crashes, switches tasks, or edits outside its declaration, the board can look orderly while the repository is not. Developers may simply bypass the tool after a few false blocks. A plain convention using worktrees and handoff files might remain cheaper and more transparent.
Question for readers
When you run coding agents in parallel, what fails first: transferring context, tracking dependencies, or discovering overlapping edits—and what evidence would convince you that a coordination layer is worth keeping?
Top comments (0)