The problem
Running several coding agents at once is easy. Integrating what they produce is not: two changes that each pass their own tests can still break each other once merged. Most multi-agent setups either avoid parallelism or leave integration to a human.
SEAM (Software Engineering Agent Merge) treats integration as the core problem. Every design decision names the constraint it serves: preventing conflicts, serializing merges, keeping review independent, or keeping execution safe.
How it works
- A lead plans. A goal becomes typed tasks, each with a declared file scope, a contract and its own test command. The lead can be a hand-written plan or an LLM planner that reads the repository in a sandbox.
- Disjoint claims prevent most conflicts. No two in-flight tasks may hold overlapping file scopes; an atomic claim in the task store enforces it. A worker that needs more files must ask, and the lead re-checks disjointness before granting.
- Each task runs in its own git worktree, in a Docker container with no network access except a credential proxy that holds the real API key, so a worker never sees a credential and cannot exfiltrate the repository.
- An independent review gate. Deterministic checks first (reviewer is not the author, every change inside the declared scope, the task's tests green in the sandbox), then an LLM reviewer judges the diff against the spec, not against the worker's claims.
- One merge at a time. The merge engine is a single global slot: each approved branch merges onto the current main and the full test suite runs on the merged tree before main moves. The merge commit is recorded first, so a crash mid-merge never leaves main half-updated.
- Semantic conflicts go to a human. If the merged tree fails the suite with no textual conflict, the task escalates instead of being auto-resolved. A human rules on it from the CLI or, through an MCP server, from Claude Code or Claude Desktop.
Results so far
All single runs on repositories and goals I chose, so these are data points, not rates:
- Toy repo, disjoint tasks: both merged, zero human touch, two workers in parallel.
- Toy repo, semantic conflict: caught by the merge-time full suite and escalated; main never broke.
- boltons (a real Python library), 8 independent features: 8/8 merged, full suite green, about $0.67 of model usage.
- boltons, 5 dependent tasks: 5/5 merged in order; the reviewer rejected two real bugs, both fixed on retry.
- LLM-planned runs: the planner produced sound plans and every task merged, but behavioral probes run afterwards still found test-passing defects on main.
What I learned
"Merged" is not "correct". The weakest link is review: a single LLM review let significant, test-passing bugs through about half the time. So runs are now also measured for silent defects, with behavioral probes written before the run, next to the merged and escalated counts. Escalation rate alone would have made every run look perfect.
Constraints beat cleverness. Preventing conflicts with disjoint file scopes kept almost every merge trivial; there is no clever semantic merger, and there shouldn't be. When the merged tree breaks, a human decides.
SEAM is written in Python with SQLite as the task store, Docker for sandboxing, and Claude Code as the default worker runtime behind a pluggable interface. It was built in collaboration with Claude Code.