Renwei (Richard) Li and Biwei Li (Southeast University, China), Nadjib Aitsaadi (Paris-Saclay), Tarik Taleb (Ruhr University Bochum), Cedric Westphal (UC Santa Cruz), Tao Huang (Purple Mountain Laboratories), Luca Foschini (Bologna), Zuqing Zhu (USTC). arXiv:2610.28244, submitted 20 October 2026. 26 pages, 45 references.
Sources: sources/whitepapers/2026-10-25-li-agentic-communication-networks.pdf
(immutable original) and its Markdown twin
sources/whitepapers/2026-10-25-li-agentic-communication-networks/2026-10-25-li-agentic-communication-networks.md
(Marker, 2026-10-25, --disable_ocr). Cited against the Markdown. One of
six tables converted through pdftext; the remainder are the table of
contents and figure captions, and nothing load-bearing was lost. The eight
figures are scenario diagrams, extracted as JPEGs alongside the twin and
not transcribed.
Handed over by Martin Pompéry, 2026-10-25.
What kind of document this is
A white paper: no results, no implementation, no evaluation. It defines a term, claims a scope for it, and lists research and standardisation opportunities. Read it as a position being staked on a future standardisation agenda, not as a finding.
The author list is academic and deliberately multi-regional (China, France, Germany, USA, Italy). ⟨Inference: the composition reads as an attempt to give the term international standing before it reaches a standards body. The references cite 3GPP TS 23.501 and ETSI GS ENI 005, which is where such a proposal would land.⟩
⟨Background: the first author brings the Big Packet Protocol (BPP) lineage, which §2.4 names as “a possible starting point for a network-layer realization within this design space” [13]-[15]. BPP comes out of the “New IP” proposals, which were contested in ITU and IETF over precisely the question of how much application-level meaning belongs in the network layer. The paper does not mention that history.⟩
The thesis
“Agentic Communication Networks (ACN) refer to communication networks that provide native support for autonomous agents as first-order network entities and enable their trusted, intent-aware, policy-compliant, and task-oriented interactions across heterogeneous communication, computing, sensing, storage, data, and service infrastructures.” (§2.1)
The argument by analogy (§1): networks have repeatedly re-based their abstractions on the entities they connect — hosts, then users and devices, then IoT endpoints, then services and compute. Agents are claimed as the next such transition, because an agent “may run across multiple devices, migrate between edge and cloud, act for different principals under different authorities, invoke multiple tools, delegate subtasks to other agents, and participate in long-lived task execution across organizational or administrative boundaries” (§1). An IP address, a device identity or a service endpoint therefore cannot represent it.
Three architectural gaps (§2.5) and three corresponding logical planes (§3.1):
| Gap | Plane | Question it answers |
|---|---|---|
| Entity | Agent Entity Plane | Who is acting, for whom, under what authority, for how long |
| Service | Agentic Service Plane | What is to be accomplished — intent, capability, context, policy, constraint, task state |
| Execution | Agentic Execution Plane | How the task is carried out across agents, services, tools, domains |
⟨The paper’s own naming is inconsistent: §3 introduces the third plane as the “Network Coordination Plane”, the heading in §3.1 calls it “Network Execution Plane”, and the body text and §8 call it the “Agentic Execution Plane”. Three names for one object inside four pages. Recorded, not resolved — “Agentic Execution Plane” is used here because the conclusion uses it.⟩
The planes sit above existing infrastructure: “They do not replace routing, transport, resource management, cloud platforms, edge systems, sensing control, or application services” (§3).
Six network-visible expressions
§2.3 enumerates what agentic communication adds to source/destination/QoS. This list is the paper’s most reusable contribution, because it is the attempt to fix a vocabulary:
- Identity — which agent acts, under which principal, credential, role, authority
- Intent — a controlled representation of the task objective
- Capability — which function, tool, model, sensor, actuator, data source or service is requested or provided
- Context — location, time, environment, network state, service state, operational mode
- Policy — privacy, security, safety, compliance, trust, cost, administrative domain
- Task state and result — progress, dependency, intermediate results, confidence, failure conditions
The question at the centre
§7.2, set as a display line in the original:
“What is the minimum network-relevant information required to support an agentic task?”
With the framing that matters: “An agent may possess extensive private context, reasoning history, memory, goals, and application state. Most of this information should never be required by the network. ACN therefore needs to identify a narrow and stable boundary between application semantics and network-relevant service semantics” (§7.2). And earlier, in §1: “a rigorous agentic network architecture must preserve the separation between private content and network-visible service expressions.”
⟨Inference: this is structurally the same problem as the confidentiality gap in ledger-based carbon accounting — a coordinating layer that must see enough to act and not enough to expose. Both documents state the requirement well and supply no mechanism for it. The difference worth noting is that the ICC Review omits the requirement after stating it, whereas this paper keeps returning to it and makes it the headline research question of a whole section.⟩
Native capabilities and candidate mechanisms
§4 names five network capabilities — registration and discovery, service orchestration, QoS assurance, protocol translation, trusted security. §5 proposes mechanisms for each. Three are worth recording in detail.
Registration and discovery (§5.1). Each agent gets an Agent ID bound to identity, organisation, network location, credentials, capabilities, service interfaces, resource requirements and status, maintained as a dynamic Agent Profile by heartbeat and event updates. Heterogeneous capability descriptions are normalised through “standardized capability ontologies, knowledge graphs, and semantic embeddings”; matching is done by vector retrieval, Graph-RAG and LLM-based intent analysis; candidates are ranked by capability relevance, load, service quality, reliability, reputation and prior collaboration performance.
Protocol translation (§5.4). An Agent Exchange Gateway translates MCP, A2A, ACP and domain-specific protocols into a Protocol-Independent Intermediate Representation (PIIR) carrying message metadata, task semantics, capabilities, context, interaction state and security policies. Pipeline: parsing → PIIR generation → target reconstruction → runtime validation. A plug-in architecture means a new protocol needs only its bidirectional mapping to the PIIR, “reducing the complexity of supporting n protocols from O(n²) pairwise mappings to O(n)”. Candidate techniques include embedding-based alignment and LLM-assisted parsing. See Agent protocol interoperability for the reading against SINE’s own experience of this argument.
Trusted security (§5.5). A zero-trust mechanism combining unique identities, certificates, cryptographic signatures and dynamic trust evaluation, with policy engines enforcing least privilege, runtime monitoring for prompt injection and anomalous collaboration, risk-aware privilege restriction and isolation, and “standardized audit logs and tamper-resistant records”. Candidate technologies: DIDs, PKI, digital signatures, MFA, zero-trust access control, capability-based authorisation, policy engines, guardrails, anomaly detection, security knowledge graphs, trusted computing, confidential communication, blockchain-based evidence preservation, trusted timestamps.
Zero-knowledge proofs, secure multi-party computation and attestation of an agent’s own reasoning appear nowhere in the document. The nearest approaches are “trusted computing” and “confidential communication”, both unelaborated single terms in the §5.5 candidate list.
Use cases (§6)
Five, each given a scenario, a “why ACN is needed” paragraph and a requirements list: dynamic collaboration (a civic coordinator assembling a temporary multi-owner team for a public event), intent-driven services (coastal inspection before a storm), cross-domain cooperation (operator, municipal emergency and utility networks forming a temporary resilience federation during an outage), task-aware data exchange (drone, ground robot and edge agent inspecting a wind farm, where information value shifts across task stages), and industrial embodied agents (a flexible microfactory replanning around an unavailable robot).
§6.4 is the one place the paper cites empirical work, on semantic-aware resource allocation [43]-[45], and it marks its own evidence honestly: the results are “based on simulation or prototype settings, including idealized reconstruction assumptions in parts of the vehicular evaluation, so these mechanisms should be treated as candidate ACN capabilities whose task-level benefit must be verified in deployment.”
Research challenges (§7) — three stated principles
The paper sets three claims as display lines:
- §7.1: “An agent should remain a recognizable and accountable network entity even when its endpoint, runtime, or communication session changes.”
- §7.3: “ACN should support distributed agentic execution while allowing agents, services, and underlying infrastructures to retain their own decision and control mechanisms.”
- §7.4: “Agents may reason, propose, negotiate, and coordinate, but execution remains bounded by policy, authorization, feasibility, and enforcement.”
§7.4 also contains the paper’s sharpest single sentence, and the one it does not follow through:
“If an agent delegates a task, another agent selects a service, and the network coordinates the underlying resources, accountability cannot be established solely from packet logs. ACN needs an auditable relationship among authority, decisions, actions, and outcomes.”
The treatment of that sentence is developed on Agent identity and delegated authority.
Reading for SINE
⟨Inference throughout this section.⟩
- Same premise as CCTI, different answer. The paper’s motivating condition is agents interacting across administrative boundaries with “no prior relationship” (§7.1) — which is CCTI’s thesis sentence in other words. Its answer is identity infrastructure plus policy enforcement plus tamper-evident logging. CCTI’s is cryptographic verifiability. Neither document knows about the other. This is the clearest available picture of what the networking community will build if the cryptographic layer is not offered to it.
- Third independent instance of the same omission. The wiki already carries the ICC Review stating confidentiality and supplying no mechanism, and iLEAP answering confidentiality by aggregation. ACN answers it by authorisation and audit. Three communities, three domains, the same gap, none of them reaching for cryptography. ⟨That is now a pattern rather than three observations, and it is an argument about demand, not about technology: the instrument is not being rejected, it is not being considered. Filed as an open task.⟩
- An audience, not a competitor. ACN proposes nothing SINE builds and builds nothing SINE proposes. It names, in its own vocabulary, the exact points where attested evidence would be the answer — and reaches for a log instead.
- Capability vocabulary as an unaddressed coordination problem. The whole architecture depends on heterogeneous agents converging on shared capability descriptions (§5.1, §5.3, §5.4), and the paper never asks how that convergence happens absent a central registry. §5.3 warns that rebinding must not “silently change the meaning of its intent, capabilities, or task state” — the risk of semantic drift under re-coordination. ⟨This is a naming game, unnamed. Relevant to the foundational-games question raised for CCTI by Martin Pompéry on 2026-10-23; no wiki page on that yet.⟩
- A governance reading the paper does not take. A network layer that makes agent identity, task association and task state visible to forwarding nodes is also a network layer that makes agent activity legible to whoever operates those nodes. The paper’s safeguard is the phrase “minimum disclosure” and the insistence that privacy “must therefore be considered when defining every ACN information element, not added as a separate protection mechanism after the architecture is established” (§7.4) — a sound principle with no mechanism attached, in a document that elsewhere proposes binding Agent IDs and task state to packets (§2.4).
Related
- Agent identity and delegated authority — the accountability-as-identity reading
- Agent protocol interoperability — §5.4 against PACT/iLEAP experience
- CCTI · Cryptographic trust infrastructure · Epistemic Integrity Certificate
- Coordination failure vs. bargaining failure
- The confidentiality gap in ledger-based carbon accounting · iLEAP · PACT Pathfinder Network
- Ostrom’s commons design principles — “without monitoring, there can be no credible commitment”