1 introduction↩︎

Large Language Model (LLM)-based agents have rapidly evolved beyond prompt-based conversational applications into autonomous systems capable of planning, tool use, and multi-step task execution[1]. Modern development platforms such as Dify [2], Coze [3], and n8n [4] have further popularized agentic workflows, a node-based construction paradigm in which heterogeneous components are connected through explicit control and data dependencies to form executable pipelines. Users can develop workflows in low-code environments by dragging and configuring nodes. Such platform-orchestrated agentic workflows have been widely adopted in practical LLM applications [5], [6], including autonomous task planning[7], software engineering assistants[8], and enterprise automation systems[9].

Despite their growing adoption, the reliability of agentic workflows remains a concern[10]. Unlike traditional software systems, whose execution is largely governed by explicit control flow and deterministic program logic, agentic workflows exhibit highly dynamic and uncertain behaviors. Such uncertainty arises from probabilistic LLM outputs[11], context-sensitive tool interactions[12], and implicit coupling between node configurations, intermediate variables, and downstream execution logic[13]. As a result, failures are difficult to predict, localize, and repair, since an error in one node may silently propagate through the workflow and manifest as a downstream symptom. These failures substantially hinder the reliability, maintainability, and deployment readiness of real-world agentic workflows.

Program repair has long been a central concern in software engineering[14]. Traditional automated program repair techniques typically leverage issue descriptions, execution traces, and test results to localize defective code regions, generate candidate patches, and validate them against test suites[15]–[17]. However, due to the low-code nature of agentic workflows, such code-centric repair techniques cannot be directly applied to them; furthermore, failures in these workflows may stem from prompts, node configurations, inter-node dependencies, or tool interfaces, rather than from isolated source code issues [18], [19]. Therefore, recent studies have begun to explore repair and optimization techniques for agent systems, including prompt evolution [20], [21], workflow restructuring[22], [23], trajectory reduction[24], and runtime supervision [25]. Most existing techniques formulate agent improvement as an optimization problem, using trajectories, feedback, or final task-level metrics to search for improved system variants. Although such optimizations may result in better overall performance, they are often weakly linked to the root causes of concrete failures, leading to coarse-grained and less targeted modifications. These limitations motivate the need for diagnosis-driven agent repair, where failure attribution and root cause analysis provide explicit guidance for targeted workflow corrections.

Realizing such diagnosis-driven workflow repair, however, faces two key challenges. First, workflow failures are only partially observable from execution trajectories. Agentic workflow executions involve probabilistic LLM reasoning, external tool invocations, and complex interactions among heterogeneous nodes[26], [27]. As failures propagate through dependent workflow nodes, downstream symptoms are often intertwined with upstream causes, making it difficult to accurately determine where a failure originates and how it evolves throughout the execution process[28], [29]. Second, workflow repair requires reasoning beyond local modifications [30]. A workflow node is often coupled with prompts, variables, model configurations, and downstream execution behaviors[31]. As a result, a seemingly correct local change may introduce unintended side effects or violate implicit assumptions elsewhere in the workflow. Effective repair therefore requires not only correcting the localized failure, but also preserves the consistency of the overall workflow logic and task objectives.

To bridge this gap, we propose FlowFixer, a diagnosis-driven repair approach for agentic workflows. The core idea is to combine symbolic modeling and symbolic inference to make workflow failures analyzable and repairable. Specifically, FlowFixer first transforms the execution trajectories into unified symbolic representations, making node configurations, node behaviors, inter-node dependencies, and execution states explicitly observable. It then performs symbolic inference over the symbolic trace to derive and verify node-level behavioral assertions, producing structured diagnosis evidence for failure attribution and root cause analysis. Based on the resulting diagnosis information, FlowFixer generates targeted repair candidates that not only address the localized errors, but also takes into account the dependencies of other related nodes as well as the overall task objectives. Before applying them, it performs a lightweight pre-execution assessment against symbolic constraints of the overall workflow, checking whether each candidate is compatible with inferred node behaviors, preserves inter-node dependencies and execution-state constraints, and remains aligned with the global task objective. By filtering out infeasible candidates before execution, this assessment reduces unnecessary dynamic verification overhead and leaves only viable candidates for dynamic verification of actual repair effectiveness. Furthermore, FlowFixer also maintains an experience pool that records online repair feedback and continuously accumulates repair experience, enabling progressively improved failure diagnosis and repair effectiveness across repeated workflow failures.

