WirelessOpsAgent: A Benchmark and Agent Design for Action Assurance in Wireless Networks

Hao Xu; Jiajia Guo; Shi Jin; Weicong Chen; Xin He; Yiping Zuo; Zijian Lu

REVIEW 3 major objections 5 minor 30 references

WirelessOpsAgent: A Benchmark and Agent Design for Action Assurance in Wireless Networks

T0 review · 3 major / 5 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper claims that an LLM agent for wireless operations becomes safer when its answers are treated as proposals whose critical fields must be grounded in current network evidence, repaired when recoverable, and revalidated before any…

desk verdict A solid benchmark-and-agent paper for execution-time action assurance, with clean internal evidence but a circular oracle design and a known mis-scored slice in the headline Unsafe APPLY Rate. read the letter →

arxiv 2608.08277 v1 pith:L5Q7RNYC submitted 2026-08-08 cs.NI

Zijian Lu , Yiping Zuo , Hao Xu , Weicong Chen , Xin He , Jiajia Guo , Shi Jin This is my paper · ORCID

classification cs.NI

keywords wirelessnetworkoperationsLLMagentactionassuranceexecution-statedecisiontelemetryfreshnessevidencegroundingboundedrepairoperatorauthorization

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper introduces WirelessOptBench, a benchmark that turns wireless network tasks into execution-state decision episodes in which telemetry can be stale, missing, conflicting, or out of order, and proposes WirelessOpsAgent, an agent design that treats an LLM's answer as a proposal rather than an executable decision. The central claim is that grounding each critical field of the proposal in current network evidence, repairing only the affected fields when support fails, and revalidating before release makes LLM agents route actions to the correct execution decision far more safely than solving the task alone. Across three backbone evaluations with 600 episodes each, the design reaches up to 0.983 exact action accuracy, and on the strongest backbone the unsafe APPLY rate falls from 82.2% to 10.3% relative to the safest baseline. The paper's point is that task correctness and execution support are separate gates: a plausible answer can be unsafe once its supporting measurements expire or disagree.

What carries the argument

The load-bearing mechanism is the decision-linked evidence graph combined with a typed integrity diagnosis and an ordered action governor. Each critical field carries value, schema, unit, source, provenance, event time, ingest time, freshness limit, and parent dependencies; the diagnosis checks $\mathrm{Valid}(k,t)=\mathrm{SchemaOK}(k)\wedge\mathrm{UnitOK}(k)\wedge\mathrm{SourceOK}(k,t)\wedge\mathrm{Fresh}(k,t)\wedge\mathrm{ConflictFree}(k,t)$, and the governor applies the ordered policy $\mathrm{APPLY}$ if ready, else $\mathrm{ESCALATE}$ for ambiguity or conflict, $\mathrm{RETRY}$ for retryable outages, $\mathrm{HOLD}$ for state not yet current, and $\mathrm{ABSTAIN}$ otherwise. Repairs are scoped to the failing fields and their descendants, accepted only if revalidated, supported by recorded evidence, and not lowering task utility. This machinery converts the open-ended question 'is the answer right?' into the checkable question 'does every field that the action depends on have current, consistent support?'.

What would settle it

Take the same 600 frozen episodes and relabel them with an independently built rule generator or with labels from human network operators, then rerun the evaluation; if exact action accuracy falls to near the baselines, the headline result is an artifact of the governor matching the benchmark's own oracle.

Watch

Extended reading notes

Core claim

On the paper's own terms, the discovery is that an authorization loop placed between an LLM proposal and the control plane can convert imperfect wireless answers into operationally safe decisions. WirelessOpsAgent binds the exposed observations into an immutable ledger, diagnoses each critical field with five checks covering schema, unit, source, freshness, and conflict, repairs only the failing fields and their descendants in the evidence graph, and then runs an ordered governor that selects APPLY, RETRY, HOLD, ESCALATE, or ABSTAIN. The empirical result is that this loop achieves exact action accuracy up to 0.983 across three backbones, eliminates false-positive APPLY decisions on all 400 blocking episodes after repair, and lowers the unsafe APPLY rate from 82.2% to 10.3% on the strongest backbone while retaining the highest safe APPLY recall. The authors interpret this as evidence that evidence grounding, bounded recovery, and revalidation, rather than a conservative refusal policy, are what produce safety.

Load-bearing premise

