GRAFT: Global Optimization and Inference-Time Region Grafting for Agentic Workflows

Review date: 2026-08-10 Author: Zhongzhu Zhou Paper reviewed: Global Optimization and Inference-Time Region Grafting for Agentic Workflows (GRAFT) Paper authors: Donghyeok Koh, Gyuwan Kim, Jinyeong Bak, Seung-Hoon Na, Tao Yang, Haneol Jang, Cheoneum Park (HBNU, UCSB, SKKU, UNIST) arXiv: 2608.02353 Venue/Status: Preprint (cs.CL), August 2026

1. Why a “fixed workflow for every query” is the wrong default

Agentic workflows — pipelines that chain planning, retrieval, reasoning, verification, and formatting steps around an LLM — have become the standard way to get a language model to do more than answer in one shot. Frameworks like AutoGen, MetaGPT, and CAMEL let you wire these steps together by hand; a newer generation of systems (ADAS, AFlow, MaAS) instead search for a good wiring automatically, treating the workflow itself as an optimization target. The pitch is compelling: instead of a human guessing which combination of Chain-of-Thought, self-consistency, retrieval, and self-refinement will work best for “math word problems” versus “multi-hop question answering,” let an optimizer explore the combinatorial space and report back the winner.

But there is a structural assumption hiding underneath almost all of this line of work: the searched workflow is one fixed artifact, discovered once (offline, using a validation set with ground-truth labels), then applied unchanged to every future input at inference time. AFlow explicitly does this — search once via Monte-Carlo Tree Search over operator graphs, freeze the winner, deploy it. MaAS softens this slightly by sampling a query-conditioned architecture from a learned “agentic supernet,” but that supernet distribution is itself trained offline and then frozen; the sampling only picks which slice of an already-fixed distribution to use, it does not adapt based on what happens during execution of this particular query.

The paper’s central empirical claim, later confirmed by an ablation (Table 2, discussed in §5), is that this rigidity leaves real performance on the table. Some inputs genuinely need a different treatment than what the population-optimal workflow prescribes: a simple one-hop arithmetic question needs one reasoning step, while a multi-hop question requires evidence aggregation, cross-checking, and possibly a second retrieval pass. A workflow tuned to the average difficulty of a benchmark cannot dynamically deepen its reasoning for the harder 20% of instances without either (a) applying that extra depth uniformly and wasting tokens on the easy 80%, or (b) re-running the entire offline search per input, which is far too expensive to do live.

GRAFT’s proposal is to split the difference cleanly: keep a workflow’s global structure — which stages exist, in what order, with what connectivity — as a frozen prior established once per task via ordinary offline search. Then, at inference time, for this specific input, locally replace only the internal operator inside individual “regions” of that structure, using signals computed from the model’s own execution (no ground truth available, no gradient updates, no retraining) to decide which regions need a swap and what to swap them for. This “structurally global, semantically local” design is the paper’s whole thesis, and unpacking exactly how it stays safe (not making things worse) while being cheap (not re-running the entire search) is the heart of the paper.

Prerequisites: what you need before diving in

Agentic workflows as typed DAGs. An agentic workflow $W$ can be modeled as a directed acyclic graph (DAG) of operators — reusable computational units like a planner, a retriever, a chain-of-thought reasoner, a self-consistency voter, a verifier/refiner, or an output formatter. Feeding an input $x$ through the DAG in topological order and collecting the terminal output gives $W(x)$. Each operator plays a role (plan, evidence, reason, verify, refine, format), and for a given task, a curated region library $\mathcal{O}$ specifies which concrete operators are eligible to fill each role — e.g., the “reason” role might be filled by plain Chain-of-Thought, by 5-sample self-consistency, or by self-consistency followed by a self-check-and-revise pass.

Why search the workflow instead of hand-designing it. The paper cites prior evidence (Zhuge et al. 2024; Zhang et al. 2025a) that performance varies substantially across different wirings of the same underlying LLM — operator choice and ordering matter as much as, sometimes more than, model choice. This motivates treating workflow structure itself as something to optimize, the same way hyperparameter search treats learning rate or batch size as something to tune rather than eyeball.

Single-entry single-exit (SESE) regions, borrowed from compiler theory. A SESE region is a subgraph with exactly one incoming edge (entry) and exactly one outgoing edge (exit) — a concept from the Program Structure Tree literature (Johnson, Pearson & Pingali 1994), originally used to decompose control-flow graphs in compilers into nested, independently-analyzable chunks. GRAFT repurposes this idea for agentic workflows: because a SESE region has a single well-defined interface (what comes in, what goes out), you can swap out everything internal to the region without disturbing the rest of the DAG’s wiring. This is the structural trick that makes “local editing without breaking the global graph” well-defined rather than ad hoc.

Label-free quality proxies. Ordinarily, deciding whether a candidate reasoning trace is “good” requires a ground-truth answer to compare against — fine for offline validation-set search, useless at inference time on a fresh, unlabeled query. GRAFT instead scores candidates using signals computable from the model’s own outputs: self-consistency (do independently-sampled reasoning chains agree with each other?), groundedness (does the answer’s content actually appear in retrieved evidence?), and verifier signals (does generated code pass its own test suite?). None of these require the true answer — they are properties of internal agreement and support, not external correctness — but the paper is careful to also measure, empirically, how well these proxies actually correlate with true correctness (this becomes RQ3 and Table 3, and the answer is: “it depends heavily on the task,” which is one of the paper’s most useful honest findings).

UCB-style exploration bonuses. The Upper Confidence Bound (UCB) algorithm (Auer, Cesa-Bianchi & Fischer 2002) is a classic multi-armed-bandit strategy: at each decision point, prefer options that either look good so far (exploitation) or haven’t been tried much (exploration), balancing the two via a bonus term that shrinks as an option accumulates trials. GRAFT reuses this idea (not for choosing actions in a bandit sense, but for prioritizing which regions of the workflow deserve the limited local-search budget on a given pass) — a nice example of a well-understood tool from one subfield (bandits) getting repurposed for resource allocation in another (workflow adaptation).

2. Architecture overview: what stays frozen, what gets grafted

