When debugging complex software issues, the challenge isn't just finding relevant code. It's understanding how seemingly unrelated pieces connect to form the complete picture. Traditional retrieval methods treat code as flat text, missing the intricate web of dependencies, calls, and relationships that define real software systems. Kodezi Chronos revolutionizes this with Adaptive Graph-Guided Retrieval (AGR), a dynamic system that thinks about code the way developers do: as an interconnected graph of relationships.

The Fundamental Problem with Flat Retrieval

Consider a typical debugging scenario: a null pointer exception in an authentication module. The error manifests in login.py, but the root cause might lie in:

• A configuration change made three commits ago

• A dependency update in a completely different module

• An edge case in token refresh logic

• A race condition between cache invalidation and user sessions

Traditional vector-based retrieval would search for syntactically similar code snippets, likely missing these crucial connections. Even advanced RAG systems struggle because they lack understanding of code structure and can't dynamically adjust their search depth based on problem complexity.

The illustration below shows why flat retrieval fails while graph-based approaches succeed in tracing actual causality through code.

Figure 1 contrasts how traditional flat retrieval versus AGR approach the same null pointer exception in an authentication module. On the left, Flat Retrieval starts from the NPE location in ExportService, searches for syntactically similar code, and retrieves ExportUtils and ExportController based on text similarity. This completely misses the root cause: a configuration change in AuthService that propagates through TokenCache to cause the null pointer.

On the right, AGR begins from the same NPE location but traverses the actual dependency graph. It follows the call chain backwards through ExportService to AuthService, discovers the configuration change (highlighted in red) that modified cache behavior, and traces how this propagates forward through TokenCache to cause the exception.

AGR retrieves not just similar code but causally connected code. This fundamental difference explains why AGR achieves 87.1% debugging success versus traditional retrieval's 25%: AGR finds causes, not just symptoms.

AGR as a Two-Part System: Retrieval and Reasoning

What makes AGR revolutionary is that it's not just a retrieval mechanism. It's a complete cognitive system with two tightly integrated components.

1. Dynamic Graph Retrieval handles the mechanics of finding relevant code. It builds the code graph from AST, dependencies, and git history, then traverses this graph adaptively. As it explores, it scores each node's relevance and decides whether to expand further or terminate.

2. Attention-Guided Reasoning orchestrates the entire debugging process. It weights nodes by debugging relevance, plans fix structure before generating code, and validates outputs against expected behavior. This isn't passive consumption of retrieved context. It's active reasoning about causality.

The critical innovation: these two systems communicate bidirectionally. Retrieval informs reasoning by providing context. Reasoning guides retrieval by identifying gaps in understanding.

If reasoning determines that current context cannot explain the bug's behavior, it signals retrieval to expand deeper. If retrieval finds causally disconnected code, reasoning filters it out to maintain focus. This tight coupling creates a feedback loop where each system makes the other more effective.

Figure 2 shows how retrieval and reasoning operate as coordinated processes. The left side displays Dynamic Graph Retrieval with its three components: Graph Construction, Adaptive Traversal, and Confidence Scoring. The right side shows Attention-Guided Reasoning with Dynamic Attention, Fix Planning, and Output Validation. The bidirectional arrows between them illustrate the feedback loop that enables adaptive debugging.

The Attention-Guided Reasoner: Beyond Simple Retrieval

Traditional RAG stacks treat retrieval as a preprocessing step. You retrieve once, then generate. Chronos's AGR turns reasoning into a first-class, dynamic orchestration process.

The Attention-Guided Reasoner continuously evaluates what's been retrieved and what's still needed. It reads from the memory graph, but unlike passive retrieval, it actively weights node importance based on debugging context. A function called once might be irrelevant. A function in the error stack trace gets maximum attention.

It tracks dependency chains, understanding that bugs often stem from interactions between components rather than isolated code. And it constructs structured debugging plans before generating any code, preventing the common failure mode where models start writing fixes before understanding the problem.

Figure 3 visualizes attention in action. Three nodes receive different scores: 0.82 for the most relevant code (likely the bug location), 0.57 for moderate relevance (perhaps a dependency), and 0.31 for lower relevance (tangentially related code). These scores update dynamically as AGR gathers more context, concentrating attention on causal chains while downweighting irrelevant branches.

How AGR Transforms Debugging Context Assembly

AGR fundamentally reimagines code retrieval as a graph traversal problem with intelligent, adaptive depth control. Instead of retrieving fixed chunks of similar text, AGR follows a four-step process.

It starts from semantic seed nodes: the initial error location, stack trace elements, or failing test cases. These seeds provide the starting point for traversal.

