MAS-FIRE: Fault Injection and Reliability Evaluation for LLM-Based Multi-Agent Systems

• Natural-language coordination permits hallucinations, ambiguous interpretations, and reasoning drift to propagate silently without runtime exceptions.Source: §1 · p. 1
• Outcome-only evaluation obscures how failures arise and whether agents self-correct or stall, leaving robustness improvement trial-and-error.Source: §1 · pp. 1–2
• MAS-FIRE evaluates 15 intra-agent and inter-agent fault types using non-invasive prompt, response, and message-routing perturbations.Source: §1 · p. 2
• Advanced models can be more vulnerable to prompt-level corruption despite excelling at semantic reasoning.Source: §1 · p. 2
• Iterative, closed-loop topologies neutralize over 40% of faults that dismantle linear, waterfall-style workflows.Source: §1 · p. 2

2.1 LLM-Based Multi-Agent Systems as Intelligent Software

• Specialized agents use planning, memory, and tool execution to divide complex, long-horizon problems beyond one model instance’s capacity.Source: §2.1 · p. 3
• Natural-language coordination makes conversation history part of system state, while topology shapes information flow and logical consistency.Source: §2.1 · p. 3

2.2 Fault Injection and the Reliability of MAS

• Fault injection deliberately introduces perturbations to accelerate rare failure modes and test whether local faults cascade into system failures.Source: §2.2 · p. 3
• MAS failures often appear as silent semantic deviations, and small perturbations can produce context-dependent outcomes in non-deterministic agents.Source: §2.2 · p. 3

• The framework uses controlled fault injection to evaluate MAS robustness through a grounded taxonomy of intra-agent and inter-agent failures.Source: §3 · p. 3
• Non-invasive injection uses prompt modification, output interception and rewriting, and message-routing manipulation to simulate anomalies during execution.Source: §3 · p. 3
• Quantitative robustness metrics assess both overall system resilience and the effectiveness of specific fault-tolerance behaviors.Source: §3 · p. 3

3.1 MAS Fault Taxonomy

• The taxonomy groups faults into seven high-level categories according to where they arise in MAS execution.Source: §3.1 · p. 3

3.1.1 Intra-agent Faults.

• Intra-agent faults affect planning, memory, reasoning, or action, including faulty plans, information loss, hallucinations, and invalid tool interactions.Source: §3.1.1 · p. 3

3.1.2 Inter-agent Faults.

• Inter-agent faults include flawed roles or dependencies, conflicting or ambiguous instructions, and abnormal message passing such as duplication or cycles.Source: §3.1.2 · pp. 3–4
• Figure 2 illustrates instruction conflict, parameter-filling error, and message storm injections, alongside examples of robust recovery and failure.Source: Figure 2 · p. 4

3.2 Fault Injection Mechanism

• MAS-FIRE operationalizes seven high-level categories as 15 injectable fault types, using prompt modification, response rewriting, and message routing manipulation.The mechanisms target prompts, runtime outputs, and message flows, respectively.Source: §3.2 · p. 4

3.2.1 Prompt Modification.

• Prompt modification corrupts system or user directives to inject configuration faults and flawed task specifications.Examples include conflicting roles, unconditional trust, incompatible constraints, and ambiguous instructions.Source: §3.2.1 · pp. 4–5

3.2.2 Interception and Response Rewriting.

• Runtime interception uses semantic-level mutations to preserve coherent wording while corrupting planning, reasoning, or tool-use correctness.Mutations include invalid plans, information loss, hallucinations, incorrect tool selection, and altered parameters.Source: §3.2.2 · p. 5
• Structure-level mutations alter message payloads or data structures directly, including truncated memory, over-compressed context, and malformed tool calls.Unlike semantic mutations, these transformations operate on syntactic structure without LLM assistance.Source: §3.2.2 · p. 5
• Message routing manipulation changes recipients or message frequency without altering content, injecting cycles, storms, and broadcast amplification.These programmatic faults can create repetitive loops, redundancy, or irrelevant messages to other agents.Source: §3.2.3 · p. 5