Figure 1 (paper Fig.1): Left (offline, “per task”): a role-scoped search over region libraries (QA / Math / Code, each with role-specific candidate operators like Plan/Evidence/Reason/Verify/Refine/Format) picks one global workflow $W_{c^*}$, with unused optional roles deactivated (dashed boxes, e.g., “Drop Region” for math tasks that need no retrieval). Right (online, “per input”): $W_{c^*}$‘s region sequence is held fixed (e.g., Planner → Multi-Hop-2 evidence → CoT&Gnd format, shown as the row of boxes at top), while a Proposer/Region-memory/Coupling-guard loop (bottom) repeatedly evaluates local edits to individual regions — here swapping the “Reason” region from a default CoT-based operator to something stronger — subject to passing a quality bar and a boundary-consistency guard, with accepted swaps written back into a reusable configuration memory.

The diagram makes the two-phase split concrete. On the left, the offline phase runs once per task (not once per input): for a task like multi-hop QA, it enumerates combinations of role-specific operators — which planner, which evidence-gathering operator, which reasoning operator, and so on — and picks the single best-scoring combination on a validation set, discarding the redundant “Drop Region” placeholders for roles a given task doesn’t need (e.g., math and code tasks skip the “evidence” region entirely, since they don’t require external retrieval). This produces $W_{c^*}$, the frozen global scaffold, and it is exactly the kind of workflow that AFlow or MaAS would also produce and then deploy statically.

The novelty is entirely on the right side: at inference time, for a specific input $x$, the frozen sequence of regions is kept in place (arrows preserved, order preserved), but a control loop — Proposer, region memory, evaluation against a label-free proxy, and a coupling guard — decides, region by region, whether the incumbent operator inside that region is good enough for this particular $x$, or whether a graft (a swap to an alternative operator with the same role) should be attempted, executed, scored, and — if it passes the guard — adopted. Anything not touched by this loop behaves exactly like the static AFlow/MaAS baseline; anything touched gets a per-input customization. This is why the paper’s framing of “workflow as an adaptable execution policy rather than a static artifact” (repeated at the start, in §3.1, and in the conclusion) is the right one-sentence summary: $W_{c^*}$ is the policy skeleton, and grafting is the per-state action selection layered on top of it.

3. The centroid–residual — sorry, the region–graft — decomposition, derived step by step

(Note: the paper does not use a centroid–residual decomposition — that terminology belongs to a different paper we reviewed this week. GRAFT’s actual decomposition is a two-level objective: a task-level global search, and an input-level local search constrained to stay inside the frozen global structure. We derive both below.)

3.1 The conceptual, intractable objective

The paper starts by stating the ideal objective any workflow optimizer would want to solve, then explains why nobody solves it directly. The token-regularized quality objective for a task $t$ is:

$$W_t^* = \arg\max_{W \in \mathcal{W}_t} \left[ G(W) - \lambda_{\text{tok}} \, c_{\text{tok}}(W) \right]. \tag{1}$$

Here $G(W)$ is some notion of task-level quality (accuracy, F1, solve rate — whatever the benchmark’s native metric is) that $W$ achieves in expectation over the task’s input distribution, $c_{\text{tok}}(W)$ is the expected token cost of running $W$, and $\lambda_{\text{tok}}$ trades one off against the other — a soft penalty added to the objective rather than a hard cutoff, which matters because it means an unusually expensive-but-much-better workflow can still win if $\lambda_{\text{tok}}$ is small, rather than being disqualified outright. $\mathcal{W}_t$ is the full search space of workflows for task $t$ — combinatorially, every valid combination of operator, connection, and parameter choice.

$W_t^*$ is called the task-level optimum: the single best workflow averaged over the task’s whole input distribution. Crucially, the paper is explicit that this is not the same as what you’d actually want for any one input: the instance-level optimum is

$$W_x^* = \arg\max_{W \in \mathcal{W}_t} G(W; x),$$

i.e., the best workflow for this specific $x$. In general $W_t^* \ne W_x^*$: the population-average winner and the per-instance winner disagree whenever the task has heterogeneous difficulty (which almost every realistic benchmark does — GSM8K has easy arithmetic and multi-step word problems side by side). This gap between $W_t^*$ and $W_x^*$ is the entire reason GRAFT exists; if every input in a task were equally hard, offline search would already be optimal and there would be nothing to graft.

Why not just solve for $W_x^*$ directly, for every input, at inference time? Three concrete reasons, laid out early in the introduction, and each has a corresponding fix baked into GRAFT’s design:

1. Search space is exponential. $\mathcal{W}_t$ spans combinations of operator choice × parameter setting × connection topology; searching all of it per input (as AFlow’s MCTS or ADAS’s meta-agent iterations effectively do, just once offline) would be far too costly to repeat live. Fix: restrict the online search space to a compact, role-scoped local candidate set per region, not the full $\mathcal{W}_t$ — this is Eq. 3, discussed below.
2. No ground-truth labels at inference time. Offline search can use $s(W(x), y)$ — a matching score against the true answer $y$. At inference time, $y$ is exactly what you’re trying to produce; you cannot use it to grade candidates. Fix: label-free proxy signals (self-consistency, groundedness, verifier pass rate) — Eq. 4 and 5, discussed below.
3. Inter-region interference. Failure-mode studies of multi-agent systems (Cemri et al. 2025, cited directly) identify misaligned information transfer between agents as a dominant failure category — improving one stage’s local output does not guarantee the overall pipeline improves, because a locally “better” but differently-shaped output can break an assumption a downstream stage was relying on. Fix: the coupling guard, Eq. 6, discussed below, which explicitly checks that a local improvement doesn’t secretly break a downstream boundary contract.

3.2 Offline phase: picking the global scaffold $W_{c^*}$

The global workflow is organized as an ordered sequence of SESE regions $R = (g_1, \ldots, g_n)$. Each region $g_i$ corresponds to a role (plan/evidence/reason/verify/refine/format), and has a role-specific region library $\mathcal{C}_i$ of candidate operators — including, importantly, an identity operator that does nothing, meaning a region can be deactivated entirely for tasks that don’t need that role (math and code skip the “evidence” region; QA tasks keep it). A workflow configuration is a tuple $c = (c_1, \ldots, c_n)$, one operator choice per region, and the offline objective is:

$$c^* = \arg\max_{c} \; \frac{1}{|D|} \sum_{(x, y) \in D} \Big[ s(W_c(x), y) - \lambda \, \tau(W_c(x)) \Big], \tag{2}$$

