naw103

I run about 45 scheduled agents for marketing and engineering across multiple products. Most of them are not always-on, they are scheduled jobs. Some run mornings,some hourly. That covers most of what I wanted from always on and many of them have some type of event listener that can trigger a run as needed (like background research on a client signup).

The part that took the work was shared state. We used GPTree for the knowledge engine. Every routine reads and writes from the same knowledge and anything public or high risk gets an approval card to continue.

We use GPTree to manage context across all our chats and coding agents using the graft extension on local machines. This allows us to use several different model families through Claude, cursor and codex without having to copy paste everywhere. It allows all out agents to run on the same context tree and company documents.

I read only a small part of what agents write now, mainly risky chunks after 3 review passes by different model families. Reading everything dosnt scale. I think a lot of it comes down to the confidence you have in the development procedures for the agents, the system architecture of what they are changing and the review procedure.

Make sure to keep the reasons where the agent can see them. Without the reason for a decision the agent can find the old approach in a doc or blog post somewhere and will keep referencing it because nothing told it why it chnaged. I keep all decisions with the reason and the date together and weekly prune as well as adding to the doc.

The thing that didn’t get cheaper for me was conversion. I run a few small products alone with agents doing a lot of the work. We had a big spike of free signups that retained better than I expected. Getting them to pay was still the struggle, mostly with onboarding and people not finding the features. We had to have real conversations with our users to be able to fix that.

Im the author. Foremerge is an MCP coordination protocol for coding agents working in parallel across multiple worktrees on the same source.

Each agent commits its intent and scope prior to changing any file so plans that collide show up as findings before code is changed rather that in merge conflicts later. Like git for before code is written. It's open source and saves a ton of headaches and time resolving conflicts later even if your agents do it for you.

Happy to answer any questions about the stopped agent tests or the migration change.

At least fix the docs that say v3 gets security fixes

If 10 minutes is becoming 2 hours it’s hard to believe that time is being saved using AI but the first question I would ask is what business impact did it have fixing those bugs? I’m guessing probably very little since they were 3 years old.

One trap when you name AI bots specifically is that is that robots.txt groups don’t merge. Crawlers will only follow the most specific group so if GPT bot has its own group named nothing under User-agent: * applies to it anymore so you need to repeat every disallowed line under each group.

The same approach worked for us with agent runs. We gave them fewer tools up front and let the models just pull what they need

Only routine sessions right now since I didn’t want to delete anything where I had replies without a manual review but it could be easily forked and modified for all sessions

The planner file is intentionally non destructive so you can run it to preview everything first

I think Foremerge would be extremely useful in your setup especially with 25 agents running in parallel. While aoe manages the physical layout and terminal communication (ie. spawning sessions, executing commands, wrappting tmux etc.), Foremerge would act as your logical synchronization layer that prevents the agents from stepping on each others toes. They should complement each other really well. do you know what causes the coordinator agent to intrude right now? is it both plans being on the blackboard or is it being triggered by diffs or failing merges?

I feel like every time I launch a new feature in GPTree one of these big players follows up with the same functionality within a few weeks :-(

https://gp-tree.com/enterprise

Our developer docs for GPTree knowledge engine here https://gp-tree.com/docs/knowledge-api

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?

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.

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)

There were several comments here that got marked dead but had some legitimate points and questions so answering them on gh discussions instead https://github.com/naw103/foremerge/discussions/32 laika23 asked for two kinds of conflicts: replace vs extend and contract change by one agent vs new agents writing against the old contract. The first case already exists today and the second will also catch if the agent declares it but currently today no rule evaluates the dependancies at acceptance unless it is specifically declared as a check. We already added to the roadmap from initial feedback to solve this through a treesitter code graph. We've measured it internally but havnt build it yet. One thing that we found while measuring this was that only edges the parser extracted are usable and the ones it had to guess were name collisions on common helper names.

You might be surprised, it works exceptionally well. If you decide to give it a shot and run into any issue feel free to reach out to me with any feedback.

... and Jev is a sore point for me right now lol we have been training our own decision intelligence model, Corgen, for the last year and a half. We're already using it in GPTree but havn't released it to the public yet. Im actually in the process of running it against JevBench right now to see how it stacks up.

Here are some questions I normally get asked:

What does an agent do with it? The agents publish intents and scopes of what they are about to change (at the start and right before they make the change if its something different). Foremerge returns a signal of related work already in progress on different worktrees (even across different branches or in the same worktree) and the agents/humans who are working on it. Agents can then negotiate on the solution prior to writing any code or generating any conflicts and Foremerge runs an acceptance check (defined by a human) prior to commit.

Why advisory claims instead of locks? Once a repo gets busy locks turn into a queue and deadlocks. A lock that the agent cant see the reason for is the worse case scenario so the hard gate is at the acceptance not the start.

What are the gaps? Ultimately Foremerge is deterministic (does not use any judge model) so it can detect some false positives and negatives though we see that very infrequently and worst case it would have likely of been missed anyway without Foremerge. Acceptance also dosnt currently compare the actual diff by default and there are no push notificiations so the earlier agent only learns about the conflict on its next status check (both of these are on the roadmap for the next version)

There are more questions and answers here: https://foremerge.com/blog/31-questions-coordinating-paralle...

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)

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

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.

We built our own model router at GPTree but this looks interesting. Caching is definitely one of the hardest parts to get right, especially in our scenario where users can branch from any part of the conversation and keep the dynamic context from the parent (unlike most other platforms that lock in the context once you branch).