The correct action for every episode is defined by the paper's own rule-based oracle, and the agent's governor is written to mirror that same ordered policy, so the reported accuracy measures how faithfully the agent follows the authors' specification rather than how an operator would judge the action.

Editorial extensions

If this is right

A model can produce a nominally correct wireless answer and the agent will still refuse to release it when a required measurement is stale, unavailable, or conflicting, so task score and operational readiness no longer move together.
After scoped repair, false-positive APPLY decisions fall to zero on all 400 blocking episodes across the three backbones while APPLY recall stays between 96% and 99.5%, showing the safety gain is not indiscriminate blocking.
The governor maps distinct telemetry faults to distinct responses, with freshness faults to HOLD, availability faults to RETRY, and conflict faults to ESCALATE, so operators receive an actionable reason rather than a single refusal.
Ablations show the integrity monitor and action governor carry the safety effect: removing either drops macro F1 to about 0.22 and raises the unsafe APPLY rate to about 0.69, while removing utility repair collapses safe APPLY recall from 72.5% to 24.5%.
The gains appear in all three task families and in 40 of 45 backbone-task-condition cells, so the design's benefit is not confined to one kind of wireless reasoning.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

A natural extension the paper does not run would replace the rule-based reference oracle with human operator labels on a subset of episodes; if exact-action accuracy falls toward baseline levels, the headline scores partly measure agreement with the benchmark's own specification.
The proposal-governor pattern is domain-general: any control setting with time-sensitive telemetry, such as power-grid dispatch or cloud autoscaling, could adopt the same grounding, scoped repair, and revalidation loop, but that transfer is not tested here.
Because the paper itself reports a frozen-evaluator confound in the conflict/provenance slice, the agent's handling of true material conflicts remains an open measurement rather than an established result.
Operational value ultimately depends on whether network operators prefer HOLD, RETRY, or ESCALATE in these fault situations; a human study of routing acceptability would test that preference directly.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

The paper is a solid benchmark-and-agent contribution, and the execution-time decision boundary it targets is genuinely new. It builds WirelessOptBench from WirelessBench tasks by pairing fixed questions with evidence graphs, execution contracts, and controlled telemetry faults (stale, missing, conflicting, schema/unit), then asking the agent to route the action to APPLY, HOLD, RETRY, or ESCALATE. That boundary—checking support at execution time—is not covered by the cited benchmarks, which mostly evaluate task solving on fixed observations. The agent design is also clean: ledger-based evidence binding, typed integrity diagnosis, dependency-scoped repair, revalidation, and a governor that releases only ready proposals. The internal evidence is strong: three backbones, 600 episodes each, ablations that cleanly isolate monitor, governor, and repair, and a before/after audit where false APPLY decisions drop to zero on all 400 blocking reference episodes. The artifact link and replayable decision records help.

The main soft spot is structural circularity. The benchmark's reference labels follow an ordered policy over six predicates (Section III.C), and the agent's governor (Eq. 9) implements essentially the same policy. The paper acknowledges in Section VI that the taxonomy and oracle are benchmark-defined, not drawn from an unseen generator or deployment study. So the headline numbers—up to 0.983 Exact Action Accuracy and the Unsafe APPLY Rate reductions—mostly measure how faithfully the LLM front-end reconstructs the authors' own mapping from violations to actions. That is acceptable for a controlled benchmark, but it does not validate the underlying safety semantics. The second issue is the conflict/provenance slice: the reported Unsafe APPLY Rate of 0.325 for that condition is confounded by a frozen-evaluator bug that marked 39 of 40 correct APPLY decisions unsafe on GPT-5.4-mini. The authors disclose this in Section V.D and exclude the slice from material-conflict claims, but the abstract and Table III still present the aggregate 10.3% Unsafe APPLY Rate without that caveat. That is a transparency slip.

Overall, the math holds up, the ablations are believable, and the paper is honest about its limits. I would send it to peer review, with a request to report the corrected Unsafe APPLY Rate excluding the confounded slice and to expand the discussion of what the oracle does and does not encode. For future work, cite it for the benchmark and the execution-time framing, not for the absolute safety numbers.

Referee Report

3 major / 5 minor