where $D$ is a labeled validation set, $s(\cdot, \cdot)$ is the task’s matching score against ground truth $y$, and $\tau(\cdot)$ is a token-cost penalty (the concrete, discretized cousin of the conceptual $c_{\text{tok}}$ in Eq. 1). Because each region’s candidate set $\mathcal{C}_i$ is small and fixed per task, the joint search space is the Cartesian product $|\mathcal{C}| = \prod_i |\mathcal{C}_i|$ — large, but tractable enough for exhaustive enumeration or coordinate ascent to handle offline (this is emphatically not claimed to be cheap in absolute terms; it’s cheap enough to do once per task, which is the only requirement, since it never needs to be repeated per input). A tie-breaking rule prefers configurations with fewer active regions, which has a nice practical side-effect: it prunes roles that a small validation set might spuriously prefer activating, keeping the frozen scaffold as lean as the task genuinely requires.

Design choice — why tailor the role scope per task instead of using one universal role set? Why it works: if every task were forced to consider every role (e.g., forcing math tasks to also search over “evidence” operators), a validation set small enough to be practical can spuriously reward activating a role that doesn’t actually help, purely from noise — the paper states this plainly (“enforcing the same set of roles across all tasks may cause irrelevant roles to be spuriously selected… thereby degrading performance”). Obvious alternative: a single universal region library covering every role for every task, which is conceptually simpler and avoids task-specific engineering. Where it fails: the universal approach wastes search budget exploring irrelevant dimensions (does a GSM8K arithmetic problem need a retrieval region? almost never) and risks overfitting small per-task validation sets to spurious role activations — exactly the failure mode the task-scoped restriction is designed to avoid.

3.3 Online phase: what a “graft attempt” for one region actually computes

This is the technical core, and it’s worth walking through in the order the paper presents it: local search objective, then quality scoring, then the acceptance guard.

Step 1 — bound the search space per region. Instead of searching all of $\mathcal{C}$, a single region $g$‘s local edit space $\mathcal{E}(g)$ contains only alternative operators sharing $g$‘s role, plus alternative parameter settings for the current operator (e.g., how many self-consistency samples to draw, what sampling temperature to use). Crucially, $\mathcal{E}(g)$ is not static — it expands in graduated stages, $\mathcal{E}_0(g) \subseteq \mathcal{E}_1(g) \subseteq \cdots \subseteq \mathcal{E}_J(g)$, where the first stage only offers cheap candidates close to the incumbent, and later, more expensive/more different candidates are only unlocked if the cheap stage fails to hit a quality target. This is a coarse-to-fine search strategy — try the cheap fix first, escalate only on failure — that keeps the typical per-input search cost low while still allowing an expensive rescue (e.g., escalating a single CoT chain to a full 5-sample self-consistency-plus-revise pipeline) when the input genuinely needs it.

Step 2 — score each candidate with a label-free quality proxy. For a candidate configuration $\phi \in \mathcal{E}(g)$ applied to input $x$, the local quality $Q_{t,r}(\phi; x)$ for task $t$ and role $r$ is a weighted average over whichever proxy signals are available for that role:

$$Q_{t,r}(\phi; x) = \frac{\sum_{k \in \mathcal{K}_{t,r}} \alpha_k \, q_k(\phi; x)}{\sum_{k \in \mathcal{K}_{t,r}} \alpha_k}. \tag{4}$$

Each $q_k \in [0, 1]$ is one label-free signal — self-consistency agreement across sampled chains, a groundedness score, a verifier pass rate — and because it’s a weighted average of terms each bounded in $[0, 1]$, $Q_{t,r}$ itself always stays in $[0, 1]$ regardless of how many signals happen to be available for a given role (a role like “reason” on a math task might only have self-consistency available; a role like “evidence” on a QA task might only have groundedness). The weights $\alpha_k$ are fixed constants shared across all tasks — the signal set $\mathcal{K}_{t,r}$ varies by task/role (which signals are even computable), but the relative importance placed on a given signal type, once available, does not get re-tuned per task. This is a meaningful simplifying design decision: it avoids per-task hyperparameter search on the weighting scheme itself, at the cost of not being able to say “groundedness matters more for QA than for code” even if that turns out to be true.

The groundedness signal, derived explicitly. One of the concrete proxy signals, groundedness $q_{gr}$, is defined as lexical coverage of the answer’s content words by the retrieved evidence set $E$:

$$q_{gr} = \frac{1}{|\mathcal{A}|} \sum_{a \in \mathcal{A}} \text{support}(a, E), \tag{5}$$

where $\mathcal{A}$ is the set of content words extracted from the candidate output, and $\text{support}(a, E) \in \{0, 1\}$ is 1 if word $a$ appears lexically somewhere in the evidence set $E$, 0 otherwise. This is a purely lexical — not semantic — coverage score: the answer’s content words are checked for literal string appearance in the evidence, not paraphrase or entailment. The paper is upfront about the consequence of this choice: “in GRAFT, groundedness is therefore defined as lexical evidence coverage,” with no hedging that this might miss legitimate paraphrases. Why it works: it’s cheap (no extra model call needed, just string matching) and robust to model-specific quirks in phrasing. Obvious alternative: an entailment-model or LLM-judge-based groundedness score, which would catch paraphrased-but-supported answers that lexical matching misses. Where it fails: an answer that correctly paraphrases evidence using different words (“the UK’s head of government” instead of “Prime Minister”) would score poorly on $q_{gr}$ despite being fully grounded — this is exactly the kind of task-specific quirk that the paper’s own Table 3 later surfaces as low proxy-correctness correlation ($\rho \le 0.17$) for QA and knowledge-intensive tasks.

Step 3 — the local search objective. Given $Q$, the region’s local search picks:

$$\phi^* = \arg\max_{\phi \in \mathcal{E}(g)} \Big[ Q(\phi; x) - \lambda_{\text{loc}} \, \tau(\phi) \Big] \quad \text{s.t.} \quad \text{accept}(\phi), \; \ell(\phi) \le \ell_{\text{budget}}(g). \tag{3}$$

This mirrors the offline objective’s structure (quality minus token penalty) but at the scale of one region instead of the whole workflow, and adds a latency filter $\ell(\phi) \le \ell_{\text{budget}}(g)$: candidates predicted to blow through a per-region latency budget are filtered out before being executed at all — avoiding wasting inference cost on candidates that would be rejected purely on time grounds even if they’d have scored well on quality. If no candidate satisfies the accept constraint (below), the incumbent is kept unchanged; grafting is opt-in per region, not forced.

Step 4 — the coupling guard, i.e., “don’t let a locally better swap secretly break downstream stages.” This is the mechanism directly answering interference concern #3 from §3.1:

$$\text{accept}(\phi) \iff Q(\phi) > Q(\phi^{\text{inc}}) \;\land\; \text{Coh}(W[g \leftarrow \phi], S) \ge \text{Coh}(W, S) - \epsilon. \tag{6}$$

Two conditions, both required (logical AND). The first, $Q(\phi) > Q(\phi^{\text{inc}})$, is a strict inequality against the incumbent’s own quality score — a tie or a decrease is never accepted, even if the candidate is otherwise appealing (e.g., cheaper). The second term is the actual novelty: $\text{Coh}(W, S)$ is a boundary-support score measuring what fraction of the boundary trace referenced by the (candidate) answer is actually supported by the evidence set $E$ handed down from upstream regions. The guard requires that swapping in $\phi$ doesn’t degrade this boundary-support score by more than a slack $\epsilon$ compared to not swapping. For tasks with no external evidence at all (math, code), $\text{Coh} \equiv 1$ trivially, so the second condition is automatically satisfied and the guard degenerates to pure local-quality improvement — the boundary-consistency machinery only actively bites for evidence-dependent tasks (QA, knowledge-intensive QA), which is exactly where inter-region interference (a locally-improved reasoning trace silently drifting away from what the retrieved evidence actually supports) is most plausible as a failure mode.

Why it works: it directly operationalizes the paper’s stated risk (local improvements harming global quality via interference) as a concrete, checkable inequality, rather than leaving it as a qualitative worry. Obvious alternative: just accept any $\phi$ with $Q(\phi) > Q(\phi^{\text{inc}})$ and skip the boundary check entirely — simpler, and it’s exactly what the ablation in Table 2 tests by removing the guard. Where it fails/costs: the ablation shows removing the guard costs 0.70 average points on the MaAS suite (Table 2) — real but modest on tasks that have $\text{Coh} \equiv 1$ throughout (none of the five MaAS-suite benchmarks use external evidence), meaning this ablation actually undersells the guard’s importance on evidence-heavy tasks like HotpotQA/DROP, where $\text{Coh}$ is not trivially 1 and the guard should matter substantially more — a gap the paper doesn’t separately ablate, which is a legitimate limitation (flagged again in §8).

4. The proposer and the full per-input inference algorithm

Searching every region on every pass, for every input, is wasteful when most regions are already fine. GRAFT’s proposer decides which regions get attention on a given pass using a UCB-flavored priority score:

$$\text{score}(g) = \hat v(g) + U(g) + \rho \, \text{Freq}(g) \, \text{Mod}(g), \tag{7a}$$ $$\hat v(g) = w_q (1 - Q_g) + w_f \, \text{Fail}(g) + w_m \, \text{Mod}(g). \tag{7b}$$

Derivation of intent, term by term. $\hat v(g)$ is meant to capture “how urgently does region $g$ need attention right now,” built from three additive signals: $(1 - Q_g)$ is the region’s quality deficit (low current quality → high urgency, since $Q_g \in [0,1]$); $\text{Fail}(g)$ is the region’s historical failure frequency (regions that have caused problems before are treated as suspects again); and $\text{Mod}(g)$ is role modifiability — some roles inherently have richer candidate libraries or more room to improve than others, so this term biases attention toward regions where a graft is even likely to help. $U(g)$ is the classic UCB exploration bonus, shrinking as region $g$ accumulates more optimization attempts — this guards against the proposer fixating on a small set of “usual suspect” regions forever and never re-checking others. The third additive term, $\rho \, \text{Freq}(g) \, \text{Mod}(g)$, is described as a “proactive prior” favoring regions that are both frequently modified historically and structurally amenable to modification — a compounding signal that a region is a repeat offender with headroom to improve, as opposed to a repeat offender that’s already near its ceiling.

Design choice — why an additive linear combination of heuristics instead of a learned priority function? Why it works: it’s fully interpretable, requires zero training data or gradient updates (consistent with the paper’s training-free framing throughout), and each term maps cleanly onto an intuitive notion (deficit, history, headroom). Obvious alternative: learn a priority-scoring model from execution traces (e.g., a small regression model predicting “expected gain from optimizing region $g$”), which could in principle capture nonlinear interactions between the three signals that the additive form cannot. Where it fails: the fixed weights $w_q, w_f, w_m, \rho$ are shared across tasks (implicitly, since they’re not indexed by $t$ in the paper’s notation), so a task where quality deficit should dominate priority and a task where historical failure frequency should dominate get the same weighting — the paper doesn’t report per-task weight tuning or sensitivity analysis for these hyperparameters, which is a gap worth flagging for anyone trying to reproduce or extend this.

Algorithm 1, unpacked step by step

Algorithm 1: GRAFT inference (per input x)
Input:  input x; task-searched global workflow W = W_c*;
        configuration memory M; proposer statistics Θ
Param:  max passes P; guard slack ε; quality target q*; cost budget B
Output: answer â

 1: W ← W_c*;  S ← ∅;  ∀g: cfg(g) ← defaultW_c*(g)      // start from frozen scaffold
 2: for pass = 1 to P do
 3:     F ← Propose(W, S, Θ)                             // Eq.7 priority ranking
 4:     changed ← false
 5:     for all region g ∈ F (upstream-first order) do
 6:         if cost spent > B then break                  // global budget guard
 7:         σ ← Signature(g, S, x)                        // memory lookup key
 8:         φ* ← M[σ]                                      // try cached winner first
 9:         if φ* = ∅ or Q(φ*; x) < q* then
10:             φ* ← arg max_{φ∈E(g)} [Q(φ;x) − λ_loc·τ(φ)]   // Eq.3: local search
11:         end if
12:         if φ* ≠ cfg(g) and Accept(φ*) then             // Eq.6: coupling guard
13:             cfg(g) ← φ*;  W ← W[g←φ*];  M[σ] ← φ*       // adopt the graft
14:             mark downstream(g) stale                    // cascade: re-check later stages
15:             changed ← true
16:         end if
17:         S ← Execute(cfg(g), x, S)                       // always run, update state
18:     end for
19:     Θ ← Attribute(S)                                    // update priority stats
20:     if ¬changed and no stale region and min_{g∈core} Q(g) ≥ q* then
21:         break                                            // early stop: converged
22:     end if
23: end for
24: return â ← Readout(S)

Line-by-line intuition.

