METHODS SUPPLEMENT

Extended methodology

From a communication intervention to an auditable outcome.

This supplement expands the paper’s taxonomy and two-phase fault-injection pipeline. It connects the methodological definitions to implementation snapshots and recorded examples. The framework is broader than the conditions evaluated in any one experiment.

01 · SCOPE OF THE MODEL

A cross-layer taxonomy

The taxonomy draws on established dependability concepts [1] [2] [3] and the representative sources cited in each row.

The construction uses 31 communication standards, protocol specifications and prior studies. From 57 fault and effect descriptions, the researchers consolidate 43 candidate concepts. The team includes one researcher with at least five years of communication-systems experience and two with at least two years of LLM/MAS experience. After a 10-candidate pilot, two researchers independently code source layer, receiver-visible manifestation and downstream MAS consequence. Pre-adjudication Cohen’s κ ranges from 0.79 to 0.86 across the three dimensions. A third researcher resolves disagreements, yielding 29 final categories. Mappings retain source evidence and selected reproducible lower-stack mappings are checked in the testbed.

The seven receiver-visible families are timeliness, availability, semantic integrity, parseability/completeness, multiplicity/idempotency, ordering/freshness and contract validity. The initial dispatch boundary I1 is excluded from the evaluated interventions.

P / D / N / T

Where a lower-stack disturbance originates.

A · Receiver exposure

What changes at the receiving application boundary.

M · MAS consequence

How affected information changes downstream state or behavior.

The mapping is conditional: lower-stack disturbances may be masked, and different sources can produce the same visible symptom. A-layer faults can also originate directly in agent-runtime delivery, ordering, association or structured-message handling. Local model reasoning, parameters, activations and training-state errors are outside this taxonomy.

Coverage boundary. The table is a classification, not a claim that every entry was injected in every benchmark. The 3,780 source-mapping executions comprise 3,600 faulted and 180 clean controlled fixtures; they do not carry MAS task-outcome scores.

Full taxonomy · 29 entries, with linked references

Numbered citations link to full bibliographic entries below.

Layer	Fault / effect	Description	References
P	P-F1 Bit-level corruption	Isolated or burst errors in communicated bits.	[4]
P	P-F2 Link/endpoint interruption	NIC, cable, or power disruption removes a path.	[3] [5]
P	P-F3 Physical-medium interference	Interference degrades reception and delivery timing.	[6]
P	P-F4 Timing instability	Clock drift affects communication timing decisions.	[7]
P	P-F5 Communication-state corruption	Hardware errors affect communication buffers or runtime state.	[8] [9]
D	D-F1 Frame loss/local drop	Frames are not delivered across a local link.	[10] [6]
D	D-F2 Frame corruption/integrity failure	Damaged frames fail integrity checks or escape detection.	[10] [4]
D	D-F3 Duplicate/reordered delivery	Frame order or multiplicity changes.	[11]
D	D-F4 MTU/fragmentation failure	Size handling or reassembly disrupts delivery.	[12]
D	D-F5 Contention/link instability	Contention or flapping delays or interrupts service.	[6]
N	N-F1 Packet loss	Independent or burst loss affects a packet path.	[3] [11]
N	N-F2 Path performance degradation	Delay, jitter, bandwidth limits, or congestion slow delivery.	[13] [11]
N	N-F3 Ordering/multiplicity anomaly	Packets arrive out of order or more than once.	[11]
N	N-F4 Reachability/routing failure	Partitioning, asymmetry, or filtering blocks a path.	[3]
N	N-F5 Endpoint resolution failure	Name resolution prevents endpoint discovery.	[14]
T	T-F1 Connection/session interruption	Reset or interruption breaks an active exchange.	[15]
T	T-F2 Deadline/expiration failure	A delivery or validity budget expires.	[16] [17]
T	T-F3 Retry/retransmission anomaly	Repeated attempts amplify load or logical work.	[15] [18]
T	T-F4 Stream completeness failure	An exchange ends before complete content arrives.	[15] [19]
T	T-F5 Transport pressure/stall	Backlog or flow-control pressure prevents progress.	[13] [15]
A	Timeliness	A logical message arrives late or misses its deadline.	[17] [20]
A	Availability	A required logical message is not delivered.	[20] [21]
A	Semantic integrity	A processable message carries changed or misassociated meaning.	[22] [23]
A	Parseability/completeness	A message cannot be parsed or lacks required content/evidence.	[24] [25]
A	Multiplicity/idempotency	A logical request or delivery is repeated.	[18] [20]
A	Ordering/freshness	The receiver observes displaced, out-of-order, or stale state.	[15] [22]
A	Contract validity	Structured keys, types, schema, or relations violate the expected contract.	[24] [26] [25]
M	System-level consequences	Execution or coordination degrades, e.g., failed delegation or workflow timeout.	[27] [28] [29]
M	Semantic-level consequences	Accepted evidence, plans, beliefs, or decisions degrade.	[27] [23] [30]