Experimental results demonstrate the effectiveness of FlowFixer. FlowFixer achieves a repair success rate of 71.3%, outperforming all repair baselines by 11.9% to 27.6%. In failure diagnosis, it improves failure attribution accuracy by 4.8% to 33.1% and root cause analysis accuracy by 15.3% to 38.8% over baseline methods. Ablation studies further confirm the effectiveness of symbolic modeling, root cause taxonomy, repair knowledge, execution information, and experience accumulation in improving both diagnosis and repair performance. In summary, this paper makes the following contributions:

• We present a symbolic modeling & inference based framework for failure diagnosis and automated repair of agentic workflows.

• We propose a unified node behavioral specification that is instantiated as executable assertions to produce structured evidence for failure diagnosis.

• We construct a multi-dimension assessment mechanism which can effectively eliminate unreasonable modified workflows and reduce verification costs.

• We demonstrate the effectiveness of FlowFixer on real-world agentic workflows, showing its capability on accurately failure diagnosis and successfully workflow repair.

2 Background↩︎

Modern agentic AI development platforms (e.g., Dify, Coze, n8n) achieve agentic workflow construction through a node-based paradigm. Instead of implementing complex logic through source code, users construct workflows by visually connecting predefined nodes and configuring their parameters through graphical user interfaces. A workflow typically consists of multiple interconnected nodes, where each node encapsulates a specific functionality, such as LLM invocation, text processing, tool execution, knowledge retrieval, conditional routing, or data transformation.

The node types supported by the platform are summarized as follows: 1) Start and Termination Nodes; 2) LLM and Agent Nodes; 3) Knowledge Nodes; 4) Logic and Control Nodes; 5) Code and Template Nodes; 6) Tool and Integration Nodes. These nodes extend the platform’s capability enabling workflows to interact with external services, databases or tools. Formally, a workflow is defined as: \[W = (N, E)\] where \(N = \{n_1, n_2,...,n_m\}\) is the set of nodes, \(E \subseteq N \times N\) denotes control dependencies between nodes, determining the execution order and information flow.

Each node \(n_i\) is defined as: \[n_i = (I_i, T_i,C_i)\] where \(I_i\) represents the node name, \(T_i\) is node type and \(C_i\) is its configuration. The configuration determines the runtime action of the node and varies across different node categories. For example, LLM nodes contain prompts and model parameters; retrieval nodes specify knowledge sources and retrieval strategies; tool nodes define tool selections and invocation parameters; and code nodes contain executable scripts. During workflow execution, nodes transform incoming information (\(V^{in}\)) into output (\(V^{out}\)) based on their configurations and propagate the output to downstream nodes: \(V^{out} = C_i(V^{in})\).

3 Approach↩︎

3.1 Overview↩︎

We propose FlowFixer, an agentic workflow automated repair framework leveraging symbolic modeling and inference. As illustrated in Fig. 1, FlowFixer contains two core stages: Failure Diagnosis, which identifies the failure-responsible node (i.e., the root node that leads to the final failure) and the root cause, and Workflow Repair, which generates and verifies repair patches to produce repaired workflows. The two stages are tightly coupled through a “diagnosis \(\leftrightarrow\) repair” loop.

Specifically, FlowFixer first constructs formal behavioral specifications for each workflow node through symbolic modeling and inference. These specifications are statically checked against the observed execution results to identify violations and collect node-level verification evidence. Based on such evidence and workflow structure, FlowFixer locates the failure-responsible node and analyzes its root cause. It then generates repair patches through a set of atomic edit operations and applies them to the original workflow to obtain a modified workflow. The modified workflow undergoes a lightweight pre-execution assessment that reuses the constructed symbolic specifications to efficiently filter infeasible patches before costly dynamic execution. Repair experiences collected during this process are stored and leveraged in subsequent iterations, enabling a continuous diagnosis and repair refinement loop.

3.2 Symbolic Modeling & Inference↩︎

3.2.1 Symbolic Modeling↩︎

When faced with a failed execution trajectory, in order to eliminate the impact of different trajectory formats on different platform and remove redundant information, we define a unified trajectory format based on symbolic representation. FlowFixer normalizes theses trajectories into a sequence of nodes, \(\{node_1, ..., node_n\}\), each node consists of id, type, input & output, status, configuration contexts and parameters, as shown in the “Input” part in Fig. 2. All nodes are assembled in execution order to form a standardized trace with a unified symbolic format.

3.2.2 Symbolic Inference↩︎