• Lines 1: Initialize from the frozen global scaffold — every region starts at its offline-searched default; nothing is grafted yet.
• Lines 2–3, 5: Each pass re-ranks all regions by the proposer’s priority score (Eq. 7) and visits them upstream-first — a deliberate ordering choice, because a region’s inputs depend on everything upstream of it in the DAG, so evaluating in upstream-first order means each region is judged using already-updated upstream outputs rather than stale ones from before this pass began.
• Lines 7–8: memory-first lookup. Before doing any fresh search, GRAFT computes a signature $\sigma$ (a lookup key derived from the region, current execution state, and input) and checks whether a previously discovered winning configuration for a similar signature already exists in memory $M$. This is the amortization mechanism: identical or near-identical sub-problems (e.g., “reason region, math task, moderate-difficulty input”) that have been solved before don’t require re-solving.
• Lines 9–11: fall back to fresh local search only on a memory miss or a stale hit. If there’s no cached configuration, or the cached one doesn’t meet the current quality bar $q^*$ (a signature match doesn’t guarantee the input is identical, only similar — so a cache hit is a starting hypothesis, not a guarantee), GRAFT runs the actual local search of Eq. 3 over $\mathcal{E}(g)$.
• Lines 12–16: the acceptance/adoption/cascade logic. A graft is adopted only if it’s actually different from the incumbent and passes the coupling guard (Eq. 6). On adoption, three things happen atomically: the live workflow $W$ is updated in place, the memory $M$ is updated with this new winner (so future similar inputs benefit), and — critically — everything downstream of $g$ is marked stale, meaning it must be re-examined on a subsequent pass, because its inputs have now changed. This staleness-cascade is what correctly propagates the consequences of an upstream change without requiring the whole workflow to be re-run from scratch blindly; only the parts that could plausibly be affected get re-flagged.
• Line 17: execution always happens, whether or not a graft occurred. This line runs outside the if block — meaning even an unchanged incumbent region still gets executed and its output written into the shared state $S$, because downstream regions need that output regardless of whether this pass touched this particular region.
• Lines 19–22: convergence check. After a full pass, if nothing changed, no region remains marked stale, and every “core” (presumably non-optional/critical) region’s quality meets the target $q^*$, the algorithm exits early rather than burning through all $P$ passes uselessly. This means the actual number of passes used per input is often less than the configured maximum $P$ — a practical efficiency detail visible in Figure 2’s declining search-cost curve.
• Line 6: hard budget stop. If cumulative cost exceeds the budget $B$ mid-pass, the loop breaks immediately — a safety valve against runaway search on a pathological input, at the cost of potentially leaving some regions unexamined for that input (the paper does not discuss what happens to the final answer’s quality guarantee in this truncated case beyond “return whatever’s in $S$,” which is a soft spot worth flagging).

Complexity, derived. Naively re-searching the full task-level space $|\mathcal{C}| = \prod_i |\mathcal{C}_i|$ per input would be the whole point of Eq. 1’s intractability restated. GRAFT instead touches only the $K$ regions on the current pass’s frontier $F$, each with at most $M = \max_i |\mathcal{E}(g_i)|$ local candidates, giving $O(P \, K \, M)$ candidate evaluations per input — with $K \le n$ (at most all regions) and, crucially, $M \ll |\mathcal{C}|$ (a per-region local library is far smaller than the full joint space). Memory hits reduce this further in practice, since a hit at line 8 skips the local search of line 10 entirely for that region.

5. Design choices worth interrogating individually

(a) Why organize regions via SESE decomposition instead of allowing arbitrary subgraph replacement? Why it works: a SESE region has exactly one input interface and one output interface by construction, so any internal replacement automatically preserves the surrounding DAG’s connectivity — there is no way for a local edit to accidentally create a dangling edge or a cycle, because the boundary contract is structurally guaranteed, not just checked at runtime. Obvious alternative: allow arbitrary subgraph edits (replace any connected set of nodes with any other connected set), which is more expressive — it could, in principle, restructure connectivity itself, not just swap operators within a fixed slot. Where it fails/costs: SESE regions cannot express certain structural adaptations, like “insert an entirely new intermediate verification stage between two existing regions that previously had no boundary there” — GRAFT can strengthen or weaken existing slots, but cannot add topologically novel connections at inference time. This is a real expressiveness ceiling, not discussed explicitly as a limitation in the paper’s own text but implied by the SESE framing itself.

(b) Why a strict Q(φ) > Q(φ_inc) inequality rather than accepting ties or near-ties? Why it works: it guarantees the local-quality proxy score is monotonically non-decreasing across grafts for a given region within a pass — you can never graft your way into something the proxy itself judges as equal or worse, which is a clean, auditable safety property. Obvious alternative: accept ties when the candidate is cheaper (lower token cost) even at equal quality — this seems strictly better from a cost-efficiency standpoint and the paper’s own objective (Eq. 3) already subtracts a token penalty, so a tie-breaking-by-cost rule would be a natural, low-risk extension. Where it fails: the current strict-inequality rule means GRAFT can get stuck with an expensive incumbent operator even when a cheaper, equally-good alternative exists in $\mathcal{E}(g)$, purely because that alternative’s $Q$ doesn’t strictly exceed the incumbent’s (rather than the net objective $Q - \lambda_{\text{loc}}\tau$ being what’s compared for ties) — a small but real missed efficiency opportunity.

(c) Why fix the proxy signal weights $\alpha_k$ globally across tasks, rather than learning them per task? Why it works: it keeps the framework strictly training-free — no weight-tuning phase, no risk of overfitting weights to a small validation set, and it’s one less hyperparameter surface to search per new task, which matters for a system whose whole pitch is “works out of the box on any task with a role-scoped library.” Obvious alternative: fit $\alpha_k$ per task via a small calibration pass on the validation set, the same way the global workflow $c^*$ and per-task pass count $P$ already are calibrated (Eq. 2, §3.4). Where it fails: Table 3’s own data shows proxy-correctness correlation $\rho$ swings from 0.62 (MATH) down to 0.04 (GPQA) — a signal that’s highly informative for one task and nearly useless for another is being combined with the same fixed weight in both cases, which likely leaves headroom on tasks where the “wrong” signal (say, self-consistency where groundedness would be more diagnostic) happens to dominate the weighted average.

(d) Why cache winning configurations by an input-signature lookup rather than a learned retrieval/embedding index? Why it works: a discrete signature-keyed dictionary is exact, cheap to query (hash lookup), fully interpretable (you can literally inspect what got cached and why), and requires no embedding model or similarity threshold tuning — again consistent with the training-free design ethos. Obvious alternative: embed the input/state and retrieve the nearest cached configuration by vector similarity, which would generalize across signatures that are semantically similar but not identical, potentially raising reuse rates further, especially for tasks with diverse phrasing but similar underlying structure (code, QA). Where it fails: Table 3 shows reuse rates ranging from 0.86–0.97 on math (uniform input types, so exact-match signatures work great) down to 0.17–0.42 on QA/knowledge-intensive tasks (diverse input types, where exact signature matches are rarer) — this is precisely the regime where a similarity-based retrieval index would plausibly help more, and the paper doesn’t explore that direction.

