Upfront Conflict Zone Detection

Pillar: scope-overlap-detection | Date: May 2026
Scope: Static and dynamic analysis techniques for predicting whether two agents' intended changes will overlap BEFORE they start work: file dependency graphs, call graph analysis, module boundary inference, package/import graph overlap, change blast radius estimation, semantic similarity of task descriptions, and ownership map lookup as a pre-flight check.
Sources: 32 gathered, consolidated, synthesized.

Table of Contents

1. Conflict Taxonomy and the Pre-Flight Imperative
2. Static Analysis for Semantic Conflict Detection
3. Call Graph Analysis and Program Slicing
4. Import and Package Dependency Graph Construction
5. Blast Radius Estimation
6. Tree-Sitter and AST-Level Symbol Detection
7. Code Ownership Maps as Pre-Flight Checks
8. Semantic Similarity of Task Descriptions
9. ML-Based Conflict Prediction
10. Production Concurrent Edit Detection Systems
11. Detection Method Comparison and Selection Guide
12. Identified Gaps and Open Problems

Section 1: Conflict Taxonomy and the Pre-Flight Imperative

Two structurally distinct conflict classes appear consistently across the literature, and any pre-flight detection system must handle both. Direct conflicts arise from concurrent changes to the same file, function, or line — detectable via file-level overlap in O(n) time. Indirect conflicts arise when changes to different code areas interact through logical or semantic dependencies: one agent changes an API that another agent's code depends on, even when there is zero textual overlap between their changes.^[8][19]

The Two Conflict Classes

Key finding: "The earlier a conflict is detected, the easier it is to resolve." The Palantír workspace awareness system (IEEE TSE 2012) demonstrated experimentally that users given real-time workspace awareness detected conflicts earlier, resolved a larger number of conflicts, and self-coordinated more effectively than control groups without such signals.^[8][19]

The Pre-Flight Imperative: Why Detection Must Precede Work

Simple file overlap detection catches only direct conflicts. Call graph and dependency graph traversal are required for indirect conflict detection. Both layers are necessary for a complete pre-flight check.^[8] In multi-agent coding practice, the pattern that mitigates the most conflicts is a mandatory plan approval before implementation workflow: agents write plans specifying files they intend to modify, a lead reviews for overlap, and then approves or rejects before any code is written — catching collision at the intent layer rather than the diff layer.^[30]

Push vs. Pull Architecture for Workspace Awareness

Traditional version control is pull-based: agents learn of others' changes only when they perform their own VCS operations. Palantír inverts this to push-based: continuously sharing workspace events across all agents, yielding "a more complete, accurate, and up-to-date picture of parallel activity."^[8][19] The incremental query only requests events relevant to artifacts present in the local workspace, avoiding information overload.

For indirect conflict awareness specifically, Palantír transmits API differences of ongoing changes across workspaces. Each workspace uses a local cache of dependencies to calculate the impact of remote API changes and determines if local changes create new indirect conflicts — moving detection from merge-time to work-time.^[8] Mapped to AI agents: each agent is a "workspace," and the coordinator monitors API changes across agent worktrees.

Section 2: Static Analysis for Semantic Conflict Detection

Standard textual merge tools fail on a specific class of integration failures: "textual merge tools aren't able to detect incompatible changes that occur in areas of the code separated by at least a single line."^[1][12] Merged code may compile successfully but exhibit unintended runtime behavior due to unintended interference between concurrent changes — what the literature terms dynamic semantic conflicts.

Four Core Static Analysis Algorithms

A technique evaluated on 99 experimental units from 54 merge scenarios across 39 projects analyzes merged code annotated with developer-specific metadata using four lightweight static analyses:^[1][12][22]

Evaluation Results

The technique significantly outperforms dynamic analysis in recall (0.60 vs. 0.14) while running 2–3 orders of magnitude faster than prior information flow approaches.^[1]

False Positive and False Negative Breakdown

Key finding: The authors recommend combining static analysis with refactoring detection tools to reduce false positives. The approach shows particular promise when computational efficiency is critical — 17.8-second median execution time makes it viable as a pre-dispatch pre-flight gate.^[1][22]