For each node in the trace, FlowFixer infers its formal behavioral specifications that characterize the expected behaviors of the node and interactions with the rest of the workflow. These specifications are derived from three complementary dimensions that reflect the fundamental correctness requirements of these agentic workflows: existence, temporal and causal constraints. These dimensions are chosen because workflow failures typically manifest as missing or malformed workflow entities, invalid data/control dependencies, incorrect execution ordering, or causal propagation of upstream errors to downstream symptoms.

Specifically, existence constraints check whether necessary fields, inputs, outputs and configuration elements are present. Temporal constraints ensure that node executions follow semantically meaningful orders required by the task, such as retrieving information before summarization or validating inputs before tool invocation. Causal constraints characterize the expected semantic relationships among workflow entities, including variable consistency, interface compatibility, task-specific requirements, and causal dependencies between upstream and downstream behaviors. For example, generated travel schedules should satisfy budget limits and duration requirements specified by the task.

This three-dimensional decomposition enables FlowFixer to infer from local node validity to workflow-level failure propagation. It also provides structured diagnosis signals for subsequent failure attribution and repair, enabling more systematic identification and localization of underlying failure sources.

FlowFixer uses an LLM-based specification generator to synthesize node-wise behavioral specifications. Given each node’s context, inputs and outputs, workflow connections and the overall task goal, the generator translates the expected node behavior into formal constraints along the three dimensions described above.

A lightweight assertion-based DSL [32], [33], summarized in Table 1, is adopted as the format for inferred specifications. It expresses each constraint as a top-level assertion assert Pred, where predicates are constructed from Boolean connectives, comparison operators, and field or method access to workflow entities. For example, existence constraints can check required fields through expressions such as node.output != None; temporal constraints can compare execution order using order comparisons such as < or >; and causal constraints can combine multiple predicates with if, or, and not to to help determine whether logical relationships are satisfied between nodes.

Fig. 2 presents an example of the specification inference process. For the Generate_itinerary node, the inferred specifications involve several constraints: Existence constraints require the generated itinerary cannot be empty (A1); temporal constraints require Generate_ itinerary node must execute after the upstream node (Travel_guide) has completed its operations (A6); and causal constraints ensure consistency with user-provided inputs such as the budget and schedule (A3, A4, A5) while providing necessary itinerary information such as flight details (A2).

3.3 Stage 1: Failure Diagnosis↩︎

This stage aims to localize failure-responsible node and identify the underlying root causes of a failed trajectory.

3.3.1 Failure Attribution↩︎

Given the formal behavioral specifications obtained from symbolic inference, FlowFixer compares them against the actual outputs of each node. By evaluating whether the observed node behaviors satisfy the inferred specifications, it can identify violated behavioral requirements.

For each node, we calculate a suspicious score indicating its contribution to the final failure. The score combines two sources of factors: (1) behavioral abnormality revealed by assertion violations and (2) the node’s potential influence on downstream executions. Specifically, nodes with higher assertion violation rates are more likely to exhibit anomalous behavior and are thus assigned higher suspicious scores. However, assertion violations alone are insufficient because failures may propagate through workflow dependencies and cause downstream nodes to appear abnormal. To account for this effect, we additionally consider the structural position of a node as its potential propagation impact. Nodes located earlier in the workflow can influence a larger portion of subsequent executions and are therefore more likely to be the origin of failures. By combining assertion violations with propagation characteristics, FlowFixer prioritizes nodes that are both highly abnormal and capable of explaining downstream failure symptoms.

3.3.2 Root Cause Analysis↩︎

The module maps node failures to corresponding root causes (e.g., poor prompt design) and generates structured failure data covering root cause and failure responsible node.

To make root cause analysis more targeted and systematic, FlowFixer constructs a root cause taxonomy from prior studies on agent and workflow failures [28], [34]–[36], as summarized in Fig. 4. It contains sixteen root cause types with their detailed description grouped into node capability, node orchestration, and node execution, and serves as structured prior knowledge for interpreting failure symptoms. Given the failure-responsible node identified by failure attribution, FlowFixer feeds its symbolic context, inferred behavioral specifications, and assertion verification results (include both satisfied and violated assertions) into the analysis module, to produce the root cause type.

3.4 Stage 2: Workflow Repair↩︎

Given the failure information from Stage 1, the second stage generates, verifies, and applies repair patches to the workflow.

3.4.1 Repair Patch Generation↩︎

This module aims to generate repair patches that directly address the failure root cause.