6. Experimental results, walked through figure by figure

Setup. Two evaluation protocols are used to match prior published baselines exactly rather than re-running everyone under one umbrella: the MaAS setup (gpt-4o-mini as the executor LLM, five benchmarks: GSM8K, MATH, MultiArith for math; HumanEval, MBPP for code) and the BayesFlow setup (Claude Sonnet as executor, six benchmarks: GSM8K, MATH, HotpotQA, DROP, MMLU-Pro, GPQA). Baselines under each setup are taken from each protocol’s own published numbers, with GRAFT run fresh on the same public splits — a reasonable choice for direct comparability, though it does mean GRAFT’s own numbers and the baselines’ numbers weren’t necessarily produced under identical hardware/sampling conditions (a caveat worth remembering when reading “beats X by Y points” claims).

Figure 3 (paper Table 1): (a) Under the MaAS setup, GRAFT scores 95.04/62.89/97.9/94.66/86.70 across GSM8K/MATH/MultiArith/HumanEval/MBPP, averaging 87.44 — beating MaAS’s 83.59 by 3.85 points and AFlow’s 82.25 by 5.19 points, and winning outright on GSM8K, MATH, HumanEval, and MBPP (only MultiArith, already near-saturated at 96–99% across all methods, sees MaAS’s 98.80 edge GRAFT’s 97.9). (b) Under the BayesFlow setup with the stronger Claude Sonnet executor, GRAFT again wins on every single benchmark (97.2/76.8/80.0/92.7/83.4/74.2, averaging 84.1), including a striking 76.8 on MATH versus BayesFlow’s own 69.4 and AFlow’s 60.1 — a 7-to-16-point gap that suggests the local-grafting mechanism is not merely a small refinement on top of a strong baseline, but is capturing something the frozen-workflow baselines structurally cannot.

Reading the MultiArith exception honestly. It’s worth pausing on the one row where GRAFT doesn’t win outright: MultiArith, where MaAS’s 98.80 beats GRAFT’s 97.9 by roughly one point. This is a near-ceiling benchmark (every method scores 96%+), so the practical difference is close to noise-level, but it’s also a natural place to ask whether local grafting can ever hurt on tasks that are already easy enough that the frozen global workflow was basically optimal for nearly every input — if there’s little headroom to improve, the proposer’s exploration overhead (UCB bonus term $U(g)$ actively seeking out under-explored regions) could in principle occasionally graft in something slightly worse before the coupling guard’s strict-improvement condition catches it on the next comparison. The paper doesn’t investigate this specific row, but it’s a plausible mechanism and a fair thing to watch for when deploying on already-saturated tasks.

Figure 4 (paper Table 2): Removing local grafting entirely (i.e., running $W_{c^*}$ frozen, exactly like the AFlow/MaAS baseline paradigm) drops the average from 87.44 to 83.34 — a 4.10-point fall, the single largest ablation effect, confirming that grafting itself (not merely a stronger base workflow) is responsible for the majority of GRAFT’s gain over the static baselines. Replacing the label-free proxy with random scores drops performance to 83.96 (−3.48), nearly matching the no-grafting condition — meaning that without a meaningful quality signal to decide which candidates are actually better, grafting provides almost no benefit; the proxy’s informativeness, not the mere existence of a search loop, is what’s driving the gain. Removing the coupling guard costs a comparatively modest 0.70 points (86.74) on this particular benchmark suite — but see the caveat below.

The pass-count comparison (bottom half of Table 2) is a clean, satisfying result. Fixing $P=1$ globally scores 87.30; fixing $P=3$ globally scores 86.52 (worse — more passes is not automatically better, since some tasks converge in one pass and additional passes on those tasks add cost/noise without adding value); the paper’s actual per-task-tuned $P^*$ strategy (chosen per task on the validation set, ranging over $\{1,2,3\}$) recovers the best of both at 87.44. This validates a specific, checkable design claim: pass count is a task property, not a universal constant, and tuning it per task (a cheap, one-time offline decision, unlike per-input adaptation) meaningfully matters.

The coupling-guard ablation caveat, worth restating clearly. All five MaAS-suite benchmarks used in Table 2 have no external evidence requirement, so $\text{Coh} \equiv 1$ throughout and the guard’s boundary-consistency term never actually triggers — the −0.70 point ablation effect measured here is purely the effect of “accept only strict quality improvements” versus some laxer acceptance rule, not a measurement of the boundary-consistency mechanism the guard was actually designed to protect against (interference on evidence-heavy tasks like HotpotQA/DROP). This is a genuine gap in the ablation’s coverage that a careful reader should not paper over.

Figure 5 (paper Fig.2): (a) Per-query search cost, normalized to the first decile of inputs processed, drops by roughly 50% by the fifth-to-seventh decile across GSM8K/MBPP/DROP, as configuration memory accumulates reusable winners and fewer fresh local searches are needed. (b) Configuration reuse (regions successfully served from memory per query) rises correspondingly over the same processing order, plateauing near 0.5–1.2 regions/query depending on task — evidence that the memory-amortization mechanism (lines 7–8 of Algorithm 1) behaves as designed: costly on early, unseen inputs, progressively cheaper as the memory of winning configurations fills in.

Figure 6 (paper Fig.3): Holding the searched global workflow $W_{c^*}$ fixed (searched originally with gpt-4o-mini) but swapping only the executor model — gpt-4o-mini → Haiku-4.5 → Sonnet-4.5 — shows accuracy rising monotonically along essentially every benchmark’s line, with the largest jumps on the hardest reasoning tasks: GPQA climbs from ~38% to ~60% to ~74-83%, MMLU-Pro and MATH show similarly large multi-point jumps. Meanwhile MultiArith, GSM8K, and HumanEval — already comfortably above 90% with the weakest executor — show only marginal further gains, since there’s little accuracy headroom left to capture. This result is presented as evidence for the paper’s “workflow as adaptable execution policy” framing: the same structural workflow, without any re-search, meaningfully benefits from a stronger backbone model — a workflow isn’t just an artifact tuned to one specific model, it’s closer to a reusable execution strategy.