Pre-Flight Application

The data flow and confluence analyses can be applied to target code regions before agents start work by annotating planned modification zones with agent metadata, then running the four analyses against the current codebase. If DF or CF paths connect the two planned modification zones, conflict is predicted before any agent writes a single line.^[22]

Section 3: Call Graph Analysis and Program Slicing

Call Graph-Based Impact Analysis

A large-scale empirical study (Musco, Monperrus, Preux, Software Quality Journal 2017) evaluated four call graph construction algorithms across 10 open-source Java projects with approximately 17,000 mutants.^[2][13][23]

Four Call Graph Algorithm Comparison

Key finding: "The most basic call graph gives the best trade-off between precision and recall for impact prediction." Counterintuitively, increased graph sophistication improves completeness but not overall effectiveness — more edges increase recall at the cost of precision (more false positives in conflict prediction).^[2][23]

Practical implication for agent conflict detection: simple CHA-level call graph traversal from target files outward provides a reliable blast radius estimate. The transitive closure of the call graph defines the set of potentially impacted files/functions. The intersection of two agents' transitive closures defines the predicted conflict zone. Teams should start with CHA rather than investing in expensive whole-program pointer analysis.^[23]

Static vs. Dynamic Call Graphs

For pre-flight conflict detection, static call graphs are the only option — dynamic graphs require execution that hasn't happened yet. Static over-approximation is acceptable because false-positive conflicts (flagging safe pairs as risky) are preferable to false-negative conflicts (missing real collisions).^[13]

Program Slicing for Blast Radius Prediction

Program slicing computes the set of statements that may affect values at a point of interest.^[5] Two directions are relevant:

Pre-flight conflict detection using slices:^[5]

1. Identify statements/variables being changed by each agent (from task description or plan)
2. Compute forward slice from those statements
3. Map slice to files — these are the blast radius files
4. Compare slices across parallel agents: overlapping slices = high conflict probability; disjoint slices = safe to parallelize

NS-Slicer: ML-Based Predictive Slicing

NS-Slicer uses pre-trained language models (GraphCodeBERT, CodeBERT) for static program slicing, achieving F1-score of 97.41% for backward slices and 95.82% for forward slices on partial code — useful specifically for in-progress agent tasks where full context is unavailable.^[5]

Multi-Granularity Impact Analysis

The Affected Slice Graph (ASG) metric — Affected Component Coupling (ACC) — directly ranks conflict risk: higher ACC values correspond to higher fault-proneness in the affected component.^[5]

Section 4: Import and Package Dependency Graph Construction

Python Import Graph Construction: Hudson River Trading Case Study

Hudson River Trading (HRT) built a complete import dependency graph for a Python codebase of millions of lines to address "code tangling" — overlapping dependency cycles causing more than 30-second import overhead.^[11]

Application to agent conflict detection:^[11]

• Graph query before dispatch: "What modules does file X import? What modules import file X?"
• Transitive blast radius: transitive closure of edges defines true blast radius
• Overlap = conflict risk: Agent A touches module M; Agent B touches a module that imports M → indirect conflict
• Layered DAG as conflict boundary: modules on different layers of a directed acyclic graph are guaranteed non-conflicting
• Import graphs can be computed in parallel across thousands of modules using standard tools — fast enough for pre-dispatch checks

Module Boundary Enforcement Tools in Monorepos

In monorepos without enforced boundaries, any library can import from any other: "Changes in one package can ripple across dozens or even hundreds of interconnected modules."^[14]

Key finding: Re-exports introduce implicit dependencies — downstream code becomes coupled to the transitive closure of a library. Changes in any modules a library depends on require rebuilding dependent apps, making re-export chains a multiplier on blast radius.^[14]

CodeRAG: Multi-Language Dependency Graph via Tree-Sitter + Neo4j

CodeRAG builds dependency graphs using Tree-Sitter for LLM-based code querying, storing relationships in Neo4j for graph traversal queries across the full dependency structure.^[9][26]