3.3 MAS Robustness Metrics

• System-level resilience measures task success under fault injection, while process-level effectiveness examines detection, response, and recovery during execution.The paired levels distinguish final outcomes from intermediate behaviors that help explain why systems succeed or fail.Source: §3.3 · p. 5, §3.3.2 · p. 6

3.3.1 System-level Resilience.

• Robustness Score (RS) measures the fraction of fault-free solvable tasks that remain successful under a specified fault.A high RS indicates maintained functionality despite the fault.Source: §3.3.1 · p. 5

3.3.2 Process-level Effectiveness.

• Occurrence Rate (O_f) measures how often injected tasks trigger fault detection and at least one fault-tolerant response.A low O_f suggests silent fault propagation without defensive responses, often leading to cascading failures.Source: §3.3.2 · p. 6
• Local Success Rate (L_f) measures whether triggered fault-tolerant behavior corrects the immediate injected fault.A low L_f indicates systems may recognize faults but lack appropriate recovery strategies.Source: §3.3.2 · p. 6
• Success Rate (S_f) measures whether local recovery among triggered tasks translates into eventual task completion.The gap between L_f and S_f captures cases where local correction does not overcome residual effects or downstream errors.Source: §3.3.2 · p. 6

4 MAS Robustness Evaluation

• The evaluation investigates fault impacts, model capability, and the fault-tolerant behaviors that emerge in multi-agent systems.Its process-oriented analysis examines how systems detect, respond to, and recover from faults, rather than only whether tasks succeed.Source: §4 · p. 6

4.1.1 System Selection and Task Datasets.

• MetaGPT, Table-Critic, and Camel represent sequential, iterative critic-refiner, and bilateral role-playing architectures across code, table-reasoning, and e-commerce tasks.The benchmarks are HumanEval, WikiTableQuestions, and WebShop; WikiTableQuestions uses a random sample of 400 from 4,344 instances.Source: §4.1.1 · p. 6

4.1.2 Fault Injection and Log Collection.

• Each task is run under controlled fault injection, and the collected logs span fault types, architectures, models, and benchmark difficulty levels.GPT-5 and DeepSeek-V3 are compared, with GPT-5 reported to outperform DeepSeek-V3 in baseline success rates across all systems; the fault-injection success rate is 99%.Source: §4.1.2 · pp. 6–7

4.2 Fault-Tolerant Behavior Analysis

• Researchers derive fault-tolerant behavior categories from execution logs through independent coding and iterative refinement until saturation.A GPT-5 annotation pipeline labels unseen logs, with Cohen’s Kappa of 0.94 against human annotations on a held-out validation set.Source: §4.2 · p. 7

5.1.1 Impact of Intra-Agent Faults.

• Shared pools mitigate Memory Faults (ΔR_Sf≈+25%), critique loops mitigate Planning Faults (ΔR_Sf≈+45%), and environmental feedback yields R_Sf>90% for two action errors.The two errors are Parameter Filling and Tool Format; retry logic also supports recovery from tool failures.Source: §5.1.1 · p. 7

5.1.2 Impact of Inter-Agent Faults.

• Configuration and instruction faults can drive robustness as low as 0.0%, with linear workflows vulnerable to cascading failures while iterative structures mitigate impact.Table-Critic's iterative loop maintains 91.05% (DeepSeek-V3) and 79.31% (GPT-5) under Role Ambiguity.Source: §5.1.2 · p. 8, Figure 3 · p. 8
• Communication faults are least destructive, with MetaGPT consistently above 93% robustness; role-based filtering, deduplication, and cycle detection provide infrastructure-level defenses.Other architectures were excluded from these faults because they lack a communication module.Source: §5.1.2 · p. 8

5.2 RQ2: Role of Foundation Model Capability