Figure 7 (paper Table 4): Side-by-side operator trace for one HotpotQA-style query, showing the frozen baseline’s single-CoT-chain error (conflating an act’s passage year with a person’s term of office) versus GRAFT’s grafted self-consistency-plus-revise operator converging on the correct answer with $Q=1.00$ — discussed in detail below.

A worked qualitative example (Table 4) makes the mechanism tangible. For the query “The Distribution of Industry Act was passed by a man who was prime minister when?” (ground truth: 1945–1951, Clement Attlee’s full term), the frozen baseline and GRAFT retrieve identical evidence (“Attlee served as PM… from 1945 to 1951,” alongside a distractor fact, “Distribution of Industry Act 1950”). The frozen workflow’s single Chain-of-Thought chain conflates the act’s passage year (1950) with the PM’s term, answering “1950” — a classic single-chain reasoning slip that a single sample has no built-in way to catch. GRAFT’s proposer, observing this region’s low proxy score $Q$ under the frozen configuration, grafts in a 5-sample self-consistency-plus-self-check-and-revise operator for the reason region specifically; all five independently-sampled chains converge on “1945 to 1951” ($Q=1.00$), and the final answer is corrected. This is a genuinely illustrative case precisely because both pipelines share identical upstream evidence — the entire difference in outcome traces to one grafted operator, making the causal story unusually clean (most real failures in agentic pipelines are messier, multi-cause affairs; this one happens to isolate cleanly, which is worth remembering is somewhat cherry-picked as an illustration rather than a typical case).

7. Limitations, stated and understated

Limitations the paper states or that follow directly from its own numbers:

• The label-free proxy’s correlation with true correctness ($\rho$ in Table 3) ranges from a respectable 0.23–0.62 on math/code tasks down to a weak 0.04–0.17 on QA/knowledge-intensive tasks. The paper is admirably candid about this (“the proxy is less effective at distinguishing good candidates in QA and knowledge-intensive tasks”), but the practical consequence — that GRAFT’s local search is essentially flying partially blind on exactly the task category (open-domain QA, GPQA-style knowledge questions) where getting the right answer matters most and is hardest to verify without ground truth — deserves more emphasis than a single sentence in an analysis subsection.
• Memory reuse rates (Table 3) are strong on uniform-input-type tasks (0.86–0.97 on math) but drop sharply on diverse-input-type tasks (0.17–0.42 on HotpotQA/MMLU-Pro/GPQA), meaning the amortization benefit that makes GRAFT’s per-input search cost manageable in aggregate is heavily task-dependent — on the hardest, most heterogeneous tasks, GRAFT pays close to the full local-search cost on nearly every single query, undermining the “search cost amortizes” story exactly where it would matter most for a production deployment.
• The GPQA numbers are flagged by the authors themselves as needing to “be read with caution due to possible contamination” — a caveat that applies to every method in that column, not just GRAFT, but worth remembering that some fraction of GRAFT’s headline gain on GPQA specifically may reflect contamination dynamics common to modern benchmarks rather than a genuine reasoning improvement.

Limitations the paper understates or omits:

• The coupling guard’s boundary-consistency mechanism is never separately ablated on an evidence-bearing task where $\text{Coh} \not\equiv 1$ — as discussed in §5’s design-choice analysis, the reported −0.70 ablation effect is measured entirely on tasks where the boundary term is trivially satisfied, so the paper has, in effect, never actually measured the primary mechanism it introduces to solve interference concern #3 (§3.1) under conditions where that concern is real. This is a significant gap for a mechanism the paper frames as central to its safety story.
• The fixed proxy-signal weights $\alpha_k$ and proposer-priority weights $w_q, w_f, w_m, \rho$ are treated as given constants throughout, with no sensitivity analysis or ablation reported for either set. Given how much Table 3’s $\rho$ swings by task, it’s a reasonable guess that at least some of GRAFT’s task-to-task performance variance is attributable to these fixed weights being closer to optimal for some tasks (math, code — where $\rho$ is decent) than others (QA — where $\rho$ is weak), but this is never directly investigated.
• The paper reports average scores over three runs (§4.1), but no variance/standard-deviation is reported anywhere in the main results tables (Table 1), the ablation (Table 2), or the operating statistics (Table 3) — for a system whose core mechanism involves stochastic self-consistency sampling and an exploration-driven proposer, run-to-run variance is a natural thing to expect and report, and its absence makes it hard to judge how much of, say, the 0.7–1 point gaps in Table 1 reflect genuine, reproducible improvement versus run-to-run noise.
• The complexity analysis ($O(PKM)$ candidate evaluations, §3.4) explicitly “excludes downstream re-execution” — but line 17 of Algorithm 1 shows every region, changed or not, gets executed on every pass it’s visited, and a staleness cascade (line 14) can mark many downstream regions for re-evaluation from a single upstream graft. The paper doesn’t provide a complexity bound including this re-execution cost, which for a workflow with many chained dependent regions could be the dominant cost term in practice, not the local-search term the stated complexity actually bounds.

8. Critical analysis

(a) Weaknesses and flaws specific to this paper. The single biggest structural weakness is the mismatch between where the coupling guard is motivated (interference on evidence-dependent, multi-agent tasks — explicitly cited via Cemri et al. 2025’s failure-mode taxonomy) and where it is actually evaluated (the Table 2 ablation, run entirely on evidence-free math/code tasks where $\text{Coh} \equiv 1$ makes the guard’s distinguishing mechanism inert). A reader taking the paper’s numbers at face value could reasonably conclude “the coupling guard buys 0.70 points,” when the guard’s actual raison d’être — preventing a locally-improved reasoning trace from silently drifting away from evidence support in a QA pipeline — is never isolated and measured on the benchmarks (HotpotQA, DROP) where it’s supposed to matter most. This is not a minor omission; it’s a gap in exactly the experiment that would validate the paper’s central safety claim.

A second, related weakness: the proxy fidelity numbers in Table 3 ($\rho$ as low as 0.04 for GPQA) mean that for a meaningful fraction of the benchmarks GRAFT is evaluated on, the entire local-search decision procedure is being guided by a signal that barely correlates with ground truth. The paper presents this candidly as an “analysis” finding (§5.1) rather than folding it back into a discussion of when GRAFT should or shouldn’t be trusted — a reader is left to infer, rather than being told directly, that GRAFT’s gains on GPQA/MMLU-Pro/HotpotQA should be trusted considerably less than its gains on GSM8K/MATH/code, even though the headline Table 1 numbers present all benchmarks with the same visual confidence (bold/underline formatting for best/runner-up, no signal of proxy-reliability caveat attached to specific rows).