02 · PHASE I — FAULT GENERATION

Intercept a concrete communication dependency

Select the task, workflow, model configuration, repetition, operator and parameters. Identify the selected edge, carrier and task/session association. The interceptor acts after sender-side production and before receiver-side consumption:

φ_f,θ(m_t, S_t) → (m′_t, S′_t)

Here m is the carrier and S is the relevant communication/runtime state. Clean runs use the same instrumentation with an identity operation. Provider requests/responses, local model internals and tool semantics are outside the intervention boundary.

I2 · Action request

An upstream instruction or tool request enables subsequent work. Losing it can prevent evidence from being generated.

Inspect: requested action, sending edge, delivery count, downstream work.

I3 · Observation

An environment or tool result returns to the agent workflow. Delayed, displaced or incomplete observations can change available state.

Inspect: tool result, state version, ordering and actual receiver input.

I4 · Evidence handoff

Produced results reach a verifier or decision agent. A fault here changes access to, or interpretation of, existing evidence.

Inspect: evidence carrier, receiver decision, alternate information paths.

Sequential, Flat and Hierarchical workflows and injection boundaries — Paper Figure 3. Workflow boundaries. Click the figure to view the full image.

Step 2/3/4 are abstract dependency types, not necessarily the second/third/fourth event in a trace. Eligibility varies by operator. The common matrix tests I2 and I4. A separate position-extension study evaluates matched I2/I3/I4 conditions; its records and cohorts are analyzed separately.

03 · WHAT WAS CHANGED

Operator implementation and evaluated conditions

The common matrix contains clean plus six condition-position cells. Two cells are non-delivery at different positions; this is not a count of six distinct fault families. Expand a cell for its intervention and exposure check.

Timeliness · I4A handoff exceeds its configured delivery budget and is not delivered.

A handoff exceeds its configured delivery budget and is not delivered.

Exposure check. Inspect deadline_ms and the delivery-event record. Do not infer exposure from elapsed run time alone.

Availability · I2The selected action request is withheld before receiver consumption.

The selected action request is withheld before receiver consumption.

Exposure check. An unreached target is not applied. Trace the work that the missing request would have enabled.

Availability · I4Generated evidence is withheld on the selected downstream handoff.

Generated evidence is withheld on the selected downstream handoff.

Exposure check. Inspect other recorded edges: evidence may remain available through a bypass path.

Semantic integrity · I4Task-critical meaning in a processable evidence carrier is changed.

Task-critical meaning in a processable evidence carrier is changed.

Exposure check. The replacement depends on the domain adapter. Compare original/delivered fields and subsequent use; a parseable message is not necessarily correct.

Completeness · I4A processable carrier retains an answer or partial content while required evidence is removed.

A processable carrier retains an answer or partial content while required evidence is removed.

Exposure check. Inspect the task-specific contract. Missing evidence does not by itself mean the numeric answer is wrong.

Freshness / association · I4Prior-task or prior-session evidence is supplied at the current handoff.

Prior-task or prior-session evidence is supplied at the current handoff.

Exposure check. Inspect task/session/version metadata and actual payload differences. A replay request without prior evidence does not establish changed exposure.

Broader implemented operator inventory

The generic registry also lists delay, timeout, channel interruption, endpoint unavailability, omission, message corruption, malformed JSON, truncation, duplication, reordering, schema mismatch, stale replay, runtime communication-state corruption, message-channel instruction injection and contract violation. Generic scenario handling additionally includes valid-partial and partition-equivalent cases. This inventory is not the main-study evaluation matrix.