It expands through typed relationships: following imports, function calls, inheritance chains, and data flows. Not all edges are equal. Direct function calls receive higher priority than distant imports.

It adapts depth based on confidence: Simple bugs might need only direct neighbors (k=1), while complex issues require deep traversal (k=3-5). AGR doesn't blindly expand. It monitors whether additional nodes improve understanding.

It terminates intelligently: stopping when confidence exceeds threshold or diminishing returns are detected. This prevents both premature termination and wasteful over-retrieval.

Figure 4 demonstrates AGR's adaptive depth expansion in action. Starting from the Error node (center), AGR performs k=1 expansion to immediate neighbors, achieving 70% confidence. This proves insufficient, so AGR expands to k=2, pulling in second-degree neighbors and reaching 85% confidence.

Still below the 90% threshold, AGR expands to k=3, incorporating third-degree dependencies and finally achieving 92% confidence. At this point, the confidence threshold is met (shown by the dotted red line), and expansion terminates.

The color gradient from pink (low relevance) to blue (moderate) to green (high) indicates which nodes contribute most to confidence. AGR doesn't blindly retrieve to maximum depth. It expands only as far as necessary to build sufficient understanding, balancing thoroughness against noise.

The Technical Architecture of AGR

Graph Construction and Edge Types

AGR builds a comprehensive code graph where nodes represent various code artifacts and edges represent typed relationships between them.

Table 1 categorizes the five node types in AGR's code graph and their semantic properties. Code Nodes represent executable elements (functions, classes, modules) and receive the highest base weights (0.6-1.0) because they directly implement behavior.

Documentation nodes capture human explanations through comments, docstrings, and README files, with moderate weights (0.4-0.6) since they explain intent but don't execute. Test Nodes validate behavior through unit tests and fixtures, weighted 0.5-0.8 based on coverage and specificity.

History Nodes track temporal evolution through commits, PRs, and issues, crucial for bugs introduced by recent changes (0.3-0.7 weights). Configuration nodes represent settings and environment variables that affect runtime behavior, highly weighted (0.5-0.9) for configuration-related bugs.

This multi-modal graph enables AGR to reason across code, documentation, tests, history, and configuration simultaneously, mirroring how developers debug by consulting all available information sources.

The graph also encodes different edge types with varying semantic weights, shown in the bar chart below.

Figure 5 quantifies the relative importance of different edge types in AGR's graph traversal. Direct Calls receive the highest weight at 1.0, reflecting that when function A calls function B, understanding B is critical to understanding A's behavior.

Test Coverage edges weight at 0.92, recognizing that tests revealing bugs point directly to problematic code. Function Calls at 0.85 differentiate between direct invocation and more abstract call relationships. Imports at 0.78 show moderate importance since imports establish dependencies but may not be causally relevant.

Data Flow at 0.73 tracks how values propagate through code, important for tracing how bad data causes failures. Inherits at 0.66 reflects that class hierarchies matter but are less immediately relevant than execution paths. Comments at 0.53 have the lowest weight, useful for context but not causally connected to execution.

These weights guide AGR's expansion priority: when exploring neighbors, AGR prefers following Direct Calls and Test Coverage edges over Comments, ensuring it discovers causally relevant code before tangential context.

The Adaptive Algorithm

The brilliance of AGR lies in its adaptive nature. Rather than blindly expanding to a fixed depth, it monitors confidence and expands only as needed.

Algorithm 1 presents the mathematical formulation of AGR's core retrieval logic. The algorithm takes as input a query q, code graph G, and confidence threshold δ (default 0.89). It begins by extracting semantic components from the query to seed the traversal, then enters the main adaptive expansion loop. Line 6 shows the key insight: the while loop continues only while confidence remains below threshold, ensuring expansion stops once sufficient context is gathered. Lines 7-11 perform k-hop neighborhood expansion, retrieving all nodes within k hops of current seeds and filtering based on relevance scores. Lines 12-14 calculate confidence and information gain to guide the termination decision. The critical adaptive step occurs at lines 15-17: if confidence gain is below threshold ε (diminishing returns detected), k increments to expand the search radius. Line 20 updates seeds with newly discovered relevant nodes for the next iteration. This formulation captures AGR's essence: expand adaptively based on confidence feedback rather than statically based on fixed depth.

The Python implementation below shows how this translates to working code:

def adaptive_graph_retrieval(query, graph, confidence_thr
                             eshold=0.89):
    """
    AGR's core algorithm for adaptive graph-guided retrieval
    """
    # Initialize
    seeds = extract_semantic_nodes(query, graph)
    visited = set()
    context = []
    k = estimate_complexity(query)  # Initial hop depth
    
    # Adaptive expansion
    while confidence(context, query) < confidence_threshold:
        candidates = []
        
        # Expand k-hop neighborhood
        for node in seeds:
            neighbors = graph.get_k_hop_neighbors(node, k)
            for n in neighbors - visited:
                score = compute_relevance(n, query, context)
                candidates.append((n, score))
        
        # Select top candidates based on typed edges
        selected = top_k(candidates, lambda_k=k)
        
        for node, score in selected:
            if is_implementation(node) or is_dependency(node):
                context.append(retrieve_context(node))
                visited.add(node)
        
        # Adaptive depth adjustment
        if delta_confidence(context) < epsilon:
            k += 1  # Expand search radius
        
        seeds = seeds.union(extract_new_seeds(context))
    
    return context

The implementation reveals several practical details. extract_semantic_nodes parses the query to identify starting points like error locations or stack trace elements. estimate_complexity uses learned heuristics to set initial k based on query type (as shown in Figure 7). The main loop's confidence function combines the four signals from Figure 6 (semantic coverage, structural completeness, temporal relevance, pattern match) to determine if context is sufficient. compute_relevance scores each candidate node based on its typed edges (using weights from Figure 5) and current context. top_k selects the most promising candidates, with selection size governed by lambda_k that increases with depth. The adaptive adjustment checks delta_confidence (marginal confidence gain) against threshold epsilon—if confidence plateaus, k increments to search deeper. Finally, extract_new_seeds identifies newly discovered nodes that warrant further exploration (e.g., functions called by retrieved code).

This algorithm embodies AGR's core insight: retrieve adaptively based on confidence rather than statically based on fixed parameters. The while loop ensures AGR never retrieves too little (continues until confidence threshold met) or too much (terminates immediately upon crossing threshold). The adaptive k adjustment allows AGR to start shallow for simple bugs and expand deep for complex bugs, all driven by objective confidence metrics rather than predetermined heuristics.

How AGR Builds Confidence: A Visual Flow

Instead of a single metric, AGR's confidence calculation flows through multiple signals that together determine when sufficient context has been assembled.

Figure 6 breaks down how AGR calculates confidence from four independent signals. Semantic Coverage (40% weight) measures whether all error-related code has been found, the highest-weighted signal since missing causally relevant code guarantees failure.

Structural Completeness (30% weight) evaluates whether all dependencies are included, ensuring the retrieved subgraph is self-contained without dangling references. Temporal Relevance (20% weight) checks if recent changes affecting the bug are captured, critical for regressions introduced by commits.

Pattern Match (10% weight, lowest weight) identifies whether retrieved code matches known bug patterns from historical data. These four signals feed into a unified Confidence Score that must exceed the 90% threshold (shown by dotted red line) before retrieval terminates.

The weighting reflects debugging priorities: semantic coverage matters most because missing the cause means failure, while pattern matching helps but isn't essential. This multi-signal approach prevents premature termination and over-retrieval.

Query Complexity: A Decision Tree Approach

AGR determines initial search depth through intelligent query analysis, recognizing that different bug types require different traversal strategies.

Figure 7 illustrates AGR's decision tree for determining initial search depth (k) based on query characteristics. The tree starts at Error Type (root node) and branches based on observable features.

If it's a Syntax Error, AGR immediately sets k=1 (very shallow) since syntax errors are local by definition. If it's a Null Pointer exception, AGR checks whether it occurs in simple or complex code. Simple null pointers get k=1, while complex scenarios get k=2.

Race Condition bugs automatically trigger k=3 since they involve timing interactions between multiple components. Complex Error types (distributed system failures, data corruption) start at k=4 because root causes are typically distant from symptoms.

This initial k estimate prevents wasted computation: starting at k=5 for a syntax error would retrieve thousands of irrelevant nodes, while starting at k=1 for a distributed race condition would fail to capture necessary context. After initial expansion, AGR adjusts k dynamically based on whether confidence improves.

AGR's Timeline: How a Debugging Session Evolves

Real debugging isn't instantaneous. AGR's confidence builds progressively through multiple expansion phases until the threshold is reached.

Figure 8 visualizes how a typical AGR debugging session unfolds over time. At Error Detected (6 nodes, confidence 0%), AGR begins with zero context. At k=1 Retrieval (12 nodes, confidence 45%), AGR expands to immediate neighbors, building initial understanding but remaining below threshold.

At k=2 Expansion (26 nodes, confidence 78%), second-degree neighbors provide substantial additional context, but still insufficient to guarantee a correct fix. At k=3 Deep Retrieval (67 nodes, confidence 92%), AGR finally crosses the 90% threshold (shown by red dotted line), signaling sufficient context.