To make patch generation targeted rather than exploratory, FlowFixer introduces root-cause-aware repair knowledge, which maps each diagnosed root cause to a corresponding repair strategy, as shown in Fig. 4. These strategies do not directly specify concrete workflow edits. Instead, they guide patch generation by restricting the search space to modifications that are causally relevant to the diagnosed failure. Similar to the root cause taxonomy, this repair knowledge is summarized from prior studies on agent and workflow failures, and platform-specific repair practices [34], [37], [38].

Based on this knowledge, FlowFixer first determines the repair direction for the diagnosed failure. For instance, poor prompt design is addressed through prompt constraint enforcement, response format errors through format validation and interface alignment. Guided by the selected repair strategy, FlowFixer performs patch planning using the failure-responsible node, its symbolic context, violated behavioral specifications, and upstream/downstream dependencies. To represent concrete modifications, FlowFixer defines five atomic edit operators:

• Insert. Insert a new node or node configuration into the workflow at a specific position to supplement missing logic or data processing steps.

• Remove. Remove redundant, wrong, or unnecessary nodes and node configurations from the workflow to eliminate invalid execution branches.

• Replace. Replace an existing faulty node or node configuration with a correct or more appropriate alternative to fix functional or semantic errors.

• Append. Add a new node or node configuration to the end of the workflow to extend execution logic or supplement post-processing steps.

• Swap. Exchange the execution order of two nodes to correct causal or sequential errors in the workflow.

A repair patch is represented as: \[\text{Patch} = \{ \text{edit}_1, \text{edit}_2, \dots, \text{edit}_k \},\]

where each edit can be instantiated as:

\[\text{edit} = op(target, content, position)\]

Here, \(op\) is one of the atomic edit operators, \(target\) is the workflow component to be modified, \(content\) is the newly inserted or replacement content, and \(position\) specifies where the edit should be applied. After generation, the patch is applied to the original workflow to produce a modified workflow.

3.4.2 Pre-execution Assessment↩︎

To minimize verification costs by eliminating problematic workflows before actual execution, FlowFixer performs workflow assessment from four different perspectives.

Structural Correctness ensures that the workflow can be correctly parsed and executed without structural errors such as missing nodes, invalid connections, or malformed node configuration information. The assessment criteria are directly derived from the workflow platform specifications and node definitions. These predefined structural rules ensure that the repaired workflow conforms to valid workflow syntax and execution constraints.

Semantic Correctness verifies whether the repaired workflow satisfies both node-level functional requirements and task-level semantic objectives. For this assessment, FlowFixer first masks the actual configurations of the modified nodes and provides the LLM with the formalized workflow representation (mentioned in Sec. 3.2.2) and the task description, which jointly specify the execution context of the modified nodes and the overall semantic objective. Based on these information, LLM infers the expected configuration specifications for the modified nodes and subsequently compares them against the nodes’ actual configurations in the repaired workflow to assess semantic correctness.

Behavioral Consistency assesses whether the generated repair actions are aligned with the diagnosed root cause and the behavior specifications. FlowFixer first summarizes the repair patch into a high-level description and then provides the diagnosed root cause and the violated behavioral specification to LLM. Based on these information, it reasons whether the proposed modifications are causally relevant to the identified failure causes and are expected to address the violated specifications rather than introducing unrelated changes.

Offset Rationality evaluates whether the modification magnitude of the original workflow caused by the repair patch is within a reasonable threshold. The modification should neither be excessively large (which may introduce new defects or deviate from the original workflow logic) nor excessively small (which may fail to effectively fix the identified root cause).

3.4.3 Dynamic Verification and Iterative Loop↩︎

Patches that pass pre-execution assessment proceed to dynamic verification, where the modified workflow is executed against the original test inputs. If the workflow executes successfully, the patch is accepted as the final repair.

If the generated repair fails the verification stage, FlowFixer does not immediately terminate the repair process. Instead, it will retry to generate new patch or the workflow is fed back into the failure diagnosis stage. The diagnosis-repair cycle continues until either a valid repaired workflow is obtained or the retry budget is exhausted. If the retry count exceeds the test budget, the workflow is regarded as a failed repair. The corresponding diagnosis and repair experiences are still recorded in the experience pool to support future debugging and repair tasks.

3.5 Experience Pool↩︎

To improve long-term performance, FlowFixer maintains an Experience Pool that stores execution information and summarized repair knowledge:

Online Repair Feedback: feedback collected during the current repair process, such as pre-execution assessment results, applied repair operations, and execution trajectories of modified workflows.

Accumulated Repair Experience: knowledge distilled from historical cases, such as recurring failure patterns, root-cause associations, effective repair strategies, and lessons from failed attempts.

