Conflict Detection and Resolution
Learn how to detect when two agents have produced incompatible outputs and pick the right resolution strategy — last-writer-wins, merge, escalate, or replay — based on the cost of being wrong.
Conflict Detection and Resolution
When two agents touch the same state, a conflict is the difference between two outputs that cannot both be applied. Detecting the conflict is mostly mechanical (version mismatch, merge marker, contradictory tool calls); resolving it is a design choice that depends on blast radius.
Detection mechanisms
| Layer | Detection mechanism | Example |
| --- | --- | --- |
| Filesystem / VCS | Three-way merge fails or produces a marker | Two agents edit the same lines of app.py |
| HTTP API | ETag / If-Match / version field | 412 Precondition Failed from a REST PATCH |
| Database | Optimistic row version, unique constraints | UPDATE … WHERE version = ? returns 0 rows |
| Semantic | A validator or critic agent catches contradictions | Two agents add rules that mutually disable a feature |
Without a detection mechanism, conflicts become silent corruption. Always identify the mechanism before designing the resolution.
Resolution strategies — pick by blast radius
| Strategy | When to use | When it bites you | | --- | --- | --- | | Last-writer-wins | Idempotent state, low-blast files (logs, caches) | Business-logic files where the loser's intent vanishes | | Optimistic retry | API calls behind ETag / version | The conflict is semantic, not just stale-state | | Auto-merge | Disjoint textual edits with a clean three-way merge | Changes that compile but contradict each other | | Escalate to human | Irreversible, high-cost, or semantically ambiguous changes | Reviewer fatigue if you escalate everything | | Escalate to supervisor agent | Mid-blast and you can codify the policy | The supervisor itself can be wrong; needs its own guardrails |
Exam tip: The right strategy follows the cost of being wrong. The exam loves scenarios where the wrong default (usually last-writer-wins or naive auto-merge) is the most tempting answer.
Pick the strategy
Resolve the conflict
Two agents have both opened PRs that edit the same line of a feature-flag config file. One enables the new checkout flow for all users; the other enables it only for 5% of traffic. Both PRs pass CI.
Where this shows up on the exam
GH-600 conflict questions almost always pit a tempting auto-resolution against a more conservative escalation. The decision tree the exam rewards: detection mechanism present? → strategy matches blast radius? → human in the loop for irreversible changes?
Key terms
- Conflict
- Two or more agent outputs that cannot both be applied to the shared state without one overwriting or contradicting the other.
- Optimistic concurrency
- Agents proceed in parallel and conflicts are detected at commit time via version checks (e.g., ETag, head SHA); one writer wins and the other must retry.
- Merge resolution
- Both agents' outputs are combined — automatically (three-way merge) or by a third agent / human — to preserve the intent of each.
- Escalation
- The conflict is handed up to a supervisor agent or a human reviewer because it is semantic, irreversible, or above an autonomy threshold.
Common pitfalls
- Defaulting to last-writer-wins on a file that encodes business logic — the loser's edit silently disappears and no one notices.
- Auto-merging changes that only look textually compatible (e.g., two configs that both compile but contradict each other semantically).
- Treating a 409 conflict response as a transient error and retrying without re-fetching state — the second attempt races the same way.
- Escalating every conflict to a human; reviewers stop reading and rubber-stamp.