The combination of vector similarity (semantic overlap) and graph traversal (structural overlap) provides two complementary conflict signals.^[9] Language support covers JavaScript, TypeScript, JSX, TSX, and Python; extensible to 100+ languages via the Tree-Sitter grammar ecosystem.^[26]

Polyglot Dependency Graph Mining: Algorithmic Complexity Comparison

An ecosystem-agnostic framework for detecting dependency conflicts in heterogeneous development environments provides complexity benchmarks for choosing the right algorithm at different stages of a pre-flight pipeline.^[20]

Graph embedding approaches use Node2Vec and GraphSAGE models to encode structural and contextual features into vector spaces; supervised classifiers trained on known conflict instances predict probable future conflicts, with risk scores correlated against Git version histories.^[20]

Section 5: Blast Radius Estimation

Blast radius in software engineering is "the potential impact that a change or failure in a system or service can have on other interconnected systems or services."^[7][17] It has two components: direct impact (systems immediately affected) and indirect impact (systems affected as a result of disruption to directly impacted systems). Factors influencing blast radius size include system complexity, interconnectivity level, nature of the change (interface changes carry larger blast radius than implementation-only changes), and system resilience.^[7]

Converting Conflict Detection to a Graph Intersection Problem

The pre-flight blast radius approach converts conflict detection into a computationally tractable form:^[7][17]

1. Build a dependency graph of all files in the codebase
2. For each proposed agent change, compute the set of directly and transitively affected files
3. Compare blast radius sets across concurrently running agents
4. Any intersection indicates a conflict risk zone requiring coordination

Dependency Map Analysis Techniques

AI-Powered Blast Radius: Port AI Pipeline

Port's AI calculates blast radius pre-deployment through a five-step pipeline:^[7][17]

1. Identify the changed service/module
2. Traverse dependency graph to find all downstream consumers
3. Score risk based on number of affected services and their criticality
4. Notify downstream team owners proactively
5. Generate rollback readiness signals

Blast-Radius.dev: PR-Level Detection Pipeline

The blast-radius.dev tool implemented a dedicated PR-level detection pipeline:^[24]

Adoption warning: The blast-radius.dev project is no longer active. The creator concluded that while the cross-service impact problem exists, "teams didn't prioritize this type of analysis at the time" — establishing an adoption barrier despite technical soundness.^[24] This contrasts sharply with Microsoft's ConE (Section 10), which achieved 90%+ user retention, suggesting that internal mandated tooling succeeds where voluntary external tooling does not.

Augment Code: Multi-Source Dependency Mapping at Scale

Augment Code's AI-powered microservices impact analysis integrates four primary data sources to capture hidden dependencies invisible to static analysis alone:^[25]

Scale: Context Engine processes 400,000+ file codebases without chunking, using models supporting 128,000 tokens of context; rebuilds dependency model within seconds of a branch push.^[25] Reported result: teams report up to 70% reduction in impact analysis time.^[25]

Blast Radius Minimization Patterns (Applicable to Agent Work Partitioning)

Key finding: Testing overly large blast radii leads to bloated, inefficient test suites that provide little real feedback. Test architecture should match decoupled software architecture — and agent task partitioning should match both.^[7]

Section 6: Tree-Sitter and AST-Level Symbol Detection

Tree-sitter is a parser generator and incremental parsing library that builds concrete syntax trees (CSTs) with full source fidelity. Its key property for conflict detection is incremental parsing: sharing unmodified tree nodes between versions enables fast re-parse when code changes (enabling source parsing on every keystroke in editors), making it viable as a live pre-flight analysis layer.^[6][16]

Tree-Sitter Capabilities Relevant to Conflict Detection

Critical limitation: Building dependency graphs with Tree-Sitter requires language-specific work — developers must write language-specific queries producing common captures, or hand-write AST traversers per language.^[6][16]

AFT: Semantic Code Operations for AI Agents

The AFT toolkit (cortexkit) is built on top of Tree-Sitter's CSTs. Every operation addresses code by what it is — function, class, call site, symbol — not by where it sits in a file.^[16] This directly addresses the root cause of line-number-based conflicts: "AI coding agents are fast, but their interaction with code is often blunt. The typical pattern: read an entire file to find one function, construct a diff from memory, apply it by line number — burning tokens on context noise, with edits that break when the file changes."^[6]