The timeline shows both node count and confidence level at each stage. Key insight: confidence doesn't grow linearly with node count. The jump from 0% to 45% required only 12 nodes, while the jump from 78% to 92% required 41 additional nodes.

This reflects diminishing returns: early nodes provide high-value core context, while later nodes fill gaps and edge cases. Real sessions complete in 47 seconds on average, with simple bugs terminating at k=1 in 6 seconds and complex bugs requiring k=5 in 87 seconds.

Information Gain Heatmap: When to Stop Expanding

AGR monitors information gain at each expansion to detect when additional retrieval provides diminishing returns, preventing wasteful over-expansion.

Figure 9 displays information gain as a heatmap where the x-axis represents Current Context Size (nodes) and y-axis represents Hop Depth (k). Color intensity indicates Information Gain, with bright yellow representing high gain (0.8) and dark purple representing low gain (0.2).

The optimal termination zone (marked by red dotted line around 60 nodes, k=3) shows where information gain drops below 0.3. The High Gain region (upper left, bright yellow) occurs at small context sizes and shallow depths where each new node dramatically improves understanding.

As context grows beyond 60 nodes, the heatmap darkens into the Low Gain region (bottom right), indicating that additional expansion provides minimal confidence improvement. The heatmap reveals that information gain depends more on hop depth than absolute node count.

Real-world sessions show AGR typically terminates between 20-80 nodes, precisely where the heatmap predicts optimal information gain exhaustion.

Visual Comparison Matrix: AGR vs Other Methods

How does AGR compare across critical dimensions? The matrix below reveals AGR's advantages and tradeoffs.

Figure 10 provides a comprehensive comparison across five critical dimensions. Flat Top-k retrieval shows Fast speed (green) due to simple vector similarity but only 25% Accuracy (red) because it misses causal relationships. Memory usage is None (yellow) and Cross-File capability is Poor (red) since it retrieves isolated chunks.

HyDE improves slightly to Medium speed and 34% Accuracy (orange) with Fair cross-file reasoning but still no memory or learning. Graph RAG achieves Slow speed due to graph construction overhead, 44% Accuracy (orange), Static memory, Good cross-file reasoning, but still None learning.

AGR stands out with Adaptive speed (yellow), 87% Accuracy (bright green), Persistent memory (green), Excellent cross-file reasoning (green), and Continuous learning (green). The color coding makes AGR's comprehensive superiority immediately visible.

AGR sacrifices raw speed but dominates every dimension that matters for debugging quality: accuracy, memory, cross-file reasoning, and learning. This explains why AGR achieves 3.5× better accuracy than the next-best approach.

Graph Construction: Building the Foundation

AGR's graph construction happens in layers, each adding different relationship types. This layered approach enables efficient incremental updates as code evolves.

Figure 11 illustrates AGR's layered graph construction where each layer adds specific relationship types. Layer 1: AST Structure (pink, base layer) parses source code into abstract syntax trees, establishing fundamental structure with execution edges. This forms the skeleton, constructed once per file in ~1ms.

Layer 2 adds Import Dependencies (blue, middle layer), connecting modules through import statements and creating cross-file edges. This layer enables AGR to traverse across file boundaries, critical since most bugs span multiple files. Construction time is ~5ms per module.

Layer 3 incorporates Git History (green, top layer), layering temporal relationships that track how code evolves through commits. This historical dimension enables AGR to trace when bugs were introduced and identify causally connected commits. Construction time is ~50ms for recent history.

The layered architecture enables incremental updates: when a file changes, only Layer 1 rebuilds for that file. This incremental design keeps graph construction fast even for massive codebases, with full builds taking minutes and incremental updates completing in seconds.

Dynamic Depth Determination

AGR's intelligence shines in how it determines retrieval depth based on query characteristics and confidence feedback.

Figure 12 quantifies how AGR maps different query types to optimal retrieval depths. Simple Error queries average k=1.2 hops, rarely requiring deep traversal since causes are local. Type Error queries average k=1.8, needing slightly deeper traversal to track type propagation.

Logic Error queries jump to k=2.7, reflecting that logic bugs often result from incorrect interactions between components. Race Condition queries reach k=3.6, requiring deep traversal to discover temporal dependencies and shared state.

Cross-Module bugs peak at k=4.3, needing the deepest traversal to trace causality across architectural boundaries. Distributed errors reach k=5.1, the deepest category, reflecting that distributed system bugs involve complex interactions across services.

This mapping isn't arbitrary: it's learned from 42.5M debugging sessions where AGR observed which depths successfully resolved each bug category. AGR uses this learned mapping as initialization, then adapts based on confidence.

Compositional Reasoning and Patch Planning

Unlike decoder-only models that generate token by token, AGR explicitly plans the structure of a fix through distinct phases before generating any code.