(b) Limitations the authors understate or omit. As detailed in §7, the paper never reports run-to-run variance despite averaging over three runs, never separately ablates the coupling guard on an evidence-bearing task, and never performs a sensitivity analysis on the fixed proxy-weight and proposer-priority hyperparameters, despite direct evidence (the $\rho$ range in Table 3) that these fixed weights are being applied under wildly different signal-quality regimes across tasks. There is also no discussion anywhere of what happens when the hard budget cutoff (line 6 of Algorithm 1) actually triggers mid-input — does the returned answer come with any indication that search was truncated, or is a partially-searched answer indistinguishable at the API boundary from a fully-converged one? For any production deployment, that distinction matters a great deal, and the paper is silent on it.

(c) Concrete, specific improvement suggestions. First, re-run the Table 2 coupling-guard ablation specifically on HotpotQA and DROP (where $\text{Coh} \not\equiv 1$), reporting both the standard task metric and a direct measurement of how often the guard actually blocks a would-be-adopted graft due to the boundary-consistency term specifically (versus the strict-quality-improvement term alone) — this would finally isolate the mechanism the guard was built to protect against. Second, replace the fixed, globally-shared proxy weights $\alpha_k$ with a lightweight per-task calibration step (the same validation-set machinery already used to pick $c^*$ and $P^*$ could just as easily calibrate $\alpha_k$), and report whether per-task weight tuning closes any of the observed cross-task performance gap correlated with $\rho$. Third, report run-to-run standard deviations for every entry in Tables 1–3, given the stochastic self-consistency sampling and exploration-driven proposer at the core of the method — three runs is enough to compute this cheaply, and its absence is currently the single easiest, lowest-cost fix available to strengthen the paper’s empirical rigor. Fourth, add a semantic (not purely lexical) groundedness variant as an ablation arm specifically on HotpotQA/DROP, to quantify how much of the QA/knowledge-task proxy-fidelity gap (Table 3’s low $\rho$) is attributable to the lexical-matching design choice in Eq. 5 versus a more fundamental limit of label-free signals on open-domain QA — this would clarify whether the “groundedness → correctness” gap is a fixable engineering choice or a harder ceiling.

9. Reproducibility notes

The paper follows established evaluation protocols closely (MaAS’s and BayesFlow’s own benchmark splits and baseline numbers), which is good for direct comparability but means a would-be reproducer needs access to both prior papers’ exact splits, not just the benchmarks’ standard splits, to match the reported baseline rows precisely. Hyperparameters are mostly shared and stated explicitly: $\epsilon = 0.02$ (coupling-guard slack), $\lambda_{\text{tok}} = \lambda_{\text{loc}} = 10^{-5}$ (token penalties at both the offline and online objective levels), per-instance token and latency budgets (values for these specific budgets are not spelled out numerically in the main text, only described as “per-instance”). The maximum pass count $P \in \{1,2,3\}$ and the use of code-repair patterns are explicitly stated to be selected per task on the validation set — meaning a full reproduction requires re-running this per-task selection step, not just plugging in a single reported $P$ value across all tasks. Results are averaged over three runs for $W_{c^*}$, but as flagged in §7/§8, no seeds or variance are reported, which will make bitwise or even statistically-tight reproduction of the exact headline numbers (87.44, 84.1) difficult to verify independently without the authors’ original run logs. No code repository link appears in the paper text itself (unlike, for instance, the TurnSight paper surfaced during this same literature scan, which does link a GitHub repo) — reproduction currently depends entirely on re-implementing Algorithm 1 and the region libraries from the paper’s textual description.

10. Where GRAFT sits in the broader agentic-workflow-optimization landscape

Positioned against the workflow-search lineage this review’s introduction already contextualized: AFlow searches a single global workflow via MCTS and deploys it statically — GRAFT uses exactly this kind of frozen offline search as its own starting scaffold, then adds the inference-time layer AFlow lacks entirely. MaAS samples a query-conditioned architecture from a supernet distribution that is itself learned and frozen offline — closer to GRAFT’s spirit of per-query adaptation, but the adaptation is confined to which slice of an already-fixed distribution to draw, not an execution-time search informed by this query’s own intermediate outputs; GRAFT’s ablation (removing local grafting, Table 2) directly demonstrates that this distinction is worth 4.10 points on the MaAS suite, which is the most direct apples-to-apples evidence in the paper that “adapt based on execution, not just based on input features” is the substantive contribution over supernet sampling. DyLAN reconstructs the agent team per query from scratch via dynamic resource allocation, trading the stability of a validated global structure for maximal per-query flexibility — GRAFT explicitly critiques this tradeoff in its related-work discussion, preferring to retain global structural stability and localize only the adaptation. Relative to the broader single/multi-agent literature this same review series has covered (MASIB’s information-bottleneck framing of when multi-agent systems help at all, the Regression Tax’s analysis of when learned skills hurt agents), GRAFT sits at an interesting intermediate point: it doesn’t ask whether to use a multi-stage pipeline at all, but rather how much of that pipeline’s internal structure should be treated as fixed versus adaptable — a design-space axis (structural rigidity vs. flexibility) that is somewhat orthogonal to, and could plausibly be combined with, both of those other lines of inquiry.

11. Conclusion

GRAFT’s core insight — treat a globally-searched agentic workflow as structural scaffolding rather than a finished artifact, and localize the remaining adaptation to individual SESE regions using label-free proxies and a boundary-consistency guard — is a genuinely useful reframing of what “workflow optimization” should mean once you accept that no single fixed structure can be optimal for every input in a heterogeneous task distribution. The empirical results are convincing on their own terms: consistent wins across eleven benchmarks spanning two independent evaluation protocols, an ablation that cleanly attributes the majority of the gain to the grafting mechanism itself (not merely a better starting workflow), and an honest, if under-emphasized, admission that the label-free proxy’s reliability varies enormously by task. The paper’s most significant gap is methodological rather than conceptual: the one experiment that would validate its central interference-safety claim — the coupling guard’s boundary-consistency term, tested on a task where that term actually does something — is never run. For a framework whose entire pitch rests on “safe local adaptation without breaking global consistency,” that is the single most valuable follow-up experiment left on the table, and it’s a modest, achievable one: rerun Table 2’s ablation on HotpotQA and DROP, and report what changes.