Summary. The paper introduces WirelessOptBench, a benchmark for action assurance in wireless network operations, and WirelessOpsAgent, an agent architecture that treats LLM outputs as proposals, grounds critical fields in current evidence, repairs recoverable support failures, and revalidates before authorizing execution. The benchmark turns 600 wireless episodes (200 each from three WirelessBench task families) into execution-state decision episodes with evidence graphs, execution contracts, telemetry stresses, and rule-based reference actions. The agent's integrity monitor applies typed checks (schema, unit, source, freshness, conflict), performs dependency-scoped bounded recovery, and routes actions through an ordered governor (APPLY, ESCALATE, RETRY, HOLD, ABSTAIN). The evaluation reports Exact Action Accuracy up to 0.983, Safe APPLY Recall up to 72.5%, and Unsafe APPLY Rates between 7.8% and 17.2% across three backbones, with ablations isolating the monitor, governor, and repair components. The paper also includes a before/after repair audit showing false APPLY decisions drop to zero on blocking episodes.

Significance. If the results hold, the benchmark fills a real gap: existing LLM agent benchmarks for wireless networks mostly evaluate task solving from fixed observations and do not test whether a proposed action is still supported by current, consistent, fresh telemetry at execution time. The paper's strengths are its explicit execution model (Eqs. 1–5), typed integrity diagnosis (Eq. 6), scoped recovery with an acceptance condition (Eqs. 7–8), replayable authorization records, and ablations that isolate the main architectural components. The before/after repair audit and per-condition routing analysis are valuable for understanding where the safety gain comes from. However, the central claim's external validity is limited by the fact that the benchmark's reference actions and the agent's governor implement essentially the same rule-based policy, and part of the reported headline Unsafe APPLY Rate is known to be inflated by a frozen-evaluator scoring artifact. These issues are disclosed in Sections V.D and VI but are not reflected in the abstract or the headline tables, so the paper overstates the strength of the safety result as currently written.

major comments (3)

[Section III.C, Section III.D, and Eq. (9)] The reference action labels in WirelessOptBench are generated by an ordered six-predicate policy, and WirelessOpsAgent's action governor (Eq. 9) implements nearly the same ordered policy (APPLY, ESCALATE, RETRY, HOLD, ABSTAIN). The paper itself states in Section III.D that the taxonomy and oracle are benchmark-defined rather than drawn from an unseen generator or independent deployment study. Consequently, the Exact Action Accuracy values up to 0.983 largely measure how faithfully the LLM front end reproduces the authors' own violation-to-action mapping, not whether the resulting actions are safe under operational wireless semantics. This is not an internal inconsistency, but it is load-bearing for the paper's claim that the agent makes actions 'safer.' I recommend adding an independent semantic validation step, such as expert human labeling of a stratified episode subset, an independent oracle implementation from a different team, or a small deployment-style study; if such validation is infeasible, the claims should be reframed as demonstrating compliance with the benchmark specification rather than operational safety.
[Section V.D, Table V, Table III, and the Abstract] The reported Unsafe APPLY Rate is materially confounded by a known scoring artifact that the paper discloses only in Section V.D. For the conflict/provenance slice, the frozen evaluator marks 39 of 40 correct WirelessOpsAgent APPLY decisions as unsafe on GPT-5.4-mini (and 22 of 40 CRITIC-style decisions), yet this slice is included in the headline Unsafe APPLY Rates in Table III and in the Abstract. Concretely, 39 of 600 episodes is 6.5 percentage points, which is a substantial fraction of the headline 10.3% Unsafe APPLY Rate on Claude Sonnet 4.6. The manuscript should either correct the evaluator and re-score the conflict slice, or report the headline metrics excluding the known mis-scored nonmaterial negatives, with a clear note in the Abstract and Table III. As written, the primary quantitative claim includes known mislabeled observations that contradict the 'false APPLY decisions fall to zero' narrative in Table IV.
[Section VI and Section III.D] The limitation statement in Section VI correctly notes that WirelessOptBench is a controlled benchmark rather than a live deployment study, and that stress domains are not production fault frequencies. However, this limitation is not carried into the interpretation of the headline numbers. The paper claims 'unsafe execution' and 'Unsafe APPLY Rate' as operational-safety metrics, but the only notion of 'unsafe' is a hard violation flag defined by the same benchmark specification that also defines the reference labels and the agent's governor. I ask the authors to either consistently qualify these terms as benchmark-defined safety violations or provide an external anchor for the safety semantics, otherwise the central contribution risks being a self-consistency check rather than an action-assurance result.