Figure 13 breaks down AGR's compositional reasoning into four sequential phases. Phase 1: Root Cause Analysis identifies the causal chain from symptom to underlying issue, outputting a structured causal graph.

Phase 2: Multi-File Fix Planning determines which files need changes, what type of changes, and in what order changes must be applied. This produces a Fix Structure specification.

Phase 3: Code Patch Generation implements the planned changes, generating syntactically correct code for each file that adheres to the fix structure. This outputs actual code patches.

Phase 4: Validation & Testing runs existing tests plus newly generated tests to verify the fix resolves the bug without regressions, producing a Test Results report.

The sequential nature is critical: planning happens before generation, preventing decoder-only models' common failure mode of starting to generate a fix before fully understanding the problem. This compositional approach sacrifices generation speed but dramatically improves correctness.

Real-World Performance: AGR vs Traditional Approaches

The paper presents compelling evidence of AGR's superiority. In the Multi-Random Retrieval benchmark, where debugging context is scattered across 10-50 files over 3-12 months of history, AGR dominates traditional approaches.

Figure 14 compares debugging success rates across retrieval strategies on realistic multi-file bugs. Traditional approaches show dismal performance: Flat Top-k achieves just 25% success because it retrieves syntactically similar but causally irrelevant code.

HyDE reaches 34% by hypothetically generating documents to improve retrieval but still lacks graph understanding. Graph RAG improves to 44% through graph-based retrieval but uses static expansion that over-retrieves for simple bugs and under-retrieves for complex ones.

Fixed k=2 achieves 86.7%, showing that even naive graph traversal helps. Fixed k=3 surprisingly drops to 80.1%, demonstrating that blind expansion introduces noise. AGR peaks at 87.1%, achieving optimal results by dynamically selecting the right depth for each query.

The key insight: AGR's 87.1% isn't just incrementally better. It represents crossing the viability threshold where AI debugging becomes reliable enough for production use. Below 60%, developers must constantly verify AI suggestions. Above 80%, developers can trust AI fixes with spot-checking.

Graph-Aware Attention vs Token Attention

A fundamental innovation in AGR is performing attention over structured graph nodes and relationships, not token sequences.

Figure 15 contrasts token attention (left) versus graph attention (right). Token Attention distributes attention uniformly across a flat sequence of tokens, treating all tokens equally regardless of semantic importance. O(n²) complexity means attention cost explodes with sequence length.

Graph Attention operates over structured relationships where nodes represent semantic units (functions, classes) and edges represent meaningful relationships (calls, imports). O(k·d) complexity scales with graph connectivity rather than input size, remaining manageable even for large codebases.

Structured relationships mean attention flows only along semantically meaningful paths: a function attends to its callers, callees, and dependencies, not every random token in the codebase. This structural efficiency enables AGR to reason over codebases with millions of LOC where token-based attention would exhaust memory.

Performance Across Different Retrieval Strategies

The paper's evaluation reveals how different strategies compare across precision, recall, and F1 score.

Table 2 provides comprehensive performance metrics. Flat Top-k shows high Precision (71.4%) because retrieved chunks are usually relevant, but terrible Recall (48.3%) because it misses causally connected code that's syntactically dissimilar.

Fixed k=1 achieves excellent Precision (86.8%) by staying focused but suffers on Recall (67.4%) by missing distant causes. Fixed k=2 shows the best balance among fixed strategies with 86.7% Debug Success. But k=3 performs worse: Precision drops to 68.7% despite higher Recall (90.2%), proving that blindly retrieving more context introduces noise.

AGR achieves the best of all worlds: 92.8% Precision (highest), 89.1% Recall (competitive with k=3), 91.6% F1 (highest by far), and 87.1% Debug Success (optimal). Efficiency at 91% shows AGR is nearly as fast as shallow retrieval by terminating early for simple bugs.

Figure 16 plots the precision-recall tradeoff as retrieval strategies expand to include more nodes. AGR (green line) dominates the top-right corner, achieving 92.8% precision while maintaining 89.1% recall, resulting in the highest F1 score at 91.6%.

Fixed k=1 (red line) shows high precision (86.8%) but low recall (67.4%), appearing in the top-left quadrant. Fixed k=3 (yellow line) pushes recall to 90.2% but precision collapses to 68.7%, demonstrating that indiscriminate expansion retrieves noise alongside signal.

The curves reveal a fundamental tradeoff: static strategies must choose between high precision or high recall, but cannot achieve both simultaneously. AGR's adaptive approach breaks this tradeoff by expanding selectively based on confidence.

Case Study: Hardware State Machine Debugging

One particularly striking example illustrates AGR's power in hardware debugging, where causality spans hardware-software boundaries.