After each repair cycle, FlowFixer stores both online repair feedback and accumulated repair experience in the experience pool. When subsequent failures occur, relevant records are retrieved as auxiliary knowledge. Online repair feedback serves as short-term memory within the current repair process, capturing the outcomes of previous repair attempts and helping the framework avoid repeating ineffective modifications. In contrast, accumulated repair experience serves as long-term knowledge distilled from historical cases, providing reusable insights into recurring failure patterns, root-cause associations, and effective repair strategies. Together, they support both failure diagnosis and repair generation in future repair iterations.

4 Experiment↩︎

4.1 Research Questions↩︎

We consider the following research questions:

RQ1: (Repair Effectiveness) Can FlowFixer effectively repair failures for agentic workflow?

RQ2: (Diagnosis Effectiveness) Can FlowFixer effectively conduct failure attribution and identify root cause?

RQ3: (Ablation Study) Can each designed component in FlowFixer contribute to failure diagnosis and repair?

4.2 Dataset↩︎

We adopt the publicly available AgentFail[34] dataset as the primary experimental benchmark for our evaluation, which consists of 307 annotated failure logs collected from 10 real-world agentic systems built on popular workflow orchestration platforms, Dify and Coze. It covers diverse task domains such as information retrieval, task planning, and code generation, and each data record contains complete execution trajectories, original workflow configurations and fine-grained expert annotations of root causes of the failures.

To further increase the diversity of workflow platforms and failure patterns, we additionally collect 136 failure cases from the n8n platform[4], covering various tasks, including information retrieval, task planning and automated design assistant. Similarly, each collected case contains the workflow configuration, execution trajectory and manually annotated root causes, following the annotation pipeline in AgentFail.

In the subsequent result and analysis section, we merge the results from two datasets since the methods have similar results on the datasets.

4.3 Baselines↩︎

To evaluate the workflow repair performance, we choose six methods as baselines which can be divided into two categories.

The first category focuses on traditional program repair: 1) SWE-agent [15], which is a popular agent resolving issues in software code repositories. 2) RepairAgent [17] treats the LLM as an agent capable of autonomously planning and executing actions to fix bugs by invoking tools. The second category focuses on bug repair for agents or agent evolution and enhancement: 3) Recreate [21] is based on the complete interactive experience of agents. It uses reasoning to identify the causes of success or failure and modifies agent’s architecture. 4) GEPA [39] enables LLM to directly read and reflect on the trajectories during the task execution, thereby facilitating more efficient learning. 5) Scope [20] achieves the agent’s prompt evolution by balancing tactical specificity (resolving immediate errors) with strategic generality (evolving long-term principles). 6) SelfHeal [37] consists of fix agent and critic agent, leveraging fix rules and web search to automatically repair agent bugs.

Furthermore, to evaluate the failure attribution performance of FlowFixer (Stage 1), we select representative methods for trajectory failure attribution as baselines for comparison: 1) FAMAS [40] locates the responsible agents through trajectory replay and spectrum analysis. 2) Dover [41] is an intervention-driven debugging framework, which augments hypothesis generation with active verification through targeted interventions. 3) AgentFixer [38] constructs fifteen failure-detection tools and two root-cause analysis modules.

4.4 Evaluation Metrics↩︎

To comprehensively evaluate the performance of FlowFixer in workflow repair and failure diagnosis, we use the following three metrics:

Repair Success Rate (RSR): The ratio of cases where the modified workflow passes the dynamic verification.

Failure Attribution Accuracy (FAA): The ratio of cases where the method correctly locates the specific node to the total number of failure cases.

Root Cause Accuracy (RCA): It refers to the proportion of cases in which the root cause is correctly identified among the cases where failure attribution is correctly predicted.

4.5 Experiment Setup↩︎

The Overall Setup. In all experiments, we use FlowFixer and baselines to respectively repair workflows in the experimental dataset. For each case in dataset, repair process is repeated three times to avoid randomness, and the average performance is presented. All experiments are conducted on a server with an Intel Xeon E5-2690 v4 CPU, 128GB RAM, and an NVIDIA A100 GPU. For the LLM involved in FlowFixer, we adopt GPT-5.2 as the backbone model.

For RQ3, we assess the effectiveness of designed component, including symbolization, external knowledge and the experience pool. The detailed settings of variants are as follows:

• w/o symbol: This variant performs failure diagnosis and workflow repair based on the original raw trajectory.

• Variants related to external knowledge: We evaluate three variants by progressively removing external knowledge sources. w/o Taxonomy removes the predefined root cause taxonomy during diagnosis, w/o Repair removes the repair knowledge used for patch generation, and w/o External removes both components, disabling all external knowledge throughout the diagnosis and repair process.