• Model capability gains depend on architecture: GPT-5 reaches RS 45.34% versus DeepSeek-V3's 23.29% for Hallucination, while systems without shared context gain less.The paper also reports GPT-5 at 55.90% versus DeepSeek-V3 at 43.84% for Inexecutable Plan faults.Source: §5.2 · p. 9

5.3.1 Behavioral Taxonomy and Fault Tolerance Dimensions.

• Observed fault responses vary with available feedback and safeguards, including clarification requests, message filtering, prompt-based role realignment, and cross-agent correction.The paper groups resilience sources into mechanism, rule, prompt, and reasoning tiers.Source: §5.3.1 · p. 9, Table 2 · p. 10

5.3.2 Empirical Evaluation of Fault Tolerance Tiers.

• Prompt-level fault tolerance activates universally for configuration faults, but recovery varies: Role Ambiguity success ranges from 24%–32% in MetaGPT to 79%–91% in Table-Critic.Under Blind Trust, Camel and MetaGPT reach 0.0% success; Table-Critic ranges from 6.32% to 71%.Source: §5.3.2 · p. 11
• For tool-related errors, all systems show occurrence rates of at least 85%, local recovery of 100%, and final task success above 61%; MetaGPT's rule-based defenses reach 100% detection and recovery for structural faults.Figure 4 visualizes fault-tolerance performance across the fault types; the rule-based result applies to communication faults and context-length violations in MetaGPT.Source: §5.3.2 · p. 11, Figure 4 · p. 12
• For Hallucination, Instruction Logic Conflict, and Instruction Ambiguity, reasoning-level fault tolerance activates at 100% across systems, while mechanism-level detection is often limited or absent.Instruction Logic Conflict mechanism-level detection is 0.0% for most systems; only MetaGPT with GPT-5 reaches 18%.Source: §5.3.2 · pp. 11, 13

6.1 Treat Upstream Instructions with Caution

• Under Blind Trust, GPT-5’s R_Sf was 6.32%, versus 70.61% for DeepSeek-V3; superior instruction-following led to near-total collapse.The results challenge the assumption that strict adherence to upstream instructions is always beneficial under faults.Source: §6.1 · p. 13
• Agents should use conditional compliance, pausing or flagging instructions that contain contradictions, constraint violations, or conflicting environmental feedback.Cross-validating upstream instructions against their own reasoning is proposed before irreversible actions.Source: §6.1 · p. 13

6.2 Avoid Failure Propagation in Linear Agent Workflow

• Under Configuration and Instruction Faults, MetaGPT’s linear pipeline fell to R_Sf as low as 0.0%, while Table-Critic’s iterative closed loop maintained significantly higher robustness.A single corrupted output can propagate downstream unchecked, while repeated validation and correction cycles provide a contrast.Source: §6.2 · p. 13
• Multi-source validation and inline verification checkpoints can detect inconsistencies before action and trigger re-execution when anomalies arise.These measures add error-correction benefits while preserving the interpretability of linear workflows.Source: §6.2 · p. 13

7.1 Fault Injection and Chaos Engineering

• MAS failures can be semantic deviations that leave systems operational while logically decoupling them from their intended tasks.Traditional fault injection and mutation testing instead focus on low-level syntactic corruptions.Source: §7.1 · p. 13
• A system may reach superficial consensus even when its reasoning has drifted into a hallucinated state and its output is logically invalid.Source: §7.1 · p. 13

7.2 MAS Evaluation Frameworks

• Sub-goal tracking moves some evaluations beyond binary success, but existing frameworks remain outcome-oriented; OpenJudge’s idealized scenarios lack organizational-resilience stress tests.Source: §7.2 · p. 13

• MAS reliability depends on an interplay between foundation-model reasoning and coordination infrastructure, and model scaling alone does not ensure system stability.Source: §8 · p. 13
• Shared message pools and iterative critique loops can neutralize semantic errors before they propagate into systemic collapse.Source: §8 · p. 13
• MAS-FIRE’s behavioral taxonomy and process-oriented metrics provide a methodology for evaluating, diagnosing, and hardening orchestrated intelligent software.Source: §8 · p. 13