I encountered similar issues before I built Foremerge, ie auto router, orchestrater and shared blackboard type memory structure. The agents were aware of what was put into memory but still did their own thing and created conflicts. I still see it in claude code today when it creates subagents without Foremerge setup for the project. It resolves itself but you can see it burning through token usage to do so. If your using a single agent you dont necessarily need Foremerge but it still helps when subagents get created automatically and gives you the audit trail of intent decisions essentially at almost zero cost of having the tool installed. Where Foremerge really shines is if you bounce back and forth between claude and codex with no single parent. I dont know Weave well enough to know where it sits. The question I'd ask about any of them is what happens if you kill it? If the agents stop then it's an orchastrator, if the agents continue and you just loosed the shared picture then its a coordinator like Foremerge.

How many sessions do you typically run at once and are they all children of the same parent?

I think before AI was writing most of the code and with small teams the solution was probably just ownership and talking (and meetings about meetings). Things moved at a pace where it was more possible to have someone oversee this, though I agree on larger teams it has always been a problem. I think Foremerge solves that too even without agents but the manual overhead outweighs more of the cost that it does with agents. Even if you can use AI to resolve the conflicts at PR time, you need the right context and you've already burned through tokens building and now even more fixing. Scale that across 10's or 100's of agents and you have a mess of each one running in its own direction. The custom solution for us became one worktree per task, and before an agent writes a line of code they lease/commit their intent and scope into an immutable log and verify drift as the acceptance check...thats now Foremerge

We’ve been taking a different path to this author, albeit to solve a similar problem. Rather than thinking agents diminish the value of code ownership, we think it stays level or potentially increases. To that end, teams are responsible for managing the agent model, harness, instructions, local skills or other config for their areas. When work needs to be done across areas we allow it, but via an orchestration layer where agents operate via adversarial negotiation, with escalations and explanations to engineers when decisions are hard to make.

We find giving the agents independent remits makes them significantly better at challenging problematic requirements, because they aren’t all automatically aligned on the same goals.

The agents from each area then having queues and messaging subsystems to coordinate their work when there are multiple streams happening, although concurrency is less of an issue than we expected. Generally will detect and flag competing requirements, which has saved us from some subtle issues. We don’t always require code owners to review every PR in their area, but they do at least always have a log of what work was done and why, which is separate from the noise of the parent work.

This does all work out a bit slower than just letting each agent get on with its job, but it’s working pretty well for us.

You're right when the agent starts with a plan and no file list and the files only exist after edit, but the way I designed Foremerge to work, it works anyway. The initial intent does not have to be complete, it just has to be right about any destructive parts. That is why Foremerge works by declaring intent as prose, not as a file list or methods. The agents them selves determine if something conflicts based on the signals Foremerge returns. It only asserts a HIGH warning on declared scope and only a HIGH signal blocks acceptance (to avoid false possitives based on prose alone). The declaration can change at any point and the auto installed skills into the agents encourage such (the initial intent is released by the agent and the new intent is committed)

Thanks! It' become a critical part of our development flow at GPTree since I built it back in Jan. So much so thats the reason I decided to open source it. I don't neccessarily see it as a replacement for version control, the diff is still doing most of the work at the point that really matters but Foremerge prevents those conflicts before you get to that point. Declared intent is what the agent thinks it will do and the diff is what it actually did, and the changeset being accepted currently depends on that diff. Where I definitely agree with you though is that not human or agent should be discovering a conflict by finding it in a diff. Its too late by that point and its the layer that git dosnt solve.

It dosnt stop an agent, claims are advisory. I mostly answered this in my comment of questions that I normally get asked above. The only hard stop is at acceptance, and only for HIGH signals. HIGH is reserved for something the toll can state as fact rather than guess about. ie. both agents declared the same scope and one agent destroys (replace, rename, remove) the thing the other agent is building on (extend, modify). Whether an overlap is fine is a judgement that Foremerge dosnt make itself and thats by design. The agents are smart enough and determine this themselves after receiving the advisory. For a HIGH signal the agents coordinate through messages and either agent resolves it with a logged rationale that unblocks it for both (a human can override it with a logged reason too). The idea is that every path out leaves a decision log behind so later you can see not just that two plans overlapped but what was decided and why. (I think this has a good compliance angle to it as well)

Thats exactly what we've seen using this in our development workflows at GPTree since Jan and why we opensourced it. I really think this becomes an essential new part of the dev stack as coding with multiple agents in parallel increases even more. What I cant count right now is the rework a missed one costs because that dosnt surface until a fix commit possibly days later and thats the measurement Im trying to find a clever way to get. Worse case is though that you would still have that conflict even without using Foremerge. The difference is how much trust you can put in the final code.