minor comments (5)

[Abstract] The phrase 'decreases from 82.2% to 10.3% relative to the safest baseline' is imprecise: the decrease is an absolute reduction of 71.9 percentage points, and 82.2% is not the relative baseline rate in the usual sense. Please rephrase as 'an absolute reduction of 71.9 percentage points compared with the best baseline.'
[Section V.D] The distinction between 'material' and 'nonmaterial' conflict positives is central to the conflict/provenance caveat but is never formally defined. Please define the criterion used in the post-freeze audit and state how many of the 120 conflict/provenance episodes fall in each class.
[Section IV.D, Eq. (8)] The acceptance condition in Eq. (8) uses a task verifier V(d'_t) >= V(d_t), but the paper does not specify how V is computed or calibrated across task families. A brief definition of the verifier and its scoring granularity would make the utility-preservation claim easier to interpret.
[Section V.A] The protocol mentions paired bootstrap confidence intervals, but Table III and Table VI report no intervals. Please either include the intervals for the primary metrics or state that the reported values are point estimates from a deterministic frozen split.
[Section III.C] The sentence 'A predicted ABSTAIN is retained as an incorrect action rather than dropped' is useful, but the denominator treatment of ABSTAIN should also be stated explicitly in the metric definitions in Table II, since ABSTAIN is never a reference action.

Circularity Check

1 steps flagged · score 6.0 of 10

The agent governor (Eq. 9) re-implements the benchmark's own label oracle (Section III.C), so headline Exact Action Accuracy largely measures self-consistency with the authors' spec rather than an independent safety property.

self definitional [Section III.C (Reference Answers and Action Labels) vs. Section IV.E (Eq. 9)]
"Labels follow an ordered policy over six predicates. Ambiguous schema, material conflict, or independent failures yield ESCALATE. Otherwise, a required source in a retryable outage yields RETRY, unknown critical schema or stale required state yields HOLD, and no blocker yields APPLY. ... The action governor then evaluates the following ordered policy from top to bottom: APPLY, Ready_t = 1; ESCALATE, ambiguity or conflict remains; RETRY, a required tool can be retried; HOLD, required state is not yet current; ABSTAIN, otherwise."

The reference labels and the agent's release rule are the same ordered policy with the same precedence order. Section III.D confirms that both 'implement the same benchmark specification' and that the taxonomy/oracle are 'benchmark-defined rather than drawn from an unseen generator or independent deployment study.' Thus the 0.972-0.983 Exact Action Accuracy and the Unsafe APPLY Rate reductions mostly test whether the LLM front-end plus recovery loop can reproduce the authors' programmed violation-to-action mapping. Not fully circular: the labels are hidden from the agent at inference time, the predicates (stale, conflict, retryable outage) must be inferred from public telemetry, and the underlying task answers come from external WirelessBench.

full rationale

The central empirical claim is a benchmark evaluation, not a mathematical derivation, so the circularity question is whether the metric is anchored independently of the agent's own design choices. The strongest circularity evidence is the near-identity between the benchmark's label oracle (Section III.C) and WirelessOpsAgent's Eq. (9) governor. Since the paper itself states that the oracle is 'benchmark-defined rather than drawn from an unseen generator or independent deployment study' (Section VI), a large part of the reported action accuracy is self-consistency: the agent is scored against a rule that its own authorization policy reimplements. This is not a fitted-parameter or self-citation chain; WirelessBench task sources [10] are external, and the agent does not see the hidden reference actions (Section III.D), so the result is not fully forced. I also flag the disclosed measurement confound in Section V.D, where the frozen evaluator marked 39 of 40 correct WirelessOpsAgent APPLY decisions as unsafe in the conflict/provenance slice and the paper still includes that slice in the abstract and Table III headline rates; this is a validity concern rather than a circularity step, but it reinforces that the headline safety numbers should not be read as externally validated. Overall: partial circularity by construction in the primary action-accuracy metric, so score 6.

Assumptions & free parameters 2 free parameters · 4 assumptions · 0 invented entities

Central claims rest on the benchmark's rule-based reference labels, which are defined by the authors, and on the standard wireless execution model. Free parameters are the benchmark's target label distribution and the per-field freshness limits, both chosen by hand rather than fitted. The agent introduces no new physical entities; its evidence graph, integrity monitor, and authorization record are implemented components measured in the paper's own evaluation, without an independent external deployment study.

free parameters (2)

Episode label distribution = 200 APPLY, 100 HOLD, 100 RETRY, 200 ESCALATE
Section III.C: deterministic retention of 600 of 7,680 candidates enforces this distribution. It sets the baseline difficulty and the denominator for unsafe apply rate; a different split would change both headline numbers.
Per-field freshness limits delta_k = contract-specific values (not enumerated)
Eq. (5) and the execution contract define when telemetry expires. These limits are chosen by the benchmark authors, not derived from deployment data, so they determine what counts as stale and hence the HOLD and RETRY decisions.

assumptions (4)

domain assumption Wireless execution model Eqs. (1)-(4) (SINR, rate, slicing budget, handover margin) correctly characterize operational safety.
The benchmark and the agent both use these formulas to judge feasibility; no validation against a real deployment is provided (Section III.A).
ad hoc to paper The six-predicate ordered reference policy (Section III.C) correctly maps evidence states to the correct action.
The oracle labels episodes with this policy, and the agent's governor mirrors it; correctness of the policy is asserted rather than externally grounded.
domain assumption Exposed telemetry metadata and provenance fields are correctly reported by the network tools.
Stated in Limitations (Section VI): WirelessOpsAgent assumes exposed telemetry metadata and provenance are correctly reported; if wrong, the evidence graph is unreliable.
ad hoc to paper The fact-level oracle and public-view certificate checker agreeing is sufficient to certify reference actions.
Section III.C: internal consistency between two paths implementing the same spec is treated as a validity check, not validation against an independent ground truth.

how reviews work

0 comments

Cite this review

Pith. "Pith review of WirelessOpsAgent: A Benchmark and Agent Design for Action Assurance in Wireless Networks." pith.science (2026). https://pith.science/paper/L5Q7RNYC

@misc{pith2026260808277,
  author       = {Pith},
  title        = {Pith review of: WirelessOpsAgent: A Benchmark and Agent Design for Action Assurance in Wireless Networks},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/L5Q7RNYC}},
  note         = {Machine review of arXiv:2608.08277}
}