• Variants related to the experience pool: We further evaluate the contribution of the experience pool through three variants. w/o Feedback removes online repair feedback, preventing iterative optimization between diagnosis and repair. w/o Experience removes accumulated repair experience while retaining online repair feedback. w/o Pool removes both components, relying solely on the execution trajectory for failure diagnosis and repair.

5 Results and Analysis↩︎

5.1 RQ1: Repair Effectiveness of FlowFixer↩︎

Table 2 presents the overall performance comparison between FlowFixer and the baselines on workflow repair (column 2). Overall, FlowFixer consistently achieves the best performance, demonstrating the effectiveness of symbolic inference-guided workflow repair.

FlowFixer achieves a repair success rate of 71.3%, substantially surpassing SWE-agent (43.7%) and RepairAgent (51.2%), yielding absolute improvements of 27.6% and 20.1%, respectively. This result indicates that directly applying program repair techniques designed for traditional software systems is insufficient for agentic workflows, whose failures often arise from unpredictable outputs and complex interactions between workflow structures, rather than deterministic code defects.

FlowFixer also consistently outperforms agent enhancement methods. Compared with each baseline, FlowFixer improves repair success rates by 11.9% (ReCreat), 12.5% (GEPA), 18.4% (Scope), and 15.9% (SelfHeal), respectively. Although these methods leverage self-reflection, prompt refinement, or iterative improvement mechanisms, they primarily focus on enhancing overall agent performance rather than explicitly diagnosing workflow failures. Such approaches lack explicit modeling of workflow semantics and causal relationships, limiting their ability to accurately identify root causes and generate targeted repair solutions. Consequently, they often make blind modifications without accurately identifying the specific workflow components responsible for the failures. Moreover, these methods mainly improve agent performance through prompt optimization, while many issues originate from node configurations, or inter-node dependencies, which cannot be effectively repaired through prompt modifications alone.

Overall, these results demonstrate that symbolic modeling & inference jointly enable FlowFixer to generate more precise and effective repairs for complex agentic workflows.

5.2 RQ2: Diagnosis Effectiveness of FlowFixer↩︎

Table 2 also presents the performance about failure diagnosis. Since FAMAS and DOVER only locate nodes that introduce failures without further analyzing underlying root causes, these two methods can only be evaluated in terms of FAA and do not support RCA calculation.

FAMAS achieves only 51.3% FAA, substantially lower than the 84.4% achieved by FlowFixer. As a spectrum-based fault localization approach, FAMAS identifies suspicious execution steps according to the correlation between failures and execution traces. It lacks an understanding of workflow semantics and cannot infer the functional roles of workflow nodes or the dependencies between them. Although DoVer leverages intervention-based execution analysis to achieve good failure attribution performance (79.6%), it relies on repeatedly modifying and replaying agent behaviors to estimate causal effects, incurring substantial computational overhead. Moreover, FlowFixer consistently outperforms DoVer, indicating that precise failure attribution can be achieved without resorting to costly intervention-based analysis. AgentFixer achieves 66.8% FAA and 62.1% RCA. This is because, although it diagnoses agent failures from multiple perspectives and offers valuable insights into their root causes, its analysis operates primarily at the trajectory level; it relies on the overall execution trajectory rather than performing fine grained reasoning focused on workflow nodes and their semantic dependencies.

5.3 RQ3: Ablation Study↩︎

Effect of Symbolization. Removing symbolization causes substantial performance degradation across all three tasks, with repair success rate dropping by 24.3%, failure attribution accuracy by 24.6%, and root cause analysis accuracy by 29.6%. This result demonstrates that symbolic modeling and symbolic inference provide the foundation for accurate failure diagnosis and workflow repair by making workflow semantics and inter-node dependencies explicitly analyzable.

Effect of External Knowledge. We progressively remove the root cause taxonomy, repair knowledge, and both components. The results show that the root cause taxonomy mainly contributes to accurate root cause analysis, whose removal reduces RCA by 33.5%. In contrast, repair knowledge primarily improves repair generation, and removing it decreases the repair success rate by 11.1%. Together, they bridge failure diagnosis and workflow repair, enabling FlowFixer to translate diagnosed failure causes into effective repair strategies.