Examples from the generic interceptor: truncation keeps the first half of serialized content; malformed JSON creates an unfinished wrapper; schema mismatch renames selected keys; contract violation changes selected field types; valid-partial removes product/evidence keys. These are implementation examples, not universal semantics for every domain adapter.

Generic FaultScenario defaults are delay_ms=1000 and timeout_ms=500. They are constructor defaults, not verified parameter values for every published run. Use each run’s fault_parameters and event records for actual settings.

Operator identifiers distinguish implementation-level interventions. The seven A-layer families classify receiver-visible effects; one family can have several condition–position implementations.

Implementation and analysis sources

The implementation links identify the operators, adapters and analysis routines used by the corresponding studies.

04 · PHASE II — PROPAGATION EVALUATION

Keep exposure, propagation and outcome separate

Variable	Required evidence	What does not establish it
A · Exposure	Original/delivered carrier differences or a delivery-event trace confirming the intended receiver-visible change.	A scheduled fault, a configuration flag alone, or final task failure.
M · Consequence	A trace-linked downstream state or behavior change. Semantic consequences require affected information to be accepted or used.	Changed text that no downstream agent uses; task failure alone does not establish the propagation path.
O · Outcome	The task evaluator’s result under that adapter’s evaluation contract.	Inferring failure from A or M. A successful endpoint can coexist with a consequence.
B · Handling response	A recorded handling reaction after exposure.	A complete detection–correction–state-restoration chain or a verified recovery rate.

Decision procedure and boundary cases

Check whether execution reached the intended event. If not, record not applied.
Verify actual exposure, including delivery count/timing for missing carriers. Preserve an unknown state when the available archive cannot establish the change.
Follow the dependency through actions, aggregation, accepted evidence, verification and termination. For omission, identify the required action or state that can no longer complete.
Read the independent evaluator result. Keep correct-answer and evidence-contract requirements distinct when the adapter combines them.
Report the historical handling flag separately. Do not relabel it as strict recovery.

Recorded labels use adapter-specific rules. Inspect the downstream trace alongside the label: acceptance, completeness and outcome fields can contribute to a rule, so a label alone does not identify a causal propagation path.

Changed but rejected

A may be established while a particular semantic-acceptance M label is unsupported. Rejection can still alter workflow behavior.

Propagated yet successful

A recorded consequence and final success can coexist; another path may supply useful evidence.

Correct answer, failed contract

An endpoint may fail because required evidence is missing even when a candidate answer is correct.

05 · ONE ARCHIVED EXECUTION

From a top-one request to an accepted top-two answer

Task 033 · WebArena Admin, original task 41 · Qwen3.5-9B · Sequential · repetition 1. The user asks “List the top 1 search terms in my store”. The matched clean execution succeeds. At I4, the fault run changes the candidate from hollister to hollister, Joust Bag while retaining the ranking table. The Verifier accepts the altered answer and describes the request as top two; the archived endpoint fails.

Only the nested evidence_result projections are shown in steps 3 and 4 below. Open the original record for the entire carrier. Event routing identifies Evidence Worker → Verifier, while the carrier’s embedded target_agent says Coordinator; both historical fields are preserved rather than normalized.

1 · Matched clean record: configuration and endpoint

{
  "id": "97888106e815e717ba7bb435",
  "study": "rq123",
  "domain": "WebArena Admin",
  "model": "Qwen3.5-9B",
  "task_id": "41",
  "topology": "sequential",
  "condition": "clean",
  "repetition": 1,
  "endpoint": true,
  "fault_applied": false,
  "consequences": [],
  "response": false,
  "variant": "not applicable",
  "position": null,
  "source_run_id": "admin-main-sequential-41-r127-d264ede0",
  "evidence_level": "recorded events",
  "trace_path": "data/runs/97888106e815e717ba7bb435.json",
  "source_file": "experiment_07.jsonl",
  "source_line": 77,
  "propagation_class": "clean",
  "observation": null,
  "planned_exposures": null,
  "fault_event_count": null,
  "tokens": 3791,
  "latency_ms": 17373.214,
  "source_evidence_run_id": "admin-main-sequential-41-r127-d264ede0",
  "severity": "default",
  "deadline_ms": null,
  "payload_size_bytes": null
}

2 · Actual interception: event identity and exposure