Import Graph Construction via Tree-Sitter

The AST-based import graph construction pipeline:^[16]

1. Parse each file with Tree-Sitter
2. Traverse AST with DFS, extract import_statement / import_declaration nodes
3. Store imports as directed edges: file → imported_file
4. Result: complete import dependency graph

"AST beats regex": early approaches used pattern matching on source text; Tree-Sitter gives the real dependency graph, not approximations that fail on multi-line imports, aliased imports, or conditional imports.^[16]

Symbol-Level Concurrent Edit Safety

AST-level conflict detection mechanism:^[6]

• All edits applied bottom-up to avoid offset recalculation from prior edits
• Multiple tree.edit calls before reparsing; incremental parsing produces updated AST
• When two edits target the same named symbol from different agents, conflicts become detectable at the semantic level, not raw line offsets

Two-agent symbol conflict check: Both agents query the same dependency graph to check for overlapping symbols. If both plan to modify the same function or class, conflict is detected pre-flight. Symbol-based locking reduces false positive conflict rates compared to file-based locking.^[6]

Architecture Anti-Patterns as High-Risk Zones

Architecture analyzers built on Tree-Sitter AST detect these patterns, which indicate zones of elevated parallel agent conflict risk:^[16]

Key finding: Symbol-level locking (AFT's approach) reduces false-positive conflict rates compared to file-level locking because two agents can safely edit different functions in the same file. File-level locks block this safe parallelism unnecessarily.^[6][16]

Section 7: Code Ownership Maps as Pre-Flight Checks

Ownership maps provide a lightweight O(1)-per-agent-pair pre-flight check that catches the most common single-file edit collisions before any dependency graph analysis is required. Files with a single clear owner can be claimed exclusively; files with shared or disputed ownership are higher-risk zones warranting deeper analysis.^[3][29][15]

Ownership Computation Methods

Critical divergence finding: Only 0–40% of developers are commonly identified by both methods across studied systems. Correlation between methods ranges from 0.24–0.65. Importantly, 79% of individual code owners were NOT among the top 100 most frequent committers — significant divergence between declared and contribution-based ownership.^[3][29]

CODEOWNERS Files: Declared Ownership Infrastructure

CODEOWNERS is a configuration file mapping files/folders to responsible owners (teams or individuals). When a pull request touches those paths, GitHub/GitLab automatically requests review from listed owners.^[15] It encodes four types of organizational information:^[15]

• Organizational structure
• Communication structure
• Trust boundaries
• Technical domain ownership

CODEOWNERS Conflict Detection Mechanism

"In larger projects with multiple codeowners, merge conflicts can arise when different codeowners make changes to the same file simultaneously." Overlapping ownership rules lead to conflicts.^[15]

Pre-flight ownership check procedure (O(1) per agent pair):^[3][29][15]

1. Parse CODEOWNERS file (or infer from git history commit frequency)
2. For each agent task description, determine target files
3. Check if multiple agents target files with the same owner
4. Flag ownership conflicts before dispatching agents

Ownership Quality Metrics (Codigy)

Key finding: High minor-contributor count correlates with higher defect rates, and making changes to a depending component without coordinating with the owner increases likelihood of faults.^[29] This extends directly to AI agents: agents assigned to files without clear ownership incur significantly higher conflict risk.

CODEOWNERS + SAST Integration

GitHub/GitLab CODEOWNERS integrates with Static Analysis Security Testing (SAST) triage by mapping ownership to file structures — automatically assigning suppression ownership. The same mechanism is applicable to conflict triage: file → owner → responsible agent → automatic conflict escalation routing.^[29]

Section 8: Semantic Similarity of Task Descriptions

Dependency graph analysis detects structural overlap; semantic similarity analysis detects intent overlap — two agents heading toward the same logical territory even when their initial file lists don't yet intersect. These are complementary signals: high semantic similarity without file overlap may indicate hidden future conflict; file overlap without semantic similarity may be incidental co-location rather than true conflict.

S3CDA: Two-Phase Semantic Conflict Detection

S3CDA (Supervised Semantic Similarity-based Conflict Detection Algorithm) was designed to automatically detect conflicts in software requirements — directly mappable to detecting when two AI agents have overlapping task intents.^[4][32]

Phase I: Similarity-Based Candidate Identification

Similarity formula: cos(r₁,r₂) = r₁·r₂ / (‖r₁‖ ‖r₂‖), ranging from -1 (dissimilar) to 1 (identical). Optimal thresholds determined via ROC curves per dataset.^[32]

Phase II: Entity Overlap Validation

High-similarity candidate pairs enter Phase II for entity extraction and overlap ratio calculation:^[32]

Overlap ratio computed against m=5 most similar candidates; if ratio exceeds threshold T₀=1.0, pair enters the final conflict set.^[32]

S3CDA Evaluation Results

LLM comparison: S3CDA consistently outperforms GPT-4o, Llama-3, Sonnet-3.5, and Gemini-1.5 in domain-specific settings. LLMs show promise on general datasets but fall short in specialized domains.^[4][32] For high-recall requirements, the unsupervised variant UnSupCDA achieves 100% recall across most datasets at the cost of lower precision.^[32]

Applying S3CDA to Agent Task Conflict Detection

Direct mapping to coding agent tasks:^[32]

1. Phase I: Encode agent task descriptions as SBERT vectors; compute cosine similarity — high similarity suggests potentially conflicting intent
2. Phase II: Extract entities from task descriptions:
   • Files/modules mentioned (object)
   • Functions/classes targeted (object)
   • Operations planned (action: refactor, delete, update, add)
   • Agent identity (actor)

This provides a lightweight, fast pre-flight screen before any dependency graph analysis — task description similarity check can run in milliseconds and serves as a Layer 0 gate before triggering more expensive structural analysis.^[32]

Semantic Consensus Framework (SCF): Production Multi-Agent Systems

Production multi-agent LLM systems show failure rates between 41–86.7%, with nearly 79% of failures originating from specification and coordination issues — not model capability limitations. The root cause is Semantic Intent Divergence: cooperating LLM agents develop inconsistent interpretations of shared objectives due to siloed context.^[18][28]

SCF Six Components

SCF Three Conflict Categories

SCF Evaluation Results (600 runs across AutoGen, CrewAI, LangGraph)

SCF also defines a Semantic Alignment Score (SAS) per agent pair, combining: (1) overlap between each agent's entity state model, (2) consistency of planned actions with the process model's valid transitions, and (3) divergence between agent confidence levels and historical base rates. SAS provides a scalar conflict risk indicator that complements the binary conflict categories.^[28]

Key finding: The 65.2% detection rate at 27.9% precision for purely semantic (task-description-level) conflict detection establishes the baseline for the semantic layer alone. Combining semantic intent analysis with dependency graph analysis should significantly improve both numbers — the two methods are orthogonal and complementary.^[28]

Section 9: ML-Based Conflict Prediction

Social + Technical Features from Git History

A large-scale study (Springer Empirical Software Engineering) evaluated machine learning on git history features for binary merge conflict prediction across 744 open-source GitHub repositories across 7 programming languages — described as the largest merge conflict prediction study to date.^[21]

Feature Categories

Model Performance

Class imbalance note: Merge conflict data from git history is highly imbalanced (far more non-conflicting merges). Handling requires SMOTE, Random Forest ensemble, or class-weighted training.^[21]

MergeBERT: Neural Transformer for Conflict Resolution

A neural program merge framework based on token-level three-way differencing and a multi-input BERT variant:^[21]

• Trained on 220,000 real-world historical merge conflicts from 100,000 GitHub repositories
• Languages: JavaScript, TypeScript, Java, C#
• Precision and accuracy: always over 60% (over 70% with top-three suggestions)

Facebook's Predictive Test Selection: ML + Build Dependency Graphs at Scale

Facebook developed a ML system shifting from "which tests could be affected" to "what's the probability a test will catch a regression?"^[31]

Production results: Detects 99.9% of regressions while running only 1/3 of all dependent tests; requires 95%+ prediction accuracy; achieved 2x testing infrastructure efficiency gains.^[31]

Key finding: Facebook's approach is directly transferable to pre-flight conflict prediction: instead of predicting test failure probability, predict conflict probability for two agent task pairs. Features: build dependency graph distance between target files, commit co-change history, owner overlap, semantic similarity. Training data: historical parallel development sessions where conflicts occurred vs. not. Facebook's results demonstrate this pattern is production-proven at massive scale.^[31]

RIPPLE: Intent-Aware Change Impact (ICSE 2026)

RIPPLE ("From Seed to Scope: Reasoning to Identify Change Impact Sets," Yadavally and Nguyen, ICSE 2026) addresses the precision-recall tradeoff in change impact analysis with a two-phase design.^[27]

RIPPLE Evaluation Results

Application to multi-agent pre-flight:^[27]

1. Given two agent task descriptions (natural language), use RIPPLE Phase 1 to expand from seed to full affected file/function set for each agent
2. Compute the intersection of two expanded impact sets
3. Non-empty intersection = predicted conflict zone

RIPPLE's key bridge: natural language intent → dependence-expanded impact set transforms task descriptions into concrete file sets comparable before any agent starts working.^[27]

Section 10: Production Concurrent Edit Detection Systems

ConE: Microsoft's Concurrent Edit Detection at Scale

ConE is a production-deployed concurrent edit detection service at Microsoft (ACM TOSEM 2022), deployed March 2020 onwards across 234 repositories.^[10]

Empirical foundation: Files concurrently edited in different pull requests are more likely to introduce bugs — established from half a year of changes across 6 large Microsoft repositories, each with 1,000+ monthly PRs.^[10]

ConE Core Metrics

ConE Deployment Results

Key finding: ConE deliberately avoids deep semantic analysis in favor of fast, scalable overlap estimation — and this is presented as the right tradeoff, not a limitation. Production validation at 70%+ usefulness confirms file-overlap-based conflict prediction is practically valuable at scale, without requiring call graph traversal or semantic analysis.^[10]

ConE Key Insights for Agent Conflict Detection

Adoption: ConE vs. Blast-Radius.dev

The contrast suggests that deployment model (mandated internal integration vs. voluntary external tool) determines adoption success more than technical merit for conflict detection tooling.^[10][24]

Palantír: Push-Based Workspace Awareness (Foundational Reference)

Palantír (2012, IEEE TSE) remains the foundational reference for real-time parallel development conflict detection. Its push-based workspace awareness architecture — where API diffs are transmitted across workspaces as work progresses — directly models the architecture needed for multi-agent pre-flight systems.^[8][19]

2025–2026 Multi-Agent Industry Practice

By end of 2025, approximately 85% of developers regularly used AI tools for coding, still mostly single-agent; multi-agent coordination became the new frontier in early 2026.^[30] The key upfront conflict-detection pattern that emerged in this period is mandatory plan approval before implementation: agents write plans specifying files they intend to modify, a lead agent reviews for overlap, and approves or rejects before any code is written — catching collision at the intent layer rather than the diff layer.^[30]

Section 11: Detection Method Comparison and Selection Guide

No single technique covers the full conflict space. A complete pre-flight system is a layered pipeline where cheap, fast techniques filter the candidate space before expensive, precise techniques are applied only to flagged pairs.

Method Comparison Matrix

Recommended Layered Pre-Flight Pipeline

Section 12: Identified Gaps and Open Problems

Known Gaps in the Literature

Key finding: The field has strong theoretical foundations and production-proven components (ConE, Palantír, S3CDA, RIPPLE) but lacks end-to-end evaluation of any layered pre-flight pipeline specifically designed for AI agent systems. The biggest open problem is not technique efficacy — it is integration: combining semantic, structural, and historical signals into a single sub-second gate without creating a bottleneck that eliminates the velocity gains from parallelism.^[10][28][27]

Home