--- title: 'ArachNet: Agentic Internet Measurement' url: https://www.emergentmind.com/topics/arachnet type: topic --- # ArachNet: Agentic Internet Measurement to=functions.exec_command ุ้นบาท json_parser code='{"cmd":"python - <<\'PY\'\nimport urllib.request, urllib.parse\nq=urllib.parse.quote(\'ti:ArachNet OR all:Towards an Agentic Workflow for Internet Measurement Research\')\nurl=f\'http://export.arxiv.org/api/query?search_query={q}&start=0&max_results=3\'\nprint(urllib.request.urlopen(url,timeout=20).read().decode(\'utf-8\')[:2000])\nPY"}' 彩神争霸快 code execution 无码不卡高清免费 to=functions.exec_command ,大香蕉_tool_output 盈立json_parser code='{"stdout":"\n \n ArXiv Query: search_query=ti:ArachNet OR all:Towards an Agentic Workflow for Internet Measurement Research&id_list=&start=0&max_results=3\n http://arxiv.org/api/q7XPAWQyA3nMXre4LeJkMGUO2hY\n 2026-07-03T00:00:00-04:00\n 69287\n 0\n 3\n \n http://arxiv.org/abs/2511.10611v1\n 2025-11-13T17:55:46Z\n 2025-11-13T17:55:46Z\n Towards an Agentic Workflow for Internet Measurement Research\n Internet measurement research faces an accessibility crisis: complex analyses\nrequire custom integration of multiple specialized tools that demands\nspecialized domain expertise. When network disruptions occur, operators need\nrapid diagnostic workflows spanning infrastructure mapping, routing analysis,\nand dependency modeling. However, developing these workflows requires\nspecialized knowledge and significant manual effort. We present ArachNet, the\nfirst system demonstrating that LLM agents can independently generate\nmeasurement workflows that mimics expert reasoning. Our core insight is that\nmeasurement expertise follows predictable compositional patterns that can be\nsystematically automated. ArachNet operates through four specialized agents\nthat mirr","stderr":"","exit_code":0}' ArachNet is an agentic framework for Internet measurement research that automates the expert reasoning process behind workflow composition. It is presented as the first system demonstrating that LLM agents can independently generate measurement workflows that mimics expert reasoning, particularly for Internet resilience tasks that require bespoke integration of specialized tools such as Nautilus, Xaminer, BGPStream, and Paris-Traceroute. Its stated objective is to collapse the barrier between a plain-English measurement goal and a fully executable Python workflow that mirrors an expert’s multi-tool analysis, while preserving the technical rigor required for research-quality analysis [2511.10611]. ## 1. Problem setting and scope Internet measurement research is framed as facing an accessibility crisis because complex analyses require custom integration of multiple specialized tools and corresponding domain expertise. The motivating examples are operationally significant tasks such as mapping submarine cables, analyzing BGP routing changes, and conducting traceroute-based latency forensics. In the formulation associated with ArachNet, these tasks traditionally require deep domain expertise, extensive manual coding, and days to weeks of human effort [2511.10611]. ArachNet addresses this setting by targeting workflow composition rather than replacing the underlying measurement systems. The input is a natural-language goal such as “Assess the country-level impact of a submarine cable cut,” and the intended output is a fully executable Python workflow produced within minutes. This suggests that the system is designed to operationalize measurement expertise as a sequence of reusable reasoning steps rather than as a monolithic code generator. The scope of the system is explicitly centered on Internet resilience scenarios. The paper notes that adaptation to security monitoring or application-performance domains would require prompt and registry re-engineering, indicating that the current design is not presented as domain-agnostic in a strong sense [2511.10611]. ## 2. Multi-agent architecture At the core of ArachNet is the claim that experts solve measurement problems through four predictable phases: Problem Decomposition, Solution Design, Implementation, and Registry Evolution. Each phase is encoded as a specialized LLM-driven agent operating over a central Registry of tool capabilities. The design choice is to isolate reasoning from raw code so that domain knowledge can be maintained without overwhelming the language model with thousands of lines of source code [2511.10611]. | Component | Phase | Output | |---|---|---| | QueryMind | Problem Decomposition | Structured sub-problems with dependencies, constraints, success criteria | | WorkflowScout | Solution Design | Candidate workflow architectures | | SolutionWeaver | Implementation | Executable Python code + embedded quality checks | | RegistryCurator | Registry Evolution | New Registry entries or refinements | QueryMind receives the natural-language goal and the Registry. Its logic is to parse the query into facets including spatial scope, temporal window, metric, and models; identify data gaps and potential failure modes; and emit a dependency graph in which each sub-problem is associated with required inputs and success tests. WorkflowScout then consumes these sub-problems and enumerates Registry functions satisfying the necessary input-output relations. It performs selective search, distinguishes simple from complex tasks, scores candidate architectures by number of tools, estimated runtime, and data fidelity, and resolves execution order to respect data dependencies [2511.10611]. SolutionWeaver converts the selected architecture into executable Python. The specified behavior includes generation of import statements, function wrappers, credential and configuration loading, data-format translation using registry-declared converters, assertions and sanity checks, and logging, error-handling, and optional visualization stubs. RegistryCurator operates on successful workflows and execution metadata, harvesting reusable patterns, validating them across at least three distinct workflows, and auto-generating new API descriptors in Registry format [2511.10611]. Agents communicate via structured JSON. QueryMind emits a JSON DAG of sub-problems, WorkflowScout returns a JSON workflow plan, SolutionWeaver consumes that plan to produce code, and RegistryCurator ingests logs of plan executions. This organization suggests a deliberately typed inter-agent interface rather than unconstrained natural-language handoff. ## 3. Registry model and compositional reasoning The Registry is described as a machine-readable catalog of measurement APIs. Each entry lists function name, inputs, outputs, and constraints, including rate limits, data coverage, and geographic scope. The examples given include `Nautilus.map_ip_to_cable(ip: IPv4) → List`, `Xaminer.analyze_failure(event: DisasterEvent, p_fail: Float) → ImpactReport`, `BGPStream.fetch_dumps(prefix: String, from: Date, to: Date) → BGPRecords`, and `ParisTraceroute.run(src: Probe, dst: Prefix) → TracePaths` [2511.10611]. ArachNet is said to automate four core reasoning patterns through the pipeline ```text Function ArachNetPipeline(query): subproblems ← QueryMind.decompose(query) designs ← WorkflowScout.explore(subproblems) best_design ← select_optimal(designs) code ← SolutionWeaver.generate(best_design) run_metadata ← execute(code) RegistryCurator.curate(run_metadata) return code ``` Within `WorkflowScout.explore`, the mechanism is described as candidate enumeration over Registry functions satisfying sub-problem requirements, pruning by complexity threshold, and then combining candidate paths across sub-problems while respecting data dependencies. This is a compositional search procedure over available measurement capabilities rather than an end-to-end direct synthesis method [2511.10611]. The paper’s central interpretive claim is that measurement expertise follows predictable compositional patterns that can be systematically automated. In ArachNet, those patterns are concretized as dependency-aware decomposition, tool-chain enumeration, architecture scoring, code generation with consistency checks, and subsequent curation of successful patterns back into the Registry. A plausible implication is that the Registry is not only a capability catalog but also the substrate for incremental institutionalization of workflow knowledge. ## 4. Workflow generation and implementation The workflow generation process is specified as a five-step procedure. First, a user submits a natural-language measurement goal. Second, QueryMind produces a “Problem Decomposition Report” that can include elements such as spatial scope, temporal window, metrics, and success criteria. The example given is a Europe-to-Asia submarine-route analysis over the last 30 days with metrics including latency, reachability, and AS-path changes, and the success criterion “detect ≥ 1 routing anomaly correlated with cable failure” [2511.10611]. Third, WorkflowScout outputs three candidate pipeline descriptions. The contrast between a direct pipeline and a multi-framework pipeline is explicit. A direct pipeline may be `Nautilus.map_ip_to_cables → Country.aggregate → Report`, whereas a multi-framework pipeline may involve Nautilus for affected IP identification, BGPStream for routing dumps, GraphModel for AS-dependency graph construction, CascadeAnalysis for failure simulation, and Report generation. In the example, Pipeline B is scored highest for comprehensive temporal-spatial analysis and selected [2511.10611]. Fourth, SolutionWeaver generates code. One example is approximately 525 lines of Python integrating `nautilus_api`, `bgpstream`, and `networkx`, with a `main(config)` entry point, staged mapping and BGP-dump retrieval, graph construction via `nx.DiGraph()`, and assertions such as `assert len(ips)>0, "No IPs found"`. Fifth, RegistryCurator observes recurring workflow patterns and promotes them into the Registry; the example is the addition of `IP_to_ASGraph` after recurrence of the three-step IP→BGP→Graph pattern across three scenarios [2511.10611]. Implementation is in Python 3.10. The system orchestrates calls to external measurement libraries and command-line tools, including Paris-Traceroute via a subprocess wrapper, BGPStream through its Python binding, Nautilus through a gRPC API, and Xaminer through a REST API. Configuration parameters such as API keys, rate limits, and geographic filters are stored in a YAML file loaded at runtime. This makes clear that ArachNet is an orchestration framework over heterogeneous external systems, not a standalone measurement engine [2511.10611]. ## 5. Evaluation methodology and empirical results The evaluation covers nine Internet-resilience scenarios across three difficulty levels. The key metrics are Success Rate (SR), defined as the fraction of workflows that produce expert-equivalent results; Workflow Generation Time ($T_{\mathrm{gen}}$), defined as wall-clock time from query to code emission; Resource Overhead ($R$), defined as the number of external tool invocations and data volume processed; and F1 for anomaly detection in the forensic case. A workflow is designated correct when its key output matches ground truth within a 5% tolerance [2511.10611]. The performance summary reported for four cases shows increasing code length and resource overhead as scenario complexity rises. Case 1 (Cable Impact) uses 250 lines of code, achieves SR of 1.00, has $T_{\mathrm{gen}}=45$ s, and requires 4 invocations. Case 2 (Multi-disaster) uses 300 lines of code, also achieves SR of 1.00, has $T_{\mathrm{gen}}=52$ s, and requires 3 invocations. Case 3 (Cascading Fail) uses 525 lines of code, achieves SR of 0.92, has $T_{\mathrm{gen}}=75$ s, and requires 8 invocations. Case 4 (Forensic Root) uses 750 lines of code, achieves SR of 0.89, has $T_{\mathrm{gen}}=120$ s, and requires 12 invocations [2511.10611]. The paper further reports that paired t-test comparisons between expert- and ArachNet-driven outputs yield $p < 0.01$ for all scenarios, with the interpretation that there is no meaningful difference in final impact metrics or identified failure events. The abstract similarly states that generated workflows match expert-level reasoning and produce analytical outputs similar to specialist solutions, while handling complex multi-framework integration that traditionally requires days of manual coordination [2511.10611]. These results support a specific claim: the primary contribution is not merely code synthesis speed, but the ability to compose technically credible, dependency-aware measurement workflows whose outputs align with specialist analyses under the stated correctness criteria. ## 6. Case studies, limitations, and prospective extensions Two case studies illustrate the system’s behavior on concrete tasks. In the SEA-ME-WE-5 failure scenario, the generated workflow consists of `Nautilus.map_ip_to_cables → IP_suspects`, `GeoLocator.ip_to_country(IP_suspects) → Country_counts`, and `ReportGenerator.plot_bar(country, impact_pct)`. The reported output is a bar chart matching Xaminer’s published results within ±2% [2511.10611]. In the latency-spike forensic scenario, the goal is to correlate a 20 ms median latency jump across Europe→Asia probes with a submarine cable fault. The generated workflow includes time-series traceroute collection over the last 7 days, anomaly detection with $\alpha = 0.05$, cable mapping of destination IPs, BGP dump retrieval before and after the anomaly, routing-change detection, and likelihood scoring over candidate cables. The output is “SMW-3” flagged with confidence 0.87, matching manual expert analysis [2511.10611]. Several limitations are explicitly identified. Minor syntax or API-mismatch errors still occur in generated code, motivating possible integration of a Python-AST verifier or automated testing harness. The current design is tailored to Internet resilience, and adaptation to other domains would require prompt and registry re-engineering. Trust and verification remain open challenges, with proposed future work including meta-agents for cross-validating multiple independent workflow generations and formal correctness checks such as data-flow type verification. Additional open problems include adjudicating contradictory outputs, for example BGP versus traceroute paths, via confidence scoring or fallback strategies; supporting Model Context Protocol (MCP) and Agent-to-Agent (A2A) standards for interoperability; and scaling RegistryCurator by mining tool repositories and documentation to detect capability changes across hundreds of evolving measurement frameworks [2511.10611]. A recurrent misconception would be to treat ArachNet as a replacement for domain tools or expert validation. The system is instead described as a multi-agent mechanism for composition, orchestration, and curation over existing measurement frameworks. Its significance therefore lies in formalizing and automating the systematic reasoning process that experts use when assembling multi-tool Internet measurement workflows. Source: https://www.emergentmind.com/topics/arachnet