Figure 17 demonstrates AGR's advantage on a hardware-software boundary bug. The query describes implementing a state machine for a hardware device. Traditional LLMs retrieve similar state machine code but completely miss the hardware constraint.

Traditional retrieval searches for syntactically similar state machine implementations, finding state transition logic in other software modules but failing to discover the hardware specification that defines valid state sequences. Without understanding hardware constraints, traditional LLMs suggest software-only fixes that violate hardware timing requirements.

AGR's graph traversal follows a different route: k=1 finds the immediate state machine code. k=2 discovers imports of hardware configuration modules. k=3 uncovers the hardware spec documenting valid state transitions and timing constraints.

AGR's final solution outputs "Extract: Complete Constraint" by recognizing that the state machine must be validated against hardware specifications, not just software logic. The fix includes explicit constraint checking that prevents invalid transitions.

The Confidence-Based Termination Model

AGR doesn't blindly expand to maximum depth. Its confidence model evaluates multiple signals to determine when sufficient context has been assembled.

Figure 18 visualizes the termination logic that prevents both premature stopping and wasteful over-expansion. The blue curve shows Recall climbing as hop depth increases: 0.4 at k=0, 0.6 at k=1, 0.82 at k=2, 0.9 at k=3, and plateauing around 0.94 at k=4+.

The orange curve shows Information Gain declining as diminishing returns set in: high at k=1-2, moderate at k=3, and collapsing to near-zero at k=4+. The red vertical line marks the Termination point where AGR stops expanding.

This occurs at k=3 where two criteria are satisfied: Confidence exceeds 90% threshold, and Information gain has diminished significantly. If AGR continued to k=5, confidence might improve marginally to 94%, but near-zero information gain means it would retrieve hundreds of additional nodes for just 4% confidence improvement.

Output-Aware Reasoning: Validation at Every Step

Debugging is fundamentally output-driven. AGR validates each reasoning step against expected program behavior, catching logical errors before generating code.

Figure 19 illustrates AGR's output-aware validation loop. After Retrieve Context, AGR proceeds to Reason Solution, generating a candidate fix hypothesis. But rather than immediately generating code, AGR performs Validate reasoning by checking: Does this fix address the root cause? Will it introduce regressions? Is it consistent with codebase patterns?

If validation passes, AGR proceeds to Generate Fix. If validation fails, AGR refines the reasoning strategy by adjusting retrieval or reconsidering the causal hypothesis. The Output-aware validation box shows this validation happens at every reasoning step, not just final output.

This prevents decoder-only models' failure mode where they commit to a fix direction early and generate plausible-looking but incorrect code. By validating reasoning before generation, AGR ensures that when it does generate code, the fix addresses the actual root cause.

This validation dramatically improves fix quality, as shown in the table below.

Table 3 reveals the dramatic impact of output-aware reasoning on fix quality. GPT-4.1 and Claude 4 Opus achieve high Syntactic correctness (92-94%), generating code that compiles, but fail on Semantic correctness (34-36%), producing fixes that don't actually solve the bug.

AGR (Retrieval Only) performs even worse, demonstrating that better retrieval alone doesn't guarantee better fixes without reasoning. But AGR (Full) with output-aware validation achieves 96.8% Syntactic, 87.4% Semantic, 85.3% Test Pass, and 94.6% No Regression.

The 2.6× improvement in semantic correctness and 6.5× improvement in test pass rate compared to Retrieval Only proves that output-aware validation is the critical component that transforms retrieved context into correct fixes.

Why AGR Works: Understanding Code as Developers Do

The genius of AGR is that it mirrors how experienced developers debug, making its approach both intuitive and effective.

Figure 20 compares how developers debug (left) versus AGR's process (right), revealing striking structural similarity. Developers start by seeing the error location, examining the failure point to understand symptoms. They then follow the call stack, tracing backwards through the execution path to identify where bad state originated.

Next, they check dependencies to understand what libraries, modules, or services the failing code relies on. Finally, they trace history to find when the bug was introduced, often using git blame or checking recent commits.

AGR mirrors this process exactly but operates on the code graph: it seeds from the error location, traverses call edges backwards to find the source of bad behavior, follows import edges to discover dependencies, and incorporates git history edges to identify causative commits.

This structural parallel explains why AGR works: it automates the cognitive process that expert developers already follow. The alignment also explains why AGR's outputs feel "right" to developers: the reasoning path matches their mental model.

Comparison to Standard Decoder Reasoning

Most LLMs operate in decoder mode: read context, predict next tokens. AGR instead behaves like a planner, thinking before generating.