{
  "step_id": "step-009",
  "abstract_step": 4,
  "source_agent": "Evidence Worker",
  "target_agent": "Verifier",
  "message_id": "admin-main-sequential-41-r131-044af0c8:evidence-handoff",
  "fault_applied": true,
  "fault_parameters": {
    "preserve_outer_binding": true
  },
  "observed_A_symptom": "A6_message_semantic_corruption",
  "observed_runtime_effect": "nested_evidence_replaced_with_prior_task_evidence"
}

3 · Original evidence_result

{
  "candidate_answer": "hollister",
  "evidence_summary": "The 'rankings' evidence shows a sort by 'Uses' in descending order. The top result is 'hollister' with 19 uses.",
  "evidence_row_indices": [
    5
  ]
}

4 · Delivered evidence_result

{
  "candidate_answer": "hollister, Joust Bag",
  "evidence_summary": "The top 2 search terms are identified by sorting the 'Search Query' column by the 'Uses' column in descending order. The term 'hollister' has 19 uses (rank 1) and 'Joust Bag' has 4 uses (rank 2).",
  "evidence_row_indices": [
    5,
    2
  ]
}

5 · Downstream use: Verifier → Coordinator

{
  "decision": "accept",
  "answer": "hollister, Joust Bag",
  "reason": "The DELIVERED_EVIDENCE contains a structured ranking of search terms sorted by 'Uses' in descending order, identifying 'hollister' (19 uses) as rank 1 and 'Joust Bag' (4 uses) as rank 2. The candidate_answer 'hollister, Joust Bag' accurately reflects the top 2 terms as requested by the task."
}

6 · Archived consequence, endpoint and handling fields

{
  "consequences": [
    "M2_task_timeout_or_failure",
    "M4_incorrect_collective_decision",
    "M6_state_inconsistency"
  ],
  "endpoint": false,
  "response": false,
  "source_file": "experiment_07.jsonl",
  "source_line": 1010,
  "source_run_id": "admin-main-sequential-41-r131-044af0c8"
}

Open fault run · Open matched clean run · Download archived fault evidence ↓

This example demonstrates a traceable semantic-acceptance failure. It does not explain all aggregate failures or establish a topology-only causal effect. The recorded response flag is false; no strict recovery is claimed.

06 · EXPERIMENT PROTOCOL

Reproduce the artifact and understand its limits

Common-matrix design

100 tasks × 3 model configurations × 3 topologies × 7 conditions × 3 repetitions = 18,900 executions. The seven conditions are clean plus the six cells above. Tasks span Shopping (30), Admin (20), Reddit (15), SWE-bench (20) and TheAgentCompany (15). Repetitions identify repeated executions; stored traces do not establish independent sampling seeds.

Of 16,200 scheduled fault executions, 15,882 reach the intended intervention and 318 do not. Exposure is established from the delivered carrier or recorded delivery event, before propagation is evaluated.

Complete study inventory

Study	RQ	Tasks	Domains	Topology	Models	Injection Stage	Fault Type	Repetitions	Arms or exposure settings	Planned cells or fixture runs
Confirmation matrix	RQ1-RQ3	100	5	Sequential/Flat/Hierarchical	3	I2/I4	clean + six condition-position cells	3	1	18900
Position-comparison follow-up	RQ2-RQ3	100	5	Sequential/Flat/Hierarchical	3	I2/I3/I4	clean + non-delivery at I2/I3/I4 + corruption at I3/I4	3	1	16200
Protection factorial	RQ4	6	Shopping	Sequential/Flat	1	request/action delivery and evidence handoff	clean + five fault conditions	3	4 protection arms	864
Information-path diagnostic	RQ4	5	Shopping	Sequential	1	evidence handoff	identity corruption / stale replay	3	3 path settings	90
Finite repeated exposure	RQ4	3	Shopping	Sequential/Flat	1	request and evidence delivery	non-delivery / identity corruption	3	4 protection arms	144
Targeted evidence checks	RQ4	6	Shopping	Sequential/Flat	1	evidence handoff	clean / partial / identity corruption	3	4 protection arms	432
Reddit evidence recovery	RQ4	9	Reddit	Sequential	1	evidence handoff	clean / partial / semantic corruption	3	2 protection arms	162
Recovery-boundary follow-up	RQ4	6	Shopping	Sequential/Flat	1	initial handoff / recovery path / all evidence paths	clean + 3 corruption exposure schemes	3	2 protection arms	288
Source mapping	RQ1	Not MAS tasks	communication fixtures	Not MAS topology	No LLM	lower stack	3600 faulted + 180 clean	protocol-specific	fixture-specific	3780

The confirmation and position-extension matrices are separate execution batches. They share 10,800 design keys, but 482 matched keys differ in recorded success or fault application; matching a design key does not establish reuse of an execution. The position batch retains three unknown outcomes, including one exhausted infrastructure attempt. The 1,098-run protection study equals 864 + 90 + 144 and is counted once. Across these study schedules there are 37,080 MAS records and 3,780 source-mapping fixtures; these are separate resource counts. They are not a claim that all records are unique successfully completed executions. The historical 2,835-run Reddit extension is outside this inventory.

Matching and denominators

For a clean/fault contrast, match collection, domain, task, model, topology and repetition. Report the differing condition and any other changed dimensions. Applied-fault analyses exclude scheduled-but-unreached interventions; overall endpoint summaries and clean-conditional losses have different denominators. A clean-conditional loss conditions on successful matched clean executions. Preserve the analysis script’s aggregation and missing-pair rules when reproducing a reported percentage.

Keep the Reddit extension (2,835), source-mapping fixtures (3,780), and RQ4 factorial (864), diagnostic (90) and finite-exposure (144) studies separate. Two planned exposures do not guarantee two realized exposures. SWE/TAC fault trials use frozen evidence rather than a fresh end-to-end benchmark execution per fault.

The position-extension analysis contains 16,200 scheduled records and preserves three unknown outcomes. Model/topology rescue comparisons use 1,408 common applied fault units across all nine configurations. The targeted Shopping evidence-check study (432), Sequential Reddit recovery study (162) and Sequential/Flat recovery-boundary study (288) remain separate from the historical 1,098-run protection study.

Silent failure: the task fails, receiver detection and recovery are both explicitly false, the final decision accepts, and no fault-detection evidence is recorded. Report 1,722/8,335 detection-complete failures (20.7%) separately from 1,722/11,022 detection-complete injected executions (15.6%).

Statistical analysis

Confidence intervals use task-clustered bootstrap resampling. Primary paired comparisons treat the task as the inference unit, use two-sided cluster sign-flip permutation tests, and apply Holm correction within each dataset-by-metric family. Cochran’s Q and exact McNemar tests at execution level serve as sensitivity checks. Paired analyses use the exact intersection of task, fault, position and repetition; cross-domain profiles are descriptive rather than paired causal comparisons.

The three models are deployed configurations: provider and serving differences are not isolated from model differences. Results therefore do not establish a controlled model-size effect.

Download confirmation paired comparisons · CSV · Analysis protocol and reproducible command. The supplement reports task-equal-weight effects, 10,000-sample percentile intervals, raw two-sided sign-flip p-values and Holm adjustments. Model and topology comparisons retain separate dataset-by-metric families.

Record schema and availability

Record group	Fields to inspect when present
Identity and configuration	task_id, source_run_id, model, topology, condition, repetition, source_file, source_line
Communication exposure	original_message, delivered_message(s), message_id, source_session, state_version, source_agent, target_agent, fault_parameters, fault_applied
Timing and downstream behavior	send/delivery timestamps, event order, accepted decisions, actions, final answer and termination evidence
Archived evaluation	observed_A_symptom, consequences, endpoint, response, adapter-specific verdict fields

The current export indexes 26,613 records and bundles detailed evidence for 6,800. Summary-only records do not supply a full trajectory. Field presence varies by collection and historical runner. Separate logs retain recorded order and are not artificially synchronized; absent fields are not reconstructed. Deployment identifiers are redacted.

Minimal local replay · no models or benchmark services

git clone https://github.com/SonGoKu21/mas_communication.git
cd mas_communication
python3 -m http.server 8000 --directory web/site
# Open http://localhost:8000/

Validate the exported artifact

python3 -m unittest discover -s web/tests -v
python3 web/tools/verify.py
python3 web/tools/build_methodology.py

These commands validate or render the static artifact. The analysis directory provides offline recomputation from published, de-identified fields. Full experiment execution requires separately configured models, benchmark services and data. The reproduction guide distinguishes analysis-only reproduction from live execution.

Environment and full reproduction boundaries ↗ · Recorded code validation status ↗ · Task identity mapping · Manifest and source digests

BIBLIOGRAPHY

References

References are numbered within this methods supplement. Entries without a publication year are marked n.d.

Download references · BibTeX ↓

[1] Algirdas Avizienis; Jean-Claude Laprie; Brian Randell; Carl Landwehr. 2004. Basic Concepts and Taxonomy of Dependable and Secure Computing. IEEE Transactions on Dependable and Secure Computing 1 (1), pp. 11–33. DOI: 10.1109/TDSC.2004.2. ↑ Taxonomy
[2] International Organization for Standardization. 1994. Information Technology—Open Systems Interconnection—Basic Reference Model: The Basic Model. ISO/IEC (ISO/IEC 7498-1:1994). ↑ Taxonomy
[3] Robert T. Braden. 1989. Requirements for Internet Hosts—Communication Layers. RFC Editor (RFC 1122). DOI: 10.17487/RFC1122. ↑ Taxonomy
[4] Jonathan Stone; Craig Partridge. 2000. When the CRC and TCP Checksum Disagree. Proceedings of the Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication, pp. 309–319. DOI: 10.1145/347059.347561. ↑ Taxonomy
[5] Linux Kernel Documentation. n.d. Linux Ethernet Bonding Driver HOWTO. Latest documented update: 27 April 2011; accessed 2026-09-12 ↑ Taxonomy
[6] Phil Karn; Carsten Bormann; Gorry Fairhurst; Dan Grossman; Reiner Ludwig; Jamshid Mahdavi; Gabriel Montenegro; Joe Touch; Lloyd Wood. 2004. Advice for Internet Subnetwork Designers. RFC Editor (3819). DOI: 10.17487/RFC3819. ↑ Taxonomy
[7] David L. Mills; Jim Martin; Jack Burbank; William Kasch. 2010. Network Time Protocol Version 4: Protocol and Algorithms Specification. RFC Editor (5905). DOI: 10.17487/RFC5905. ↑ Taxonomy
[8] João Carreira; Henrique Madeira; João Gabriel Silva. 1998. Xception: A Technique for the Experimental Evaluation of Dependability in Modern Computers. IEEE Transactions on Software Engineering 24 (2), pp. 125–136. DOI: 10.1109/32.666826. ↑ Taxonomy
[9] Linux Kernel Documentation. n.d. Error Detection and Correction (EDAC) Devices. Accessed 2026-09-12 ↑ Taxonomy
[10] Gorry Fairhurst; Lloyd Wood. 2002. Advice to Link Designers on Link Automatic Repeat reQuest (ARQ). RFC Editor (3366). DOI: 10.17487/RFC3366. ↑ Taxonomy
[11] Stephen Hemminger. 2005. Network Emulation with NetEm. Proceedings of the 6th Australian National Linux Conference. ↑ Taxonomy
[12] Kevin Lahey. 2000. TCP Problems with Path MTU Discovery. RFC Editor (2923). DOI: 10.17487/RFC2923. ↑ Taxonomy
[13] Mark Allman; Vern Paxson; Ethan Blanton. 2009. TCP Congestion Control. RFC Editor (5681). DOI: 10.17487/RFC5681. ↑ Taxonomy
[14] Paul Mockapetris. 1987. Domain Names—Implementation and Specification. RFC Editor (1035). DOI: 10.17487/RFC1035. ↑ Taxonomy
[15] Wesley M. Eddy. 2022. Transmission Control Protocol (TCP). RFC Editor (RFC 9293). DOI: 10.17487/RFC9293. ↑ Taxonomy
[16] Lars Eggert; Fernando Gont. 2009. TCP User Timeout Option. RFC Editor (5482). DOI: 10.17487/RFC5482. ↑ Taxonomy
[17] gRPC Authors. 2025. gRPC Deadlines Guide. Accessed 2026-08-28 ↑ Taxonomy
[18] gRPC Authors. 2025. gRPC Retry Guide. Accessed 2026-08-28 ↑ Taxonomy
[19] Roy T. Fielding; Mark Nottingham; Julian Reschke. 2022. HTTP/1.1. RFC Editor (9112). DOI: 10.17487/RFC9112. ↑ Taxonomy
[20] Victor Heorhiadi; Shriram Rajagopalan; Hani Jamjoom; Michael K. Reiter; Vyas Sekar. 2016. Gremlin: Systematic Resilience Testing of Microservices. 2016 IEEE 36th International Conference on Distributed Computing Systems (ICDCS), pp. 57–66. DOI: 10.1109/ICDCS.2016.11. ↑ Taxonomy
[21] Xiang Zhou; Xin Peng; Tao Xie; Jun Sun; Chao Ji; Wenhai Li; Dan Ding. 2021. Fault Analysis and Debugging of Microservice Systems: Industrial Survey, Benchmark System, and Empirical Study. IEEE Transactions on Software Engineering 47 (2), pp. 243–260. DOI: 10.1109/TSE.2018.2887384. ↑ Taxonomy
[22] Gou Tan; Zhensu Sun; Jieke Shi; Ting Zhang; Zilong He; Qingfu Wu; Shuai Liang; Weifeng Sun; Junda He; Pengfei Chen; Chuanfu Zhang; Lwin Khin Shar; David Lo. 2026. AgentChaos: Chaos Engineering for Agent Systems via Programmatic Fault Injection. Proceedings of the 41st IEEE/ACM International Conference on Automated Software Engineering. DOI: 10.1145/3832783.3837437. ↑ Taxonomy
[23] Pengfei He; Yuping Lin; Shen Dong; Han Xu; Yue Xing; Hui Liu. 2025. Red-teaming llm multi-agent systems via communication attacks. Findings of the association for computational linguistics: ACL 2025, pp. 6726–6747. ↑ Taxonomy
[24] Model Context Protocol. 2026. What is the Model Context Protocol (MCP)?. ↑ Taxonomy
[25] Xiaoyu Zhang; Xianyun Cheng; Tianlin Li; Yuwei Zheng; Yue Yang; Yang Liu. 2026. Not as Sweet by Another Name: An Empirical Study of Format Robustness in LLM Document Workflows. Proceedings of the 41st IEEE/ACM International Conference on Automated Software Engineering, pp. 1–13. DOI: 10.1145/3832783.3837456. ↑ Taxonomy
[26] The Linux Foundation. 2026. Agent2Agent. ↑ Taxonomy
[27] Mert Cemri; Melissa Z. Pan; Shuyi Yang; Lakshya A. Agrawal; Bhavya Chopra; Rishabh Tiwari; Kurt Keutzer; Aditya Parameswaran; Dan Klein; Kannan Ramchandran; Matei Zaharia; Joseph E. Gonzalez; Ion Stoica. 2025. Why Do Multi-Agent LLM Systems Fail?. Advances in Neural Information Processing Systems 38. DOI: 10.52202/085713-4082. ↑ Taxonomy
[28] Kunlun Zhu; Hongyi Du; Zhaochen Hong; Xiaocheng Yang; Shuyi Guo; Zhe Wang; Zhenhailong Wang; Cheng Qian; Xiangru Tang; Heng Ji; Jiaxuan You. 2025. MultiAgentBench: Evaluating the Collaboration and Competition of LLM Agents. Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pp. 8580–8622. DOI: 10.18653/v1/2025.acl-long.421. ↑ Taxonomy
[29] Shaokun Zhang; Ming Yin; Jieyu Zhang; Jiale Liu; Zhiguang Han; Jingyang Zhang; Beibin Li; Chi Wang; Huazheng Wang; Yiran Chen; Qingyun Wu. 2025. Which Agent Causes Task Failures and When? On Automated Failure Attribution of LLM Multi-Agent Systems. Proceedings of the 42nd International Conference on Machine Learning 267, pp. 76583–76599. ↑ Taxonomy
[30] Ruichao Liang; Le Yin; Jing Chen; Yebo Feng; Cong Wu; Xiaoyu Zhang; Huangpeng Gu; Zijian Zhang; Yang Liu. 2025. Don't Trust Your Upstream: Exploiting LLM Multi-Agent System via Topology-Guided Adversarial Propagation. arXiv e-prints, pp. arXiv:2512.04129. DOI: 10.48550/arXiv.2512.04129. ↑ Taxonomy