Effect of Experience Pool. We further evaluate the contributions of online repair feedback, accumulated repair experience, and the entire experience pool. The results indicate that the two components play complementary roles. Online repair feedback enables iterative refinement between diagnosis and repair, and removing it decreases the repair success rate by 17.1%. In contrast, accumulated repair experience provides reusable knowledge from historical cases, and removing it reduces failure attribution accuracy by 21.9%. Together, they enable FlowFixer to continuously refine failure diagnosis and generate more effective repair strategies through experience-guided repair.

6 Case Study↩︎

Fig. 5 and 6 illustrate two examples, in which the first example focuses on the process of symbolic modeling and inference; The second one focuses on demonstrating the process of generating the patch and verifying modified workflow.

Diagnosis Case. This workflow is for generating a summer travel itinerary for Iceland. However, the final output contains activities that are unsuitable for summer travel and lacks hotel-related information.

In the failure diagnosis, FlowFixer performs symbolic modeling and inferring for each node. Taking the “Problem Decomposition” node as an example, FlowFixer derives that its formal behavioral specifications should require: the generated sub-tasks should include location information; adhere to user-specified time constraints; and cover essential travel-related elements such as hotel planning.

By verifying these specifications against actual output, FlowFixer identifies multiple violations, including missing time constraints (the summer travel period) and the absence of hotel-related sub-tasks. Combining these violation evidences with the workflow, FlowFixer attributes the failure to the “Problem Decomposition” node and identifies the root cause as “Poor Prompt Design” as the prompt fails to instruct the model to preserve critical travel constraints during task decomposition.

Guided by the diagnosed root cause and the corresponding repair strategy, FlowFixer generates a repair patch consisting of atomic workflow edits. In this example, the repair removes the original decomposition prompt and appends additional instructions requiring the model to explicitly consider user-specified feasibility factors and travel constraints. FlowFixer then produces a modified workflow based on the patch and submits it to the assessment and verification stage.

Repair Case. This workflow implements a Q&A assistant. However, when users provide inputs with an invalid format or excessively long queries, the workflow lacks an input validation mechanism, causing downstream nodes to receive unexpected inputs and ultimately leading to a crash.

Guided by the corresponding repair strategy, FlowFixer first generates a repair patch by inserting a validation node immediately after the “Begin” node. After applying the patch, the pre-execution assessment analyzes the modified workflow and detects a structure violation: the upstream dependency of the “Classification” node has not yet been changed from “Begin” to the newly inserted “Checker” node, breaking the expected workflow structure. Consequently, this repair candidate is rejected before expensive dynamic execution.

FlowFixer then generates a new repair patch by inserting “Checker” between “Begin” and “Classification”, preserving the original execution dependencies while introducing the required input validation. The repaired workflow successfully passes the pre-execution assessment and is subsequently verified through dynamic execution, producing a valid repaired workflow.

7 Discussion↩︎

7.1 Effectiveness of Pre-execution Assessment↩︎

In this section, we evaluate whether the proposed pre-execution assessment can accurately identify wrong repair candidates before costly dynamic execution. We compare its assessment results (pass/fail) with the corresponding dynamic execution results to measure its ability to filter out invalid workflows while retaining correct repair candidates. We use Precision and Recall to evaluate the effectiveness of pre-execution assessment: Precision quantifies the accuracy of pre-execution failure assessment, Recall reflects the detection coverage of real wrong workflows.

Experimental results show that pre-execution assessment module achieves a 99.7% Precision, indicating that almost all workflows identified as wrong by the assessment indeed fail during dynamic execution. This demonstrates that the assessment can effectively filter out low-quality repair candidates with very few false alarms, thereby avoiding unnecessary execution costs caused by obviously incorrect workflows.

The assessment further achieves a Recall of 84.6%, suggesting that the majority of invalid workflows can be detected before execution. Nevertheless, a small portion of failures remain undetected. These cases typically involve model capability limitation or external tool invocation that cannot be fully revealed through static assessment alone and only manifest during actual workflow execution.

These results indicate that FlowFixer can effectively eliminate most invalid repair candidates prior to dynamic validation while retaining correct workflows, substantially reducing the cost of workflow repair and verification.

7.2 Repair Condition Analysis↩︎

We further analyze the repair patches generated by FlowFixer from the perspectives of repair operators and modified workflow nodes, as shown in Fig. 7.

Repair Operators. We can observe that Remove (35%) is the most frequently used operator, Append (22%), Replace (21%), and Insert (18%) are also widely adopted, while even Swap (4%) is required in a subset of repairs. Rather than relying on a single editing strategy, FlowFixer employs diverse repair operators to accommodate different failure scenarios. This observation suggests that repairing agentic workflows is inherently complex and requires flexible combinations of workflow modifications, instead of being addressed through a single type of repair operation.