Table 4 contrasts decoder-only models with AGR's planning approach. Context Assembly: Decoder mode uses a fixed window (retrieve once, generate from that context), while AGR uses dynamic graph traversal (expand adaptively until confidence threshold met).

Reasoning: Decoder mode operates token-by-token, predicting each token given all previous tokens, while AGR uses compositional phases (plan structure, then generate implementation). Validation: Decoder mode validates post-generation by running tests after code is written, while AGR validates during reasoning, catching errors before generation.

Memory: Decoder mode has no explicit memory beyond attention weights that fade over time, while AGR maintains persistent graph-structured memory. Complexity: Decoder mode scales as O(n²) attention where n is context size, while AGR scales as O(k·d) traversal where k is hop depth and d is average degree.

This comparison reveals why AGR succeeds where decoder-only models fail: by planning before generating and validating during reasoning, AGR catches errors that decoder models only discover after generating broken code.

Real-World Impact: AGR in Action

The combination of dynamic graph retrieval and attention-guided reasoning produces remarkable results across diverse debugging scenarios.

Figure 21 isolates AGR's components to identify which contributes most to debugging success. Across four bug complexity categories, two bars compare AGR Retrieval Only (blue) versus Full AGR with Reasoning (green).

For Simple bugs, AGR Retrieval Only achieves 92% success while Full AGR reaches 95%, a small 3% improvement because simple bugs require minimal reasoning. For Medium bugs, the gap widens: 61% (Retrieval Only) versus 88% (Full AGR), showing that reasoning becomes critical for multi-step causality.

For Complex bugs, retrieval alone collapses to 42% while Full AGR maintains 84%, demonstrating that sophisticated reasoning is essential for non-obvious causality. For Distributed bugs (the hardest category), retrieval alone manages just 28% while Full AGR achieves 75%, nearly 3× improvement.

The widening gap as complexity increases proves that reasoning, not just retrieval, drives AGR's advantage on hard problems. Retrieval provides necessary context, but reasoning transforms that context into correct fixes.

AGR as the Debugging Conductor

Chronos's AGR is not just a smarter retriever or decoder. It is a domain-specific reasoner designed for debugging that orchestrates the entire debugging process.

Figure 22 visualizes AGR's role as the central orchestrator connecting all debugging components. AGR (center) coordinates six subsystems through bidirectional communication.

Graph Memory provides the knowledge base, feeding context to AGR while AGR updates the graph with new patterns. Dynamic Retrieval expands the search space, receiving directives from AGR about where to search and reporting findings.

Attention Engine weights node importance, guided by AGR's understanding of causality while informing AGR which paths are most promising. Reasoning Module structures the solution, receiving context from AGR and returning fix plans.

Fix Generator produces code, guided by AGR's plan while validating against AGR's correctness criteria. Output Validation tests fixes, reporting results to AGR which uses them to refine future debugging strategies.

The orchestration is dynamic: AGR adjusts retrieval depth based on reasoning confidence, modifies attention based on validation failures, and updates memory based on fix success. This conductor role distinguishes AGR from simple pipelines where components operate independently.

Theoretical Complexity Analysis

Understanding AGR's computational properties reveals why it scales to massive codebases where traditional approaches fail.

Where: n = number of documents, k = retrieval depth, d = average node degree, V, E = vertices and edges

Table 5 analyzes computational complexity across four retrieval approaches. Flat Vector search operates in O(n log n) time using approximate nearest neighbor search, with space complexity O(n·d) storing document vectors. Retrieval cost is Low because it's a single lookup.

Dense Retrieval requires O(n²) time to compute pairwise similarities, with O(n²) space for the similarity matrix. Retrieval cost is High due to exhaustive comparison.

Graph RAG improves time complexity to O(n·d) by traversing only graph neighbors, with space O(|V| + |E|) for the graph structure. Retrieval cost is Medium since it avoids exhaustive search but must traverse the graph.

AGR achieves O(k·d·log n) time complexity: O(k·d) for traversing k hops with degree d, multiplied by O(log n) for priority queue operations. Space remains O(|V| + |E|) for the graph. Retrieval cost is Adaptive: low for simple bugs, higher for complex bugs.

The key advantage: AGR's complexity grows with hop depth k (typically 1-5) and graph connectivity d (typically 10-50), not with codebase size n (potentially millions). Real-world performance confirms theory: AGR handles 10M LOC codebases with sub-minute retrieval times versus Dense Retrieval's hours.

Implications for Autonomous Debugging

AGR's success has profound implications for the future of software development and automated debugging systems.

Figure 23 illustrates how AGR enables four transformative capabilities that cascade toward fully autonomous debugging. At the top, Context Understanding shows AGR assembles complete debugging context across files, time, and relationships.

