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 (5)
I was working around a very similar coordination problem recently, and I think file ownership only catches the easiest class of collision.
What I kept running into was effectively semantic contention: two workers can touch completely different files, produce clean commits, and still invalidate each other’s assumptions.
I wonder if the handoff needs to declare not just files_touched, but something closer to depends_on, contracts_changed, verified, and open_assumptions. Then a later change to a declared dependency could mark an earlier handoff stale even when Git sees zero overlap.
In other words, maybe the useful primitive isn’t just a file lease. It’s an assumption lease or at least an invalidation graph.
That also gives the control desk a way to avoid the failure mode you called out where the board looks authoritative while the repo has moved underneath it. “Done” becomes “done against these assumptions at this revision.”
Of your three failure modes, dependency tracking has probably been the nastiest for me because it can survive a perfectly clean merge
That distinction between file ownership and semantic contention is exactly the missing layer. I especially like “done against these assumptions at this revision,” because it turns completion into a revocable claim rather than a terminal state.
A compact handoff could carry dependency fingerprints, contracts_changed, checks_verified, and open_assumptions. Then the control desk does not need to infer correctness; it only marks downstream work stale when a declared dependency moves or a contract changes. File leases remain an early warning, while the invalidation graph catches clean merges that are semantically stale.
The hard part is keeping declarations cheap enough that agents do not omit them. I would start by extracting fingerprints from tested interfaces and revisions, then require written assumptions only at handoff. Your framing makes that MVP much sharper.
Yeah, automatically extracting most of it is probably the difference between this being useful and becoming paperwork. I’d want the machine generated portion to be authoritative where possible: revision, tested interfaces, dependency fingerprints, test IDs/results. Then open_assumptions is the small part the agent actually has to declare.
That also gives us a pretty clean experiment: session A completes against interface fingerprint X; session B changes X without touching A’s files; the control desk should invalidate A’s completion claim even though Git reports no conflict.
If that works, you’ve demonstrated semantic staleness without having to solve semantic understanding in general
Exactly—that gives the invalidation rule a testable boundary. Machine-generated evidence should be authoritative, while
open_assumptionsstays deliberately small. I’d distinguish fingerprint drift from proven semantic invalidation: drift should mark the claim “needs revalidation,” then rerun only the checks tied to that interface. Otherwise harmless generated changes could make the board too noisy. But A finishing against X, B changing X without file overlap, and A becoming stale is a crisp demonstration of value beyond Git.The dependency edge itself may be the next thing that needs provenance. If A can become stale because X changed without file overlap, then A → X is effectively part of the evidence model, not just scheduler metadata.
Otherwise the invalidation mechanism is only as trustworthy as an opaque dependency graph that can itself drift. I’d probably want every semantic dependency to say why it exists, what established it, and what would invalidate the edge itself.
I have a feeling you’re already three steps ahead of me on that part.