Paper deep dive
A T-API-Compliant ReAct Agentic Loop for Optical Networks: Generic vs. Domain-Specific Tool Abstractions
Seyed Morteza Ahmadian, Paolo Monti, Carlos Natalino
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 95%
Last extracted: 6/21/2026, 1:29:00 AM
Summary
The paper presents the first T-API-compliant ReAct (Reasoning and Act) agentic loop designed for autonomous optical network management. The research compares generic HTTP/RESTCONF tool abstractions against domain-specific T-API tool abstractions (comprising 12 atomic and 4 composite operations). Experimental results using Qwen LLMs on a CORONET CONUS topology demonstrate that domain-specific composite tools significantly improve correctness (up to 90% for Qwen2.5-32B-Instruct) and reduce token consumption (threefold savings) compared to generic tools, highlighting that tool-layer abstraction is a critical lever for agent performance in optical networking.
Entities (7)
Relation Signals (4)
Domain-Specific Tools â improves â Correctness
confidence 100% ¡ domain-specific tools significantly increase correctness, reduce token usage, and suppress hallucinations
ReAct Agentic Loop â uses â T-API
confidence 100% ¡ We present the first T-API-compliant reasoning and act (ReAct) loop.
Qwen2.5-32B-Instruct â powers â ReAct Agentic Loop
confidence 90% ¡ The ReAct agent layer is implemented on top of an LLM runtime... Qwen2.5-32B-Instruct... primary baseline
Digital Twin â validates â ReAct Agentic Loop
confidence 90% ¡ digital twins (DTs) have emerged as safe sandboxes in which actions proposed by large language models (LLMs) can be validated
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Optical networks need intent-driven, closed-loop agentic management, a key enabler for higher autonomy levels. We present the first T-API-compliant reasoning and act (ReAct) loop. We show that domain-specific composite tools achieve 90% oracle-validated correctness with threefold token savings compared to generic tools.
Tags
Links
- Source: https://arxiv.org/abs/2606.18000v1
- Canonical: https://arxiv.org/abs/2606.18000v1
Trouble viewing inline? Open PDF directly â
Full Text
19,419 characters extracted from source content.
Expand or collapse full text
A T-API-Compliant ReAct Agentic Loop for Optical Networks: Generic vs. Domain-Specific Tool Abstractions Morteza Ahmadian, Paolo Monti, Carlos Natalino Department of Electrical Engineering, Chalmers University of Technology, Gothenburg, Sweden. seyedah@chalmers.se,mpaolo@chalmers.se,carlos.natalino@chalmers.se Abstract Optical networks need intent-driven, closed-loop agentic management, a key enabler for higher autonomy levels. We present the first T-API-compliant reasoning and act (ReAct) loop. We show that domain-specific composite tools achieve 90% oracle-validated correctness with threefold token savings compared to generic tools. Š 2026 The Authors Introduction The telecommunications industry is still operating at low autonomy levels (L2âL3), while higher levels (e.g., L4) are targeted for 2030 [1]. In this context, both IMT-2030 and the ETSI Zero-touch network and Service Management (ZSM) framework [2, 3] establish intent-driven, closed-loop, agentic op- erations as the target operating model. Mean- while, digital twins (DTs) have emerged as safe sandboxes in which actions proposed by large language models (LLMs) can be validated before being instantiated in production networks [4]. The Transport Application Programming Inter- face (T-API) is a standard, vendor-neutral north- bound interface for multi-vendor, disaggregated optical network control. Nevertheless, agentic- LLM work in optical networking has so far targeted device-level YANG models [5â9], vendor spe- cific software-defined networking (SDN) APIs [10â 12], and proprietary simulators [13â15], leav- ing the standardized, vendor-neutral T-API north- bound unexplored. LLM-driven optical control has been demonstrated in field trials over NET- CONF/YANG with plan-and-execute or reasoning and act (ReAct) sub-loops [6, 10], over OpenCon- fig/NETCONF with fixed multi-agent pipelines [7, 8], and over vendor-specific SDN APIs with multi- agent orchestration [11]. Simulator-only and tuto- rial works complete the picture [13, 14]. Only [16] has explicitly addressed T-API, and did so as a vendor-code mediator with a fixed classifier- generator-validator pipeline, not as a ReAct agent for autonomous management. Graph-based agents provide a deterministic set of steps that the agent had to go through, including the execution of heuristics. Meanwhile, ReAct- based agents do not follow a pre-defined set of steps, and can decide which set of steps to take, tools to call, or to interact with the user by e.g. asking for further details. In the meantime, tool abstraction has been stud- ied contrasting code versus structured outputs [17], Model Context Protocol (MCP) versus code gener- ation [12], and generic application interfaces [18]. First attempts at standardized benchmarks ex- ist [19, 20], but they rely on LLM-as-judge or human rubrics, and hallucination is at best qual- itatively catalogued [13, 21].MCPfor network management has been proposed but neither im- plemented nor measured [22]. Once the LLM is capable enough (14B-class and above according to current studies [12, 14]), the dominant lever on success rate and efficiency shifts from model capa- bility to the tool layer. Nevertheless, no prior work measures how the tool abstraction itself affects correctness, token efficiency, and hallucination on the same agent. To this end, we present, to the best of our knowl- edge, the first T-API-compliant ReAct agentic loop for optical networks, together with the first con- trolled comparison of generic Hypertext Transfer Protocol (HTTP) tools against a domain-specific T-API tool layer (12 atomic and 4 composite opera- tions) on a common agent and scenario suite. We evaluate 10 scenarios covering querying, analysis, provisioning, and multi-turn workflows, with an au- tomated oracle that separates execution success from answer correctness and identifies each agent failure. Results demonstrate that domain-specific tools significantly increase correctness, reduce to- ken usage, and suppress hallucinations relative to raw protocol interaction, with the abstraction effect exceeding the model-choice effect. The proposed framework constitute a step toward principled stud- ies of future agentic T-API adapters. T-API-Compliant ReAct Agentic Architecture Fig. 1 illustrates the proposed architecture. A Re- Act reasoning loop drives a tool layer that targets a T-API RESTCONF northbound, covering topology, connectivity, photonic-media, path-computation, and equipment contexts. The tool layer can be chosen between generic and domain-specific ab- stractions without altering either the agent or the northbound, which isolates the abstraction as the sole independent variable. The ReAct agent layer is implemented on top of an LLM runtime. Unlike fixed multi-agent pipelines arXiv:2606.18000v1 [cs.NI] 16 Jun 2026 Agentic Layer ReAct loop ReasonActObserve Tool calls Abstraction Layer (Tools) Tool layer (swappable) Generic HTTP/RESTCONF (2 tools: GET and POST) Composite Domain-Specific T-API-based Operations (4 tools) Control Plane T-API topology ⢠connectivity photonic-media path-computation ⢠equipment Time-Series Database Path Computation Element Inventory Data Plane Device-specific API EDF A EDFA EDF A T-API TRXROADM ROADM ROADMTRX Optical network ... Atomic Domain-Specific T-API Operations (12 tools) Fig. 1: The T-API-Compliant ReAct Agentic Architecture. [7, 8, 16] and plan-and-execute prior work [6, 20], our loop iteratively reasons, calls a tool, observes, and decides dynamically, according to instructions. Two tool alternatives share the same agent and the same control and data planes. The first al- ternative employs generic HTTP tools, that is, two primitives (GET/POST with URL and body) following the philosophy of [18], where the LLM must construct and interpret T-API paths and mes- sages by itself. The second alternative exposes 16 typed operations (12 atomic and 4 compos- ite) covering topology browsing, path computation, modulation selection, connectivity lifecycle, and GNPy-based quality-of-transmission (QoT) esti- mation and optical performance monitoring (OPM) telemetry. Experimental Setup Our setup uses aDTacting as the northbound T-API. TheDTcombines a GNPy-based QoT en- gine [23], a NetworkX topology and inventory, and routing based on [24]. Our results are ob- tained using the CORONET CONUS topology (75 reconfigurable optical add-drop multiplexers (ROADMs) and 198 fiber spans) operated in the C-band, according to the GNPy-provided example configuration files. Three tool abstractions targeting the same north- bound are evaluated, varying the level of T-API specific manipulation required by the LLM pow- ering the agent. The generic HTTP/RESTCONF option exposes two primitives:http_request (read-only GET) andhttp_request_mutate (POST/PUT/PATCH/DELETE). Under this option the LLM constructs RESTCONF paths and JSON, resolves service-interface-point (SIP) universally unique identifiers (UUIDs), navigates raw YANG-model JSON, and composes POST bodies itself. The single-call tools abstraction comprises 12 atomic operations, each of which maps 1:1 to a T-API endpoint or performs pure in-process filtering over another atomic toolâs out- put, namelylist_nodes,get_node_details, get_link_details,list_services, get_service_details,get_service_path, get_equipment,get_spectrum_overview, get_opm_service,find_degraded_services, estimate_qot, and delete_service. The multi-call tools abstraction adds 4 com- posite operations on top of the single-call set:get_topology_summary,compute_paths, find_best_modulation(cascaded DP-64QAM to DP-16QAM to DP-QPSK via up to three estimate_qotcalls), andprovision_service. These tools make it easier for the agent to execute operations that naturally require multiple interac- tions with the network through the T-API. The scenario suite contains 10 scenarios span- ning querying (Q1âQ4), analysis (A1âA3), pro- visioning (P1âP2), and multi-turn flows (MT1). It spans the lifecycle categories of [19] and [6] while being grounded in T-API semantics. Node- dependent scenarios randomize source and desti- nation pairs on every run by sampling live SIP end- points from the topology. Representative cases include A1 (best modulation query on a routable path), A2 (modulation feasibility on potentially long, high-loss paths), A3 (k-shortest paths with compar- ative QoT estimates), P1 (lightpath provisioning after a QoT feasibility check), P2 (400G service attempt on a potentially infeasible path), and MT1 (explore-then-act across two turns). Consistent with the data-sovereign motivation of [8, 10, 14], four open on-premisesLLMs from the Qwen family are evaluated: Qwen2.5-32B-Instruct (dense transformer fine-tuned for tool calling, pri- mary baseline at temperature 0.0), Qwen3.5- 35B (mixture-of-experts model activating only a sparse subset of parameters per token), Qwen3.5- 9B (dense mid-range model), and Qwen3.5-4B (compact dense model stress-testing resource- constrained deployments). Each LLM, tool ab- straction, and scenario combination is executed for 20 runs for statistical significance. The agent is implemented with LangGraph, and all inference runs locally via vLLM on a single NVIDIA RTX 6000 GPU with 96 GB. Two metrics are collected per run. The suc- cess rate reports oracle-validated answer correct- Qwen2.5 32B InstQwen3.5 35BQwen3.5 9BQwen3.5 4B (a) LLM 0% 20% 40% 60% 80% Eval Pass Score [%] 57% 58% 57% 20% 36% 27%27% 18% 90% 55% 54% 28% Variant Generic Single-Call Tools Multi-Call Tools Qwen2.5 32B InstQwen3.5 35BQwen3.5 9BQwen3.5 4B (b) LLM 0k 10k 20k 30k 40k Mean Total Tokens per Run 30.3k 31.5k 37.6k 35.9k 10.1k 21.3k 16.6k 39.2k 10.6k 45.0k 21.1k 18.8k Variant Generic Single-Call Tools Multi-Call Tools Fig. 2: Evaluation pass rate (a) and mean total tokens per run (b) for different LLM models and tool abstractions. ness, combining tool-presence checks with value checks against ground-truth quantities fetched from theDT. The oracle further types each failure as zero-tool, wrong-value, wrong-modulation, or missing-grounding, thereby extending the quali- tative taxonomies of [13] and [21]. Provisioning is scored in two stages: a presence layer con- firming thatprovision_servicereturned a ser- vice UUID (HTTP 201), and an oracle-correctness layer verifying modulation selection against the pre-computedbest_modulationand, on infeasi- ble paths, the agentâs ability to refuse provisioning. Token usage captures the total number of tokens sent to and produced by theLLMas a measure of cost of the operations. Note that in our case, as well as in real-world scenarios, token usage is accounted for regardless of agent success. Numerical Results Fig. 2(a) shows the success rate and Fig. 2(b) the mean total number of tokens per run across the four LLMs and three tool abstractions. The results reveal that, under the tested conditions, both tool abstraction andLLMare decisive on both correctness and cost. The clearest signal comes from the generic tool abstraction, where the pass rate flattens at approx- imately 57â58% across the larger models, despite nearly a fourfold spread inLLMsize. Token us- age is uniformly high (30kâ38k per run). The suc- cess rate of the smallest model collapses to 20%. Therefore, the solution using generic tool abstrac- tion uses more tokens without higher success, and saturates success rate below 60% regardless of scale. Against this saturation plateau, the enhanced multi-call abstraction unlocks a decisive improve- ment: Qwen2.5-32B-Instruct improves from 57% under generic tools to approximately 90% un- der composite tools â a gain exceeding 30% â while its token usage drops to roughly 10.6k per run, among the lowest in the whole experiment. Tool-calling fine-tuning pays off simultaneously on both axes. This result confirms that the size-vs- grounding observations of [14] and [20] are also observed here. The results suggest that for T-API agentic control, combining an instruction-tuned tool-calling LLM with typed composite tools domi- nates over LLM size. The other models, however, show that com- posite tools alone are not a sufficient forLLMs not prepared for tool calling. Exposing atomic single-call tools still forces the agent to orchestrate multi-step T-API flows (SIP resolution,QoTestima- tion, cascaded modulation screening, path cross- comparison), and non-instruct mid-range models (Qwen3.5-9B, Qwen3.5-35B) collapse under this orchestration burden. The success rate roughly halves relative to the instruction-tuned model on composite tools, and Qwen3.5-35B consumes the highest number of tokens among the tested setups, with up to 45k tokens. Qwen3.5-4B remains below 28% success rate on every abstraction regardless of token usage, indicating a floor on capability be- low which tool-layer design cannot compensate. Composite tools absorb recurring flows into deter- ministic logic, but only models fine-tuned to invoke them reliably translate that abstraction into correct- ness gains. Conclusions We introduced the first T-API-compliant ReAct agentic loop for optical networks. We bench- marked generic vs.domain-specific tool ab- stractions through an oracle validator with a domain-specific procedures. The results showed that agents become operationally viable once grounded in T-API-aware tools, but need to be based onLLMs optimized for tool calling. The pro- posed architecture combining a ReAct agent and domain-specific tools whose signatures map di- rectly onto T-API objects, can be dropped into any T-API-compliant domain controller. Future work may target a T-API MCP server that mimics our 16 domain-specific tools but allowing remote ex- ecution. Porting the tool layer to MCP would test whether the MCP wire format would preserve the correctness gains measured in this work. Acknowledgements The work presented in the paper originated from the EUREKA CELTIX-NEXT SUSTAINET- Advance Flagship project supported (in Sweden) by the Swedenâs Innovation Agency VINNOVA (Dnr: 2025-02987). References [1]R. Webb and D. Bushaus, âAutonomous networks: In search of best practiceâ, TM Forum, Tech. Rep., Dec. 2024, p. 51. [2] ITU-R, âFramework and overall objectives of the future development of IMT for 2030 and beyondâ, International Telecommunication Union, Geneva, Switzerland, Rec- ommendation ITU-R M.2160-0, Nov. 2023. [3]ETSI ISG ZSM, âZero-touch network and service man- agement (ZSM); intent-driven closed loopsâ, European Telecommunications Standards Institute, Sophia Antipo- lis, France, Group Specification ETSI GS ZSM 016 V1.1.1, Oct. 2024. [4]D. Wang et al., âThe role of digital twin in optical com- munication: Fault management, hardware configuration, and transmission simulationâ, IEEE Communications Magazine, vol. 59, no. 1, p. 133â139, Jan. 2021. DOI: 10.1109/MCOM.001.2000727 [5]X. Liu et al., âFirst field trial of llm-powered ai agent for lifecycle management of autonomous driving optical networksâ, in 2025 Optical Fiber Communications Con- ference and Exhibition (OFC), Mar. 2025, Th1A.2. DOI: 10.1364/OFC.2025.Th1A.2 [6]X. Liu, Y. Zhang, Q. Qiu, Y. Cheng, W. Hu, and Q. Zhuge, âField trial of an llm-powered ai agent for autonomous optical networks: A full-lifecycle demonstrationâ, Jour- nal of Optical Communications and Networking, vol. 18, no. 5, A179, May 2026. DOI: 10.1364/JOCN.575402 [7]H. Zaid, P. Safari, B. Shariati, A. Jafari, M. Balanici, and J. K. Fischer, âMulti-agent design for llm-assisted network managementâ, in 2025 Optical Fiber Commu- nications Conference and Exhibition (OFC), Mar. 2025, W1A.4. DOI: 10.1364/OFC.2025.W1A.4 [8]B. Shariati et al., âData sovereign llm-assisted automa- tion platform for open optical and packet transport networksâ, in 2025 IEEE International Conference on Machine Learning for Communication and Network- ing (ICMLCN), May 2025, p. 1â6. DOI:10 . 1109 / ICMLCN64995.2025.11140539 [9]A. Zhou, Y. Song, Y. Zhang, M. Zhang, and D. Wang, âLarge language model-driven ai agent in sdn controller towards intent-based management of optical networksâ, in ECOC 2024; 50th European Conference on Optical Communication, Sep. 2024, p. 1595â1598. [10]H. Huang et al., âField trial of llm-based autonomous net- work management with ai-agent in real-time 400g/800g elastic optical networkâ, in 2025 European Confer- ence on Optical Communications (ECOC), Sep. 2025, p. M.03.01.3. DOI:10 . 1109 / ECOC66593 . 2025 . 11263349 [11] X. Xu et al., âCross-domain orchestration with multi- agent llm framework for enhanced task automationâ, in 2025 Optical Fiber Communications Conference and Exhibition (OFC), Mar. 2025, M3Z.10. DOI:10.1364/ OFC.2025.M3Z.10 [12] Z. Wang et al., Agentic ai for scalable and robust opti- cal systems control, Feb. 2026. DOI:10.48550/arXiv. 2602.20144 arXiv: 2602.20144 [eess]. [13] X. Jiang et al., âOpticomm-gpt: A gpt-based versatile research assistant for optical fiber communication sys- temsâ, Optics Express, vol. 32, no. 12, p. 20 776â 20 796, Jun. 2024. DOI: 10.1364/OE.522026 [14] T. Tanimura and N. Kikuchi, âOn-premises small lan- guage model agent with physics-aware reasoning for optical network optimizationâ, in Optical Fiber Communi- cation Conference (OFC), 2026, Th2A.33. [15]S. Shen et al., âLLM-enhanced digital twin framework in optical networksâ, in Optical Fiber Communication Conference (OFC), 2026, M4A.6. [16]A. Jafari et al., âLlm assistant for tapi context and client code translationâ, in 2025 European Conference on Op- tical Communications (ECOC), Sep. 2025, p. M.03.01.2. DOI: 10.1109/ECOC66593.2025.11263212 [17] C. Wang, M. Scazzariello, A. Farshin, S. Ferlin, D. Kosti Ě c, and M. Chiesa, âNetConfEval: Can LLMs facilitate net- work configuration?â, Proceedings of the ACM on Net- working, vol. 2, no. CoNEXT2, 7:1â7:25, Jun. 2024. DOI: 10.1145/3656296 [18]Y. Qin et al., âToolllm: Facilitating large language models to master 16000+ real-world apisâ, in International Con- ference on Learning Representations, vol. 2024, May 2024, p. 9695â9717. [19]Y. Zhang, Q. Qiu, J. Wu, X. Liu, W. Hu, and Q. Zhuge, âAutoonbench: A benchmark for large language model agents in autonomous optical networksâ, Journal of Op- tical Communications and Networking, vol. 18, no. 9, p. D1âD15, Sep. 2026. DOI: 10.1364/JOCN.589201 [20]D. Wang, Y. Wang, X. Jiang, Y. Zhang, Y. Pang, and M. Zhang, âWhen large language models meet opti- cal networks: Paving the way for automationâ, Elec- tronics, vol. 13, no. 13, Jun. 2024. DOI:10 . 3390 / electronics13132529 [21]D. Yuan, H. Zhou, X. Liu, H. Chen, Y. Xin, and J. Zhang, âEnhancing large language models (LLMs) for telecom using dynamic knowledge graphs and explain- able retrieval-augmented generationâ, IEEE Wireless Communications, 2026, Accepted; arXiv:2602.17529. [22]Y. Yang, Q. Wu, D. Lopez, N. R. Moreno, and L. Tailhar- dat, âApplicability of MCP for the network managementâ, Internet Engineering Task Force, Internet Draft draft- yang-nmrg-mcp-nm-02, Feb. 2026. [23] V. Curri, âGnpy model of the physical layer for open and disaggregated optical networking [invited]â, Journal of Optical Communications and Networking, vol. 14, no. 6, p. C92âC104, Jun. 2022. DOI: 10.1364/JOCN.452868 [24] C. Natalino et al., âOptical networking gym: An open- source toolkit for resource assignment problems in opti- cal networksâ, Journal of Optical Communications and Networking, vol. 16, no. 12, G40âG51, Dec. 2024. DOI: 10.1364/JOCN.532850