Repaired Nodes. LLM & Agent Nodes account for the largest proportion of repairs (47%), followed by Code & Template Nodes (20%), Knowledge Nodes (15%), Logic & Control Nodes (11%), and Tool Integration Nodes (7%). The repaired nodes are distributed across all major workflow components, indicating that failures can arise from diverse parts of agentic workflows rather than being concentrated in a single node category. This result highlights the necessity of diagnosis and repair techniques that can reason over heterogeneous workflow components and support diverse repair operations.

7.3 Repair Cost↩︎

We further evaluate the computational cost of FlowFixer by measuring the average token consumption throughout the repair process. Among the repair methods, Scope incurs the lowest cost at around 14K tokens per repair, while SWE-agent has the highest cost at approximately 38K tokens. In comparison, FlowFixer requires 17K tokens on average, indicating a competitive computational overhead. The relatively low overhead of FlowFixer is largely attributed to the proposed pre-execution assessment module, which filters out infeasible repair candidates before workflow execution. By eliminating low-quality modifications in advance, FlowFixer avoids unnecessary workflow execution and reduces the overall repair cost. We also observe that the remaining overhead mainly comes from symbolic inference and iterative repair retries. In future work, we plan to try more efficient framework (such as symbolic inference techniques combined with inference caching) to further reduce cost while maintaining repair effectiveness.

8 Related Work↩︎

8.1 Agent Enhancement↩︎

With the widespread application of agents, some new tasks have emerged, aiming to enhance the capabilities of these agents specifically to address the failures they encounter in practical applications. Existing agent enhancement techniques can be generally categorized into three mainstream paradigms: structural & workflow enhancement [22], [23], [42], [43], agent internal enhancement[20], [21], [44] and runtime & supervisory optimization[24], [25].

The first category aims to enhance system robustness by optimizing the external architecture: Aegis[22] aimed to improve agent-environment observability and computation offloading; Maestro [23] optimized workflow graphs and agent configurations guided by trajectory feedback; CE-Graph [42] refined workflows based on failure distribution to avoid repeated errors. The second line upgrades the agent’s intrinsic capabilities: SCOPE[20] achieved online prompt evolution to balance error correction and long-term strategy improvement; AgentDevel[44] formalized self-improvement as a release-like pipeline with diagnostic scripting and gating mechanisms; ReCreate[21] constructed domain agents by extracting experience from successful and failed trajectories. The last line enhances stability during execution: AgentDiet[24] compressed redundant trajectory information to improve efficiency; SUPERVISORAGENT[25] added a lightweight supervisor to proactively correct misbehavior and purify observations.

8.2 Failure Attribution↩︎

Failure attribution is the cornerstone of diagnosing and improving LLM-based agent systems. Deshpande et al.[45] introduced a dataset and error taxonomy for evaluating agent traces, showing that current LLMs failed significantly at automated debugging. Current research on failure attribution in LLM-based agent systems can be broadly categorized into four types: pattern-based analysis[40], [46], [47], LLM reasoning-based methods[19], [48], [49], model fine-tuning techniques[50]–[52], and intervention-based methods[28], [41], [53].

For pattern-based methods, FAMAS[40] is a spectrum-based failure attribution technique that ranks the suspiciousness of agents based on their occurrence patterns in successful versus failed executions. For the second category, Who&When[19] is a representative approach that employs prompting strategies such as all-at-once and step-by-step reasoning to identify the responsible agent and failure step directly from execution logs. In model fine-tuning-based methods, AgenTracer[50] constructs a dedicated failure attribution dataset through fault injection and counterfactual replay, and fine-tunes a lightweight model to recognize error propagation patterns and localize failures efficiently. As a dynamic intervention-based method, DoVer[41] formulates failure attribution as an intervention-driven debugging process, validating attribution hypotheses by modifying intermediate states and observing whether the failure can be eliminated.

9 Conclusion↩︎

This paper presents FlowFixer, a diagnosis-driven automated repair framework for platform-orchestrated agentic workflows. By combining symbolic modeling and symbolic inference, FlowFixer enables accurate failure diagnosis and targeted workflow repair. Experimental results on real-world workflow failures show that FlowFixer consistently outperforms existing repair and diagnosis approaches in terms of repair success rate, failure attribution accuracy, and root cause analysis accuracy. These results demonstrate the effectiveness of diagnosis-driven symbolic inference for improving the reliability and maintainability of agentic workflows.

References↩︎