This comprehensive understanding enables the second capability: Causal Reasoning, where AGR traces root causes through dependency chains and history. With causal understanding, AGR achieves the third capability: Autonomous Operation where no human guidance is needed for 65.3% of real-world bugs.

Finally, these three capabilities enable Continuous Learning: each debugging session improves future performance by updating the graph with new patterns, bug-fix pairs, and causal relationships.

The cascading structure shows these capabilities build on each other. The implications extend beyond debugging: AGR's approach applies to any domain where understanding requires assembling context from fragmented sources through typed relationships.

The Future of Intelligent Code Retrieval

AGR represents just the beginning of graph-aware code intelligence. Future directions include:

Figure 24 visualizes six future research directions that extend AGR's foundation. AGR Today (center, green) represents current capabilities: dynamic graph traversal, confidence-based termination, and compositional reasoning.

Cross-Repo Learning (top) would enable AGR to learn patterns across multiple codebases, recognizing that similar bugs occur across projects and transferring debugging knowledge globally.

Multi-Modal Debugging (top-right) would integrate screenshots for UI bugs, network traces for distributed debugging, and memory dumps for performance issues, creating a truly comprehensive debugging system.

Predictive Retrieval (right) would anticipate which nodes will be needed based on current context, pre-fetching likely-relevant code before confidence drops to avoid latency.

Visual Understanding (bottom-right) would parse UI screenshots and diagrams to debug front-end issues, expanding beyond text-only code.

Real-time Adaptation (bottom) would adjust retrieval strategies during long debugging sessions as understanding evolves, maintaining efficiency even for bugs requiring hours of investigation.

Federated Graphs (bottom-left) would enable AGR to operate across organization boundaries, learning from industry-wide debugging patterns while preserving code privacy through federated learning.

Performance Summary

Table 6 provides comprehensive performance comparison. Debug Success shows AGR's dominant 87.1% versus GPT-4.1's 13.4%, a 6.5× improvement representing the difference between useless and production-ready.

Precision at 92.8% means AGR's retrieved code is highly relevant, 1.3× better than GPT's 71.2%. Recall at 89.1% shows AGR misses little necessary context, 2.0× better than GPT's 45.6%.

Cross-File debugging capabilities show qualitative progression: GPT and Claude are Poor (cannot reason across files), HyDE is Fair (sometimes finds cross-file connections), Graph RAG is Good (consistent cross-file reasoning), and AGR is Excellent (deep multi-file causality).

Time reveals AGR's adaptive nature: at 52.1 seconds average, it's slower than GPT (12.4s) but comparable to Graph RAG (47.3s), reflecting that AGR prioritizes correctness over speed.\

AGR as a Paradigm Shift

Adaptive Graph-Guided Retrieval represents more than an incremental improvement—it's a fundamental paradigm shift in how AI systems approach debugging. By combining:

• Dynamic graph traversal that mirrors developer intuition

• Attention-guided reasoning that plans and validates

• Output-aware validation that ensures correctness

• Compositional planning that structures complex fixes

AGR achieves what traditional systems cannot: consistent, reliable debugging at scale.

Figure 25 plots the historical evolution of AI debugging success rates from 2021 to 2025, showing that AGR represents a discontinuous leap rather than gradual progress.

In 2021, Early LLMs (GPT-3) achieved roughly 5% success on real debugging tasks. By 2022, RAG Systems improved to around 12%. In 2023, Greedy RAG reached 20% through better chunking strategies.

By 2024, early Graph RAG prototypes hit 30% by incorporating basic graph structure. Then in 2025, AGR (labeled "AGR Breakthrough") jumps discontinuously to 87%, a near-vertical line representing step-function improvement.

AGR's 87.1% success rate isn't just "better than before." It crosses the usability threshold (marked around 75%) where AI debugging becomes reliable enough for autonomous operation rather than just assisted development.

By combining dynamic graph traversal that mirrors developer intuition, attention-guided reasoning that plans and validates, output-aware validation that ensures correctness, and compositional planning that structures complex fixes, AGR achieves what traditional systems cannot: consistent, reliable debugging at scale.

The 87.1% debugging success rate represents a fundamental breakthrough in how AI systems understand and navigate code. As software systems grow ever more complex, AGR's graph-based intelligence becomes essential for autonomous debugging at scale.

For developers tired of AI tools that provide syntactically correct but semantically useless suggestions, AGR offers hope: a system that truly understands code structure and can assemble precisely the context needed to solve real debugging challenges.

AGR turns context into causality and patches into guarantees, making autonomous debugging not just possible, but practical. The combination of intelligent retrieval and sophisticated reasoning creates a system that doesn't just find code. It understands it, reasons about it, and fixes it with the precision and insight of an experienced developer.