read the original abstract

Large language model (LLM) agents are emerging as planners for autonomous wireless network operations. Yet a task answer that is correct at proposal time can still be unsafe at execution time if supporting telemetry is stale or inconsistent. Existing benchmarks mainly evaluate task solving from fixed observations and leave support checking at execution time untested. We introduce WirelessOptBench, a benchmark for action assurance in wireless operations. It turns wireless tasks into execution state decision episodes with controlled telemetry faults and action constraints. We further develop WirelessOpsAgent, which grounds candidate actions in current evidence and repairs recoverable support failures before execution. Across three backbone evaluations with 600 episodes each, WirelessOpsAgent achieves up to 0.983 Exact Action Accuracy. On Claude Sonnet 4.6, the Unsafe APPLY Rate decreases from 82.2% to 10.3% relative to the safest baseline. We make WirelessOptBench available at https://anonymous.4open.science/r/wirelessopsbench-artifact-D969/.

Figures

Figures reproduced from arXiv: 2608.08277 by the authors.

**Figure 2.** WirelessOptBench pairs fixed wireless tasks with execution state observations and scores decisions against state derived reference actions. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗

**Figure 3.** WirelessOpsAgent binds evidence, checks a proposed decision, repairs affected fields, and authorizes the resulting action. [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗

Figures from the paper (4 more)

**Figure 4.** Figure 4: OPS survival over 600 episodes for each method on each backbone. [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]

**Figure 5.** Figure 5: Final routing of proposals initially marked APPLY. Bars are normal [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]

**Figure 6.** Figure 6: Row normalized action confusion matrices averaged over three 600 episode backbone runs. Rows are reference actions. Columns include the four [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]

**Figure 7.** Figure 7: Exact Action Accuracy gain over the strongest baseline in each back [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

30 extracted references · 23 canonical work pages

[1]

A survey on intent-based networking,

A. Leivadeas and M. Falkner, “A survey on intent-based networking,” IEEE Commun. Surveys Tuts., vol. 25, no. 1, pp. 625–655, 2023

2023
[2]

Network slicing in 5G: Survey and challenges,

X. Foukas, G. Patounas, A. Elmokashfi, and M. K. Marina, “Network slicing in 5G: Survey and challenges,”IEEE Commun. Mag., vol. 55, no. 5, pp. 94–100, 2017

work page 2017
[3]

O-RAN: Disrupting the virtu- alized RAN ecosystem,

A. Garcia-Saavedra and X. Costa-P ´erez, “O-RAN: Disrupting the virtu- alized RAN ecosystem,”IEEE Commun. Standards Mag., vol. 5, no. 4, pp. 96–103, 2021

work page 2021
[4]

RD-Probe: Scalable monitoring with sufficient coverage in complex datacenter networks,

R. Ding, X. Liu, S. Yang, Q. Huang, B. Xie, R. Sun, Z. Zhang, and B. Cui, “RD-Probe: Scalable monitoring with sufficient coverage in complex datacenter networks,” inProc. ACM SIGCOMM, Aug. 2024, pp. 258–273

work page 2024
[5]

Enhancing network failure mitigation with performance-aware ranking,

P. Namyar, A. Ghavidel, D. Crankshaw, D. S. Berger, K. Hsieh, S. Kandula, R. Govindan, and B. Arzani, “Enhancing network failure mitigation with performance-aware ranking,” in22nd USENIX Symposium on Networked Systems Design and Implementation (NSDI 25). USENIX Association, Apr. 2025, pp. 335–357. [Online]. Available: https://www.usenix.org/conference/nsd...

work page 2025
[6]

Impact of adaptive consistency on distributed SDN applications: An empirical study,

E. Sakic and W. Kellerer, “Impact of adaptive consistency on distributed SDN applications: An empirical study,”IEEE J. Sel. Areas Commun., vol. 36, no. 12, pp. 2702–2715, Dec. 2018

work page 2018
[7]

Abstractions for network update,

M. Reitblatt, N. Foster, J. Rexford, C. Schlesinger, and D. Walker, “Abstractions for network update,” inProc. ACM SIGCOMM, Aug. 2012, pp. 323–334

work page 2012
[8]

WirelessAgent: Large language model agents for intelligent wireless networks,

J. Tong, W. Guo, J. Shao, Q. Wu, Z. Li, Z. Lin, and J. Zhang, “WirelessAgent: Large language model agents for intelligent wireless networks,”China Commun., vol. 23, no. 3, pp. 265–285, Mar. 2026

work page 2026

Show all 30 references

[9]

WirelessAgent++: Automated agentic workflow design and benchmarking for wireless networks,

J. Tong, Z. Li, F. Liu, W. Guo, and J. Zhang, “WirelessAgent++: Automated agentic workflow design and benchmarking for wireless networks,” arXiv preprint arXiv:2603.00501, 2026

2026
[10]

WirelessBench: A tolerance-aware LLM agent benchmark for wireless network intelligence,

J. Tong, F. Liu, L. Xv, S. Lu, K. Li, Y . Zhang, Y . Song, Z. Xue, and J. Zhang, “WirelessBench: A tolerance-aware LLM agent benchmark for wireless network intelligence,” arXiv preprint arXiv:2603.21251, 2026

2026
[11]

NetConfEval: Can LLMs facilitate network configuration?

C. Wang, M. Scazzariello, A. Farshin, S. Ferlin, D. Kosti ´c, and M. Chiesa, “NetConfEval: Can LLMs facilitate network configuration?” Proc. ACM Netw., vol. 2, no. CoNEXT2, pp. 1–25, Jun. 2024, art. no. 7

2024
[12]

Bench- marking LLM-driven network configuration repair,

I. Protogeros, R. Asadli, B. Hoffman, and L. Vanbever, “Bench- marking LLM-driven network configuration repair,” arXiv preprint arXiv:2604.22513, 2026

2026 arXiv
[13]

R-Judge: Benchmarking safety risk awareness for LLM agents,

T. Yuan, Z. He, L. Dong, Y . Wang, R. Zhao, T. Xia, L. Xu, B. Zhou, F. Li, Z. Zhang, R. Wang, and G. Liu, “R-Judge: Benchmarking safety risk awareness for LLM agents,” inFindings of the Association for Com- putational Linguistics: EMNLP 2024. Association for Computational Ling...

2024
[14]

AgentSpec: Customizable run- time enforcement for safe and reliable LLM agents,

H. Wang, C. M. Poskitt, and J. Sun, “AgentSpec: Customizable run- time enforcement for safe and reliable LLM agents,” arXiv preprint arXiv:2503.18666, 2025

2025 arXiv
[15]

Dynamic control system upgrade using the Simplex architecture,

D. Seto, B. H. Krogh, L. Sha, and A. Chutinan, “Dynamic control system upgrade using the Simplex architecture,”IEEE Control Syst. Mag., vol. 18, no. 4, pp. 72–80, 1998

1998
[16]

ModelPlex: Verified runtime validation of verified cyber-physical system models,

S. Mitsch and A. Platzer, “ModelPlex: Verified runtime validation of verified cyber-physical system models,”Formal Methods Syst. Des., vol. 49, no. 1–2, pp. 33–74, 2016

2016
[17]

Self-Refine: Iterative refinement with self-feedback,

A. Madaan, N. Tandon, P. Gupta, S. Hallinan, L. Gao, S. Wiegreffe, U. Alon, N. Dziri, S. Prabhumoye, Y . Yang, S. Gupta, B. P. Majumder, K. Hermann, S. Welleck, A. Yazdanbakhsh, and P. Clark, “Self-Refine: Iterative refinement with self-feedback,” inAdv. Neural Inf. Process. S...

2023
[18]

CRITIC: Large language models can self-correct with tool-interactive critiquing,

Z. Gou, Z. Shao, Y . Gong, Y . Shen, Y . Yang, N. Duan, and W. Chen, “CRITIC: Large language models can self-correct with tool-interactive critiquing,” inProc. Int. Conf. Learn. Represent. (ICLR), 2024

2024
[19]

ReAct: Synergizing reasoning and acting in language models,

S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y . Cao, “ReAct: Synergizing reasoning and acting in language models,” inProc. Int. Conf. Learn. Represent. (ICLR), 2023

2023
[20]

Toolformer: Language models can teach themselves to use tools,

T. Schick, J. Dwivedi-Yu, R. Dessi, R. Raileanu, M. Lomeli, E. Hambro, L. Zettlemoyer, N. Cancedda, and T. Scialom, “Toolformer: Language models can teach themselves to use tools,” inAdv. Neural Inf. Process. Syst. (NeurIPS), vol. 36, 2023, pp. 68 539–68 551

2023
[21]

ToolLLM: Facilitating large language models to master 16000+ real-world APIs,

Y . Qin, S. Liang, Y . Ye, K. Zhu, L. Yan, Y . Lu, Y . Lin, X. Cong, X. Tang, B. Qian, S. Zhao, L. Hong, R. Tian, R. Xie, J. Zhou, M. Gerstein, D. Li, Z. Liu, and M. Sun, “ToolLLM: Facilitating large language models to master 16000+ real-world APIs,” inProc. Int. Conf. Learn. ...

2024
[22]

FlexRAN: A flexible and programmable platform for software- defined radio access networks,

X. Foukas, N. Nikaein, M. M. Kassem, M. K. Marina, and K. Konto- vasilis, “FlexRAN: A flexible and programmable platform for software- defined radio access networks,” inProc. ACM Int. Conf. Emerg. Netw. Experiments Technol. (CoNEXT), 2016, pp. 427–441

2016
[23]

Application of machine learning in wireless networks: Key techniques and open issues,

Y . Sun, M. Peng, Y . Zhou, Y . Huang, and S. Mao, “Application of machine learning in wireless networks: Key techniques and open issues,” IEEE Commun. Surveys Tuts., vol. 21, no. 4, pp. 3072–3108, 2019

2019
[24]

Header space analysis: Static checking for networks,

P. Kazemian, G. Varghese, and N. McKeown, “Header space analysis: Static checking for networks,” in9th USENIX Symposium on Networked Systems Design and Implementation (NSDI 12). USENIX Association, 2012, pp. 113–126

2012
[25]

Real time network policy checking using header space analysis,

P. Kazemian, M. Chang, H. Zeng, G. Varghese, N. McKeown, and S. Whyte, “Real time network policy checking using header space analysis,” in10th USENIX Symposium on Networked Systems Design and Implementation (NSDI 13). USENIX Association, 2013, pp. 99– 111

2013
[26]

Veri- Flow: Verifying network-wide invariants in real time,

A. Khurshid, X. Zou, W. Zhou, M. Caesar, and P. B. Godfrey, “Veri- Flow: Verifying network-wide invariants in real time,” in10th USENIX Symposium on Networked Systems Design and Implementation (NSDI 13). USENIX Association, 2013, pp. 15–27

2013
[27]

A general approach to network con- figuration analysis,

A. Fogel, S. Fung, L. Pedrosa, M. Walraed-Sullivan, R. Govindan, R. Mahajan, and T. Millstein, “A general approach to network con- figuration analysis,” in12th USENIX Symposium on Networked Systems Design and Implementation (NSDI 15). USENIX Association, 2015, pp. 469–483

2015
[28]

PROV-DM: The PROV data model,

World Wide Web Consortium, “PROV-DM: The PROV data model,” W3C Recommendation, Apr. 2013, L. Moreau and P. Missier, Eds

2013
[29]

Reasoning language models for root cause analysis in 5G wireless networks,

M. Sana, N. Piovesan, A. D. Domenico, Y . Kang, H. Zhang, M. Debbah, and F. Ayed, “Reasoning language models for root cause analysis in 5G wireless networks,” arXiv preprint arXiv:2507.21974, 2025

2025 arXiv
[30]

A multi-dataset benchmark for eval- uating LLM agents in microservice failure diagnosis,

Y . Cai, X. Nie, K. Yin, C. Pei, Y . Sun, S. Zhang, H. Liu, G. Liu, X. Wen, F. Situ, and D. Pei, “A multi-dataset benchmark for eval- uating LLM agents in microservice failure diagnosis,” arXiv preprint arXiv:2606.29193, 2026

2026 arXiv

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.

[1] [1]

A survey on intent-based networking,

A. Leivadeas and M. Falkner, “A survey on intent-based networking,” IEEE Commun. Surveys Tuts., vol. 25, no. 1, pp. 625–655, 2023

2023

[2] [2]

Network slicing in 5G: Survey and challenges,

X. Foukas, G. Patounas, A. Elmokashfi, and M. K. Marina, “Network slicing in 5G: Survey and challenges,”IEEE Commun. Mag., vol. 55, no. 5, pp. 94–100, 2017

work page 2017

[3] [3]

O-RAN: Disrupting the virtu- alized RAN ecosystem,

A. Garcia-Saavedra and X. Costa-P ´erez, “O-RAN: Disrupting the virtu- alized RAN ecosystem,”IEEE Commun. Standards Mag., vol. 5, no. 4, pp. 96–103, 2021

work page 2021

[4] [4]

RD-Probe: Scalable monitoring with sufficient coverage in complex datacenter networks,

R. Ding, X. Liu, S. Yang, Q. Huang, B. Xie, R. Sun, Z. Zhang, and B. Cui, “RD-Probe: Scalable monitoring with sufficient coverage in complex datacenter networks,” inProc. ACM SIGCOMM, Aug. 2024, pp. 258–273

work page 2024

[5] [5]

Enhancing network failure mitigation with performance-aware ranking,

P. Namyar, A. Ghavidel, D. Crankshaw, D. S. Berger, K. Hsieh, S. Kandula, R. Govindan, and B. Arzani, “Enhancing network failure mitigation with performance-aware ranking,” in22nd USENIX Symposium on Networked Systems Design and Implementation (NSDI 25). USENIX Association, Apr. 2025, pp. 335–357. [Online]. Available: https://www.usenix.org/conference/nsd...

work page 2025

[6] [6]

Impact of adaptive consistency on distributed SDN applications: An empirical study,

E. Sakic and W. Kellerer, “Impact of adaptive consistency on distributed SDN applications: An empirical study,”IEEE J. Sel. Areas Commun., vol. 36, no. 12, pp. 2702–2715, Dec. 2018

work page 2018

[7] [7]

Abstractions for network update,

M. Reitblatt, N. Foster, J. Rexford, C. Schlesinger, and D. Walker, “Abstractions for network update,” inProc. ACM SIGCOMM, Aug. 2012, pp. 323–334

work page 2012

[8] [8]

WirelessAgent: Large language model agents for intelligent wireless networks,

J. Tong, W. Guo, J. Shao, Q. Wu, Z. Li, Z. Lin, and J. Zhang, “WirelessAgent: Large language model agents for intelligent wireless networks,”China Commun., vol. 23, no. 3, pp. 265–285, Mar. 2026

work page 2026