Technical guide
Multi-Agent Software Engineering Before the Pull Request
How task claims, append-only coordination events, replica convergence, and pre-PR observability expose duplicate and conflicting work among coding agents.
Direct answer
Direct answer: Multi-agent software engineering
Pull requests reveal the final code but hide much of the cost of concurrent coding agents: repeated discovery, duplicate implementation, conflicting edits, abandoned branches, lock starvation, and races to declare completion. A useful multi-agent engineering system records task claims and append-only coordination events before the pull request, allows replicas to reconcile deterministically, and measures useful throughput rather than raw agent activity.
Written for Developer-tool teams, engineering leaders, coding-agent builders, distributed-systems practitioners, and researchers studying AI-assisted software delivery.
The operating principles
Coordinate before code review
Agents need a shared protocol for claiming, splitting, yielding, blocking, and completing work before their edits collide in a pull request.
Use append-only evidence
Immutable coordination events preserve intent and sequence, making duplicate discovery and conflicting ownership measurable after replicas reconnect.
Design for divergent replicas
Disconnected or delayed agents will observe different histories. The protocol must converge without silently discarding a valid write.
Measure useful throughput
Commits, tokens, and tasks closed reward motion. Useful throughput discounts duplicate and conflicting work and includes the cost of reconciliation.
Keep humans able to inspect the protocol
A git-native or otherwise ordinary event trail lets engineers review coordination failures without a proprietary observability stack.
What supports this view
Before the Pull Request
In the measured setup, duplicate or conflicting rework fell from 78% to 0%, useful throughput more than tripled, and the append-only log converged without silently dropped writes.
Inspect the source ↗grite
A git-native coordination implementation accompanying the paper and released corpus.
Inspect the source ↗grite corpus
The released artefacts support inspection of coordination traces and the measured setup.
Inspect the source ↗Scope and limitations
- The controlled results do not establish that every coding team or agent framework will achieve the same improvement.
- Coordination overhead can exceed its value for very small, independent, or short-lived tasks.
- A convergent event log does not make the underlying code correct; testing and review remain separate obligations.
Common questions
Why are pull requests insufficient for observing coding-agent work?
They capture proposed code after substantial work has happened. They usually omit repeated discovery, abandoned attempts, duplicate task ownership, and coordination messages that explain why the work became expensive.
What is a task claim in multi-agent coding?
A task claim is an explicit, time-bounded coordination event stating that an agent intends to work on a defined scope. It reduces accidental duplication without requiring a permanent central lock.
What should multi-agent engineering teams measure?
Useful completed work, duplicate and conflicting effort, claim wait time, reconciliation cost, abandoned work, human interventions, and whether every valid coordination event survives convergence.
Does more agent activity mean more engineering throughput?
No. Parallel activity can increase duplication and conflict. Throughput should count useful, integrated work after subtracting the effort needed to resolve overlap and errors.