-
Notifications
You must be signed in to change notification settings - Fork 11
Expand file tree
/
Copy pathindex.html
More file actions
580 lines (444 loc) · 63.8 KB
/
index.html
File metadata and controls
580 lines (444 loc) · 63.8 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Agent Network Protocol White Paper</title>
<script src="https://www.w3.org/Tools/respec/respec-w3c" class="remove"></script>
<script class='remove'>
// See https://github.com/w3c/respec/wiki/ for how to configure ReSpec
var respecConfig = {
specStatus: "CG-DRAFT",
shortName: "agent-network-protocol-whiter-paper",
editors: [
{
name: "Gaowei Chang",
company:"ANP Open Source Community",
companyURL:"https://agent-network-protocol.com/"
},
{
name: "Ruoxi Ran",
company: "W3C",
companyURL: "https://www.w3.org/"
}
],
authors: [
{
name: "Song Xu",
company: "China Mobile",
companyURL: "https://www.chinamobileltd.com"
},
{
name: "Hong Hou",
company: "Peking University",
companyURL: "https://www.pku.edu.cn"
},
{
name: "Xi Sun",
company: "Ant Group Co., Ltd.",
companyURL: "https://www.antgroup.com/"
},
{
name: "Shengyi Zhang",
company: "Beijing Esandinfo Ltd.",
companyURL: "https://www.esandinfo.com/"
}
],
group: "cg/agentprotocol",
github:"w3c-cg/ai-agent-protocol"
};
</script>
<style>
table {
border-collapse: collapse;
width: 100%;
table, th, td {
border: 1px solid black;
}
</style>
</head>
<body>
<section id="abstract">
<h2>Abstract</h2>
<p class="ednote">另见该文档的<a href="https://w3c-cg.github.io/ai-agent-protocol/index_cn.html">中文版本</a>。</p>
<p>This paper explores the evolution from the vision of the Semantic Web to the emerging Agentic Web, and analyzes the necessity of establishing standardized agent network protocols. Despite the forward-thinking concept of the Semantic Web proposed twenty years ago, it was not fully realized due to the limitations of artificial intelligence capabilities at that time. With the rapid development of modern AI technologies such as Large Language Models (LLMs), agents now possess the ability to autonomously execute tasks, perform complex reasoning, and solve multi-step problems, thus giving rise to the Agentic Web. Through systematic analysis, this paper identifies four core trends of the agent network: agents replacing traditional software as internet infrastructure, universal interconnection between agents, protocol-based native connection patterns, and agents' autonomous organization and collaboration capabilities. Meanwhile, the research reveals three major challenges that the current internet architecture poses to the development of the Agentic Web: data silos limiting the quality of agent decision-making, human-machine interfaces hindering agent interaction efficiency, and the absence of standard protocols impeding agent collaboration. In response to these challenges, this paper elaborates on the design principles and core requirements for agent network protocols, and provides a systematic comparison and analysis of current major agent network protocol initiatives (MCP, A2A, ACP, ANP, etc.). The conclusion emphasizes that establishing standardized agent network protocols is crucial for breaking down data silos, enabling heterogeneous agent collaboration, building AI-native data networks, and ultimately realizing an open and efficient Agentic Web, while calling on all stakeholders to actively participate in W3C's standardization process.</p>
</section>
<section id="sotd"></section>
<section id="introduction">
<h2>Introduction: From the Unfulfilled Vision of the Semantic Web to the Dawn of the Agentic Web</h2>
<p>Twenty years ago, Tim Berners-Lee and his collaborators visionary proposed the concept of the Semantic Web, with the core objective of creating a data-centric, machine-readable web of data, enabling computers and humans to collaborate more efficiently. This concept depicted an intelligent future: daily transactions, administrative affairs, and various life scenarios would be automatically completed by "intelligent agents" through machine-to-machine dialogues. To achieve this goal, the Semantic Web planned to give clear semantic definitions to information on the web through technologies such as XML, RDF, and Ontology, enabling software agents to autonomously navigate between web pages and efficiently execute complex tasks on behalf of users.</p>
<p class="ednote">TODO: This section needs further development and refinement.</p>
<p>Notably, the original concept of the Semantic Web already included rich "agent" ideas. These agents were envisioned as entities that could automatically execute tasks on behalf of users. The technological breakthroughs represented by Large Language Models (LLMs) have enabled agents to act autonomously, perform complex reasoning, and solve multi-step problems. These agents are no longer just passive tools, but have become active participants in the digital ecosystem. Against this background, the concept of the "Agentic Web" or "Internet of Agents" has emerged. This new network paradigm views agents as primary actors, actively interacting with network resources, services, and other agents to collectively accomplish user goals. The Agentic Web inherits the core vision of the Semantic Web and, leveraging advanced AI capabilities, is committed to building an ecosystem composed of autonomous, intelligent, and efficiently collaborative agents, gradually making the Semantic Web's ideal of machine intelligence efficiently processing information and effectively assisting humans a reality.</p>
<p>This transformation heralds a fundamental change in user interaction patterns—from human-centered clicking and browsing through browsers to agent-centered interactions and collaborations driven by agents. In this new model, agents would autonomously interact directly with other agents, automatically complete tasks, and provide personalized experiences based on user preferences and context. This agent-dominated model is not just an incremental update to the existing network, but may trigger profound changes in internet architecture and interaction logic. The way users access information would also change, from actively querying information through interfaces to agents actively executing tasks and delivering results, possibly bypassing traditional website interfaces. This would promote a comprehensive innovation in the design methods, discovery mechanisms, and interaction modes of network services, pushing the internet into a new stage of development.</p>
</section>
<section id="trends">
<h2>Potential Trends of the Agentic Web</h2>
<p>Just as the vision of the Semantic Web once opened up new possibilities for internet development, today, the Agent-centric Agentic Web may be leading the internet toward a new era full of opportunities and transformations. This
shift not only suggests technological advancement but also could represent a profound revolution in the underlying architecture of the internet and user interaction logic. This agent-driven paradigm shift is potentially manifested in the following four key trends.</p>
<section>
<h3>Agents May Drive the Comprehensive Upgrade of Traditional Software</h3>
<p>With the continuous evolution of agent technology, we may be standing at a turning point for the upgrade of traditional software systems. Agents have the potential to become important infrastructure for the next generation of the internet and may reshape how people interact with the digital world. At the individual level, personal agents could become the main entry points for users to access the internet, and most existing websites and apps might gradually become agent-enabled, delivering corresponding functions and services through agent-to-agent interactions. Compared to interface-based applications that rely on manual operations, agents may demonstrate significant advantages in information integration, intent recognition, decision support, and multimodal scenario interaction, possibly bringing users order-of-magnitude improvements in user experience.</p>
<p>At the enterprise level, companies could deploy enterprise agents to improve internal business process automation and provide more intelligent and personalized user experiences and services externally.</p>
<p>Meanwhile, personal agents might connect directly with enterprise agents to achieve more precise, efficient, and secure service experiences. This new connection paradigm characterized by point-to-point, direct connections between personal agents and enterprise agents is beginning to take shape, suggesting that a more flexible, intelligent, and decentralized internet architecture could be on the horizon.</p>
</section>
<section>
<h3>Agents Would Achieve Universal Interconnection</h3>
<p>In the landscape of the Agentic Web, agents are no longer isolated operating units but may form a highly interconnected, collaboratively evolving network system. Enabling free connections between any agents could fundamentally break the structural limitations of "platform fragmentation" and "data silos" in the current internet, allowing information to flow freely between different domains and systems. This interconnection not only means data interoperability but also could represent agents' ability to dynamically acquire and combine cross-platform, cross-scenario contextual information, thereby demonstrating stronger comprehensive perception and reasoning capabilities when serving individual users or organizational decision-making. At the same time, open connection mechanisms may enable agents to call upon network-wide tools and capability resources as needed, building more complex and deeper collaboration chains. Driven by this trend, interactions between agents might gradually replace human-centered interaction methods, becoming the most core and primary form of connection in the future internet.</p>
</section>
<section>
<h3>Agents May Use Native Protocols for Connection and Interaction</h3>
<p>Currently, AI's interaction with the internet primarily relies on human-centered interface methods, such as Computer Use and Browser Use. While these interaction paths provide AI with preliminary access capabilities, they are essentially designed for human users and may struggle to fully leverage AI's capabilities in information parsing, semantic processing, and automated execution. In fact, AI excels at handling structured data, semantically annotated information, and explicit function calls, rather than complex and variable webpage HTML or frontend interfaces. Therefore, the future Agentic Web may require the development of a network protocol system natively designed for AI, allowing agents to interact directly in a machine-readable, semantically clear manner. Such protocols could play a role similar to HTTP in the human internet, becoming the foundational communication standard supporting the agent network. Based on this protocol system, an entirely new data network specifically designed for AI, more accessible and operable by agents, would also emerge.</p>
</section>
<section>
<h3>Agents Could Self-Organize and Collaborate</h3>
<p>Another key trend in the evolution of the Agentic Web is that agents might possess broader capabilities for autonomous organization and collaboration. We believe that with the support of standardized protocols, agents could dynamically negotiate through natural language, quickly identify each other's capabilities, intentions, and needs, and autonomously form collaborative relationships and complete task divisions without preset interfaces. This flexible, highly adaptive interaction mode may help break through the limitations of traditional systems that rely on static interfaces and manual orchestration, significantly improving network operational efficiency and task response speed while greatly reducing human intervention and integration costs. As collaborative mechanisms continue to evolve, an Agentic Web ecosystem that is self-driven, highly composable, and capable of rapid response may gradually take shape, providing a solid foundation for complex task processing and multi-agent system operations.</p>
</section>
<p>In summary, the rise of the Agentic Web not only suggests that agents could play a greater role in various applications but also indicates a possible reshaping of internet infrastructure and interaction paradigms. To move in this evolutionary direction, there is an urgent need to build a new protocol system for agent networks, thereby providing the necessary infrastructure and standard support for agents to fully unleash their capabilities.</p>
</section>
<section id="challenges">
<h2>Challenges of the Agentic Web: Limitations of the Current Internet and the Urgent Need for Standardized Interaction</h2>
<p>With the development of AI technology, agents are gradually becoming the new generation of core participants in the internet ecosystem, following websites and applications. However, the accelerated evolution of the Agentic Web also exposes many limitations in the technical foundation and connection paradigms of the current internet. If these issues are not addressed, they would severely constrain the scalability and collaborative efficiency of agent systems. The main challenges include the following three aspects:</p>
<ul>
<li><strong>Lack of Standard Protocols Impeding Agent Collaboration</strong>: Agents lack unified communication languages and collaboration norms. While natural language provides a means of communication, it is insufficient to support large-scale, reliable, automated agent collaboration. Establishing standardized protocols is key to networking agents and leveraging collective intelligence.</li>
<li><strong>Human-Machine Interfaces Hindering Agent Interaction Efficiency</strong>: Most existing network services are designed for humans through graphical user interfaces (GUIs). Agents need to simulate human operations to use these services, making the process complex, inefficient, and error-prone. There is an urgent need to provide native, machine-readable interface protocols for agents to enable direct and efficient automated interactions.</li>
<li><strong>Data Silos Limiting Agent Decision Quality</strong>: Agents need to integrate extensive information to make high-quality decisions. Without standard protocols, agents face difficulties in identity authentication and communication with each other, and the existing "data silos" on the current internet would remain difficult to break. This prevents agents from obtaining complete contextual information, severely constraining their analytical, reasoning, and decision-making capabilities.</li>
</ul>
<p>These challenges, especially the lack of standardized agent network protocols, would lead to fragmentation of the agent ecosystem in the future. Numerous heterogeneous agents would become "agent islands," making it difficult to interoperate and collaborate effectively, not only limiting the overall potential of the Agentic Web but also significantly increasing integration costs and complexity .</p>
<p>Faced with this situation, establishing standardized agent network protocols has become an urgent priority for building a truly Agentic Web. Such protocols aim to provide a unified framework for discovery, identification, verification, communication, and collaboration among agents from different platforms and vendors, thereby overcoming interoperability barriers and ensuring secure and efficient interactions. The establishment of the W3C AI Agent Protocol Community Group and its mission is an active response to this need. Standardization is not only a technical requirement but also a strategic cornerstone to prevent the Agentic Web from becoming balkanized and to fully leverage its network effects and realize the vision of "billions of agents" working collaboratively.</p>
</section>
<section id="blueprint">
<h2>Defining the Blueprint: Key Issues and Core Requirements for Agent Network Protocols</h2>
<p>To address the challenges presented in Chapter 3 and fully leverage the potential of the Agentic Web, designing and implementing standardized agent network protocols is crucial. These protocols are not just technical specifications but cornerstones for building an interoperable, trustworthy, and efficient agent ecosystem. A comprehensive agent network protocol framework needs to address a series of key issues and meet specific functional and non-functional requirements.</p>
<section>
<h3>Key Issues That Agent Network Protocols Aim to Solve</h3>
<ul>
<li><strong>Interconnection and Breaking Down Data Silos</strong>: Protocols need to provide mechanisms for agents created by different platforms and developers to discover, verify, connect, and communicate with each other, thereby breaking down the data silos prevalent in the current internet. This requires protocols to support cross-domain communication and promote the free flow of information, ensuring that agents can access complete contextual information needed for high-quality decision-making.</li>
<li><strong>Collaboration Between Heterogeneous Agents</strong>: The Agentic Web would consist of a large number of heterogeneous agents with different architectures, capabilities, and goals. Protocols must be able to address communication and collaboration issues between these heterogeneous agents, for example, through standardized message formats, interaction patterns, and capability description mechanisms, enabling them to understand each other and work together.</li>
<li><strong>Compatibility and Standard Reuse</strong>: To promote widespread adoption and integration, agent network protocols should be compatible with and reuse existing mature Web standards and technologies (such as HTTP, WebRTC, OpenAPI, WoT, etc.) whenever possible. This not only reduces development and deployment barriers but also helps fully leverage the stability and security of existing network infrastructure.</li>
<li><strong>Building Trust and Reducing Collaboration Costs</strong>: In the open Agentic Web, trust between agents is a core issue. Protocols should include mechanisms for establishing and verifying agent identity, reputation, and capabilities to reduce the risks and costs of collaboration between unknown agents and promote trustworthy interactions.</li>
<li><strong>Efficient Collaboration and Privacy-Preserving Interaction Models</strong>: Protocols need to define information interaction patterns between agents that ensure both collaboration efficiency and user privacy and data security. This would involve trustworthy verification of agent identities, encrypting communication content, supporting selective information sharing, and defining access control mechanisms of different granularities.</li>
</ul>
</section>
<section>
<h3>Core Functional Requirements for Agent Network Protocols</h3>
<p>A comprehensive agent network protocol should meet the following core functional requirements to support the effective operation of agents in the Agentic Web:</p>
<ul>
<li><strong>Agent Identity</strong>: Build unified identity representation and verification mechanisms that enable agents to make trusted identity claims and authentication across different platforms, services, and domains, thereby achieving interoperability and trust transfer in cross-platform environments.</li>
<li><strong>Agent Description</strong>: Establish standardized agent description models for expressing agent information, functions, interfaces, and service scope, allowing other agents to accurately understand their capability boundaries based on unified semantics, and enabling automatic parsing and invocation.</li>
<li><strong>Agent Discovery</strong>: Support agents in dynamically searching for and locating other suitable agents in the network based on semantic matching, task requirements, or capability characteristics, thereby building a distributed agent network for on-demand collaboration.</li>
<li><strong>Agent Data Exchange</strong>: Formulate unified data formats and interaction processes for reliable transmission of information, instructions, and context between agents, ensuring semantic consistency, structural standardization, and collaborative effectiveness in cross-agent communication.</li>
<li><strong>Agent Capability Invocation</strong>: Based on identity, description, and discovery mechanisms, establish a universal invocation mechanism that supports one agent calling the services or interfaces exposed by another agent, enabling task delegation, process orchestration, and cross-agent collaborative operations. The invocation process needs to cover a complete loop including interface discovery, parameter passing, permission verification, and execution feedback, ensuring the accuracy, security, and auditability of the invocation.</li>
</ul>
<section>
<h4>Design Principles for Agent Identity Mechanisms</h4>
<p>As discussed in Chapter 3 of this paper, the "data silo" phenomenon in the current internet severely constrains the decision quality and collaboration efficiency of agents. Without standardized identity authentication mechanisms, agents cannot establish trusted connections, and cross-platform information flow and collaboration become impossible. Therefore, the design of agent identity mechanisms is not only a technical requirement but also a key foundation for realizing the vision of "universal interconnection between agents" described in Chapter 2. To this end, the design of agent identity mechanisms should follow these core principles:</p>
<p><strong>Layered Design of Authentication and Authorization</strong>: Agent identity mechanisms should first focus on addressing the fundamental problem of "authentication"—that is, reliably confirming the identity of agents through cryptographic means. Cryptographic identity based on public-private key systems is the foundation of the entire trust chain and the starting point for all subsequent interactions and authorizations. On the basis of reliable authentication, higher-level requirements such as authorization and permission management can be flexibly extended through various mechanisms, such as access tokens for session-level authorization, or Verifiable Credentials (VCs) for fine-grained attribute proofs and permission claims. It must be emphasized that regardless of the authorization mechanism adopted, the cryptographic identity holder is always the subject of authorization—the issuance and authorization of tokens must be traceable to the original cryptographic identity, ensuring the integrity and verifiability of the authorization chain. This layered design gives the identity mechanism good extensibility—core identity verification remains simple and reliable, while authorization strategies can be customized according to specific application scenarios.</p>
<p><strong>Federated Identity Architecture</strong>: A viable agent identity scheme should draw on the successful experience of email systems—each platform can manage its own account system in a centralized manner, while achieving cross-platform interconnection through standard protocols. The core of this federated architecture lies in adopting a Web DID-like approach: each platform internally manages agent accounts and keys in a centralized manner, but externally publishes distributed identity documents through web hosting in a unified manner, enabling external agents to obtain trusted identity verification evidence through standardized resolution processes. Just as email systems allow Gmail users to send emails to Outlook users, agent identity mechanisms should support mutual identification and authentication between agents on different platforms. This design means that existing centralized identifier systems do not need to be completely restructured—simply adding standardized identity document hosting and publishing mechanisms on top of existing systems enables cross-system interoperability. This design significantly lowers the threshold for technical implementation, helps promote wide adoption of agent network protocols, and prevents the Agentic Web from falling into the "fragmentation" trap warned about in Chapter 3 of this paper.</p>
<p><strong>Efficient Cross-Platform Authentication Process</strong>: In cross-platform interaction scenarios between agents, identity authentication mechanisms should minimize interaction rounds to reduce collaboration costs and improve efficiency. Ideally, agents should be able to complete verification by carrying identity identifiers and digital signatures in their first request, without requiring additional handshakes or multiple confirmation rounds. After successful verification, the server can return an access token, and subsequent interactions only need to verify the token, avoiding repeated identity verification overhead. This "verify-on-first-request" design pattern is crucial for achieving the "efficient collaboration" goal stated in Section 4.1 of this paper, especially in scenarios where agents need to frequently interact with multiple servers, significantly reducing latency and improving overall collaboration efficiency.</p>
<p><strong>Mutual Authentication</strong>: In agent interaction scenarios, in addition to server-side verification of client identity, clients may also need to verify the identity of server-side agents. Although the HTTPS protocol already provides domain-name-based server identity verification through TLS certificates, DID-based mutual authentication mechanisms can provide additional value: on one hand, DID authentication can be precise to specific agent entities, rather than just verifying domain ownership; on the other hand, this mechanism allows clients and servers to use consistent, decentralized identity verification methods that do not rely on traditional CA systems. In implementation, the server can return its DID identifier and corresponding signature in the response, and the client can use this to verify the true identity of the server-side agent. It should be noted that DID-level mutual authentication and transport layer security (TLS) are complementary rather than substitutes—the former provides decentralized fine-grained identity assurance at the application layer, while the latter provides communication security and basic domain name identity verification at the transport layer.</p>
<p><strong>Tiered Authorization Mechanism</strong>: As stated in Section 4.3 of this paper, agent network protocols should support "human-in-the-loop" observability requirements. Identity and authorization mechanisms should be able to distinguish between automatic agent authorization and human manual authorization scenarios. For routine, low-risk operations (such as querying public information, accessing already authorized services), agents can automatically complete authorization on behalf of users; while for requests involving important resources or sensitive operations (such as payments, signing agreements, accessing private data), human confirmation processes should be supported. This tiered mechanism ensures that humans retain ultimate control over critical decisions, achieving a balance between agent automation and user security, and is an important safeguard for building a trustworthy Agentic Web.</p>
<p><strong>Privacy-Preserving Design</strong>: As emphasized in Section 4.3 of this paper, protocol design should embed privacy protection mechanisms to avoid unnecessary data exposure. At the identity level, this means supporting a "multi-identity strategy"—that is, a user or agent can have multiple independent identity identifiers for different scenarios (such as maintaining social relationships, daily shopping, service subscriptions, etc.), with each identity isolated from the others to prevent third parties from tracking users' complete behavioral trajectories through identity correlation. Additionally, identity identifiers should support periodic replacement or temporary identity generation to further enhance privacy protection capabilities. This design enables users to maintain control over their personal data while enjoying the convenience of agent networks, complies with relevant privacy regulations, and is a necessary condition for realizing the "open network" vision described in Chapter 7 of this paper—a truly open network should give users the power of choice, rather than trading privacy for interconnection.</p>
</section>
<section>
<h4>DID-Based Identity: A Reference Implementation Approach</h4>
<p>The design principles outlined above establish the requirements for agent identity mechanisms. This section presents Decentralized Identifiers (DIDs), specifically the Web-Based Agent DID method (did:wba), as a reference implementation approach that addresses these requirements while overcoming limitations of traditional authentication schemes.</p>
<section>
<h5>Why Traditional Approaches Fall Short for Agent Networks</h5>
<p>Agent networks present a unique challenge: agents from different platforms must establish trust <strong>dynamically</strong>, often without any pre-existing relationship. Traditional authentication approaches were not designed for this scenario:</p>
<p><strong>OAuth Limitations</strong>: OAuth 2.0 assumes the existence of a trusted authorization server that both parties recognize. In multi-platform agent scenarios, this creates significant challenges:</p>
<ul>
<li>For Platform X's agent to access Platform Y's agent, either Platform Y must pre-register Platform X as a trusted OAuth client, or both must trust a common identity provider.</li>
<li>For N platforms to interoperate freely, this requires either O(N²) bilateral trust agreements or dependence on a dominant centralized identity provider—neither of which scales well or preserves decentralization.</li>
<li>New platforms face a "cold start" problem: they cannot participate until they establish OAuth relationships with existing platforms.</li>
</ul>
<p><strong>Traditional PKI Limitations</strong>: While PKI provides strong cryptographic guarantees, it has limitations for agent identity:</p>
<ul>
<li>TLS certificates verify <strong>domain ownership</strong>, not individual agent identity. Multiple agents on the same domain share a single certificate.</li>
<li>PKI is designed for transport-layer security, not application-layer identity verification between peer agents.</li>
<li>Cross-domain certificate verification relies on centralized Certificate Authority (CA) trust chains.</li>
<li>Certificate management overhead is high for dynamic ecosystems where agents are frequently created and retired.</li>
</ul>
</section>
<section>
<h5>How DID Addresses These Gaps</h5>
<p>W3C Decentralized Identifiers (DIDs) [[DID-CORE]] provide a foundation for agent identity that addresses the limitations above:</p>
<ul>
<li><strong>Self-Sovereign Identity</strong>: Each agent has its own cryptographic identity (public-private key pair) that it controls, independent of any central authority.</li>
<li><strong>Self-Hosted Identity Documents</strong>: DID documents containing public keys are hosted on the agent's own domain, eliminating dependence on third-party identity providers.</li>
<li><strong>Direct Verification</strong>: Any agent can verify another agent's identity by fetching its DID document and verifying cryptographic signatures—no pre-established relationship required.</li>
<li><strong>Federated Architecture</strong>: Like email, each platform manages its own accounts centrally while achieving cross-platform interoperability through standard protocols.</li>
</ul>
</section>
<section>
<h5>The Web-Based Agent DID Method (did:wba)</h5>
<p>The did:wba method extends the did:web specification specifically for agent communication scenarios. It inherits the simplicity of web-based DIDs while adding cross-platform authentication processes optimized for agent interactions.</p>
<p><strong>Key Characteristics</strong>:</p>
<ul>
<li><strong>No Blockchain Required</strong>: Unlike did:btc, did:ethr, or did:ion, did:wba uses standard web infrastructure (DNS, HTTPS, web servers). This eliminates blockchain scalability concerns and reduces deployment complexity.</li>
<li><strong>Familiar URL-Based Resolution</strong>: A DID like <code>did:wba:example.com:user:alice</code> resolves to <code>https://example.com/user/alice/did.json</code>—a simple JSON document hosted on a standard web server.</li>
<li><strong>Single-Request Authentication</strong>: Agents include their DID and a cryptographic signature in the first HTTP request. The server fetches the DID document, verifies the signature, and returns an access token—all in a single round-trip.</li>
<li><strong>Tiered Authorization Support</strong>: DID documents can include separate verification methods for routine agent operations versus sensitive operations requiring human authorization (humanAuthorization), supporting the tiered authorization principle described earlier.</li>
</ul>
<p><strong>Authentication Flow</strong>:</p>
<ol>
<li>Client agent includes its DID and signature in the HTTP Authorization header of the first request.</li>
<li>Server fetches the client's DID document from the client's domain (e.g., <code>https://client-domain.com/agent/did.json</code>).</li>
<li>Server verifies the signature using the public key from the DID document.</li>
<li>Upon successful verification, server returns an access token for subsequent requests.</li>
<li>Result: Cross-platform authentication completed in a single round-trip, with no pre-registration required.</li>
</ol>
<figure>
<img src="anp-did/images/cross-platform-authentication.png" alt="Cross-platform authentication flow using DID" style="max-width: 80%; height: auto;">
<figcaption>Figure 1: Cross-platform authentication flow showing how agents use DID for single-request authentication without pre-registration</figcaption>
</figure>
</section>
<section>
<h5>Practical Scenario: Multi-Platform Agent Collaboration</h5>
<p>Consider a travel booking scenario where a user's personal agent (Platform A) needs to coordinate with multiple service agents:</p>
<ul>
<li>Query hotel availability from a hotel agent (Platform B)</li>
<li>Book flights through an airline agent (Platform C)</li>
<li>Arrange car rental via a rental agency agent (Platform D)</li>
</ul>
<p><strong>With OAuth</strong>: Platform A would need to be pre-registered as an OAuth client with Platforms B, C, and D—or all platforms would need to trust a common identity provider (creating centralization). Adding a new travel service platform would require establishing new OAuth relationships before any collaboration could occur.</p>
<p><strong>With DID</strong>: Each agent simply hosts a DID document on its domain. Platform A's agent can immediately verify and interact with agents on Platforms B, C, and D by fetching their DID documents and verifying signatures. New platforms can join the ecosystem simply by hosting DID documents—no bilateral agreements or central coordination required. This enables the "universal interconnection between agents" vision described in Chapter 2.</p>
<figure>
<img src="images/anp-information-interact.png" alt="Multi-platform agent information interaction" style="max-width: 80%; height: auto;">
<figcaption>Figure 2: Information interaction between agents across multiple platforms, demonstrating decentralized collaboration without pre-established trust relationships</figcaption>
</figure>
</section>
<section>
<h5>Addressing Adoption Concerns</h5>
<p>A common concern is that DID introduces unfamiliar concepts and learning overhead. However, did:wba is designed to minimize this barrier:</p>
<p><strong>Conceptual Simplicity</strong>: At its core, a DID is simply "domain + path + public key." The format mirrors familiar patterns:</p>
<ul>
<li>Email: <code>alice@example.com</code></li>
<li>DID: <code>did:wba:example.com:user:alice</code></li>
</ul>
<p><strong>Incremental Adoption</strong>: Existing systems do not require restructuring. Organizations can add DID document hosting alongside their existing authentication mechanisms, enabling gradual migration. The DID document is simply a JSON file served over HTTPS—no special infrastructure required.</p>
<p><strong>Familiar Building Blocks</strong>: did:wba uses technologies web developers already know: HTTP, JSON, public-key cryptography, and DNS. The authentication flow resembles API key authentication, with the added benefit of cryptographic verification.</p>
<p><strong>Tooling Availability</strong>: Reference implementations and libraries are available for common programming languages, reducing implementation effort.</p>
</section>
</section>
</section>
<section>
<h3>Key Non-Functional Requirements for Agent Network Protocols</h3>
<p>In addition to core functionalities, agent network protocols must also meet a series of key non-functional requirements to ensure their security, usability, scalability, and controllability in real-world applications:</p>
<ul>
<li><strong>Security</strong>: Provide complete mechanisms for identity authentication, access control, data integrity verification, and communication encryption, with capabilities to protect against common attacks (such as forgery, tampering, replay, etc.), ensuring secure and trustworthy interactions between agents.</li>
<li><strong>Privacy</strong>: Protocol design should embed privacy protection mechanisms, avoid unnecessary data exposure and sharing, support minimizing the transmission of personal information during agent interactions, and comply with relevant legal requirements and regulations.</li>
<li><strong>Scalability</strong>: Protocol design should possess good scaling capabilities to handle increasing numbers of agents and interactions without significant performance degradation.</li>
<li><strong>Flexibility</strong>: Protocol design should have good evolutionary capabilities, able to flexibly adapt to future AI capability evolution, emergence of new agent roles, and constantly changing interaction patterns.</li>
<li><strong>Compatibility</strong>: Ensure compatibility with existing Web protocols and standards where appropriate, and enable agents from different developers/platforms to work together collaboratively.</li>
<li><strong>Auditability</strong>: Support comprehensive recording, tracing, and review of agent behaviors and interaction processes, ensuring verification, analysis, and accountability determination in case of disputes or abnormal behaviors.</li>
<li><strong>Observability</strong>: Support human-in-the-loop scenarios, enabling monitoring and control of agent behaviors.</li>
</ul>
</section>
<p>By addressing the key issues above and meeting these core requirements, standardized agent network protocols would lay a solid foundation for building a prosperous, collaborative, and trustworthy Agentic Web.</p>
</section>
<section id="protocol-overview">
<h2>Overview of Typical Agent Protocols</h2>
<p>This section aims to provide a neutral overview of some current and emerging agent protocols, highlighting how they address the challenges and requirements discussed earlier. These protocols each target different aspects of interoperability and deployment scenarios, collectively forming the exploratory frontier of current agent communication standardization.</p>
<section>
<h3>Model Context Protocol (MCP)</h3>
<ul>
<li><strong>Description</strong>: MCP is a widely adopted open specification initiated by Anthropic and now open-sourced, aimed at specifying how applications provide context to large language models (LLMs). It is metaphorically described as the "USB-C port for AI applications," targeting the M×N integration challenge faced when AI models connect with external data sources, tools, and systems (such as cloud platforms, enterprise databases, local files). By providing a unified interface, MCP simplifies interactions between AI models and the external world, reducing the need to build custom connectors for each new data source or tool [[ref11]].</li>
<li><strong>Key Features/Mechanisms</strong>: MCP adopts a client-server architecture where AI applications (such as chat assistants, AI-driven IDEs) act as MCP clients, connecting to one or more MCP servers that expose capabilities or data . Its core interaction primitives include: Tools (executable functions that can be dynamically invoked, such as API calls), Resources (structured static data streams for AI reference), and Prompts (reusable conversation workflows or templates). The protocol layer handles message framing, request/response mapping, and notification delivery, supporting various transport protocols such as Stdio for local processes and HTTP+SSE for network services.</li>
<li><strong>Focus Areas/Target Challenges</strong>: MCP's core goals are to provide structured context injection for LLMs, enable flexible plugging of tools and knowledge, support secure infrastructure integration, and ensure compatibility across different LLM vendors. It aims to enhance AI models' context awareness and dynamic tool discovery and execution capabilities.</li>
<li><strong>Core Technologies Used</strong>: JSON-RPC (for client-server interface), HTTP, Server-Sent Events (SSE).</li>
</ul>
</section>
<section>
<h3>Agent-to-Agent Protocol (A2A) </h3>
<ul>
<li><strong>Description</strong>: A2A is an open protocol initiated by Google and jointly promoted with over 50 industry partners, designed to enable independent AI agents built on different frameworks by different vendors to communicate, collaborate, and coordinate actions securely and seamlessly. It aims to address interoperability issues in heterogeneous agent ecosystems, allowing agents to work together without exposing their internal states, memories, or tools [[ref8]] [[ref9]].</li>
<li><strong>Key Features/Mechanisms</strong>: A2A's core architecture revolves around client agents and remote agents. Agents publish their identities, capabilities, skills, service endpoints, and authentication requirements through "Agent Cards" (JSON metadata documents), enabling capability discovery. The protocol supports task management lifecycle, allowing creation, sending, and tracking of task status, and can handle long-running tasks that might take hours or even days. A2A supports multiple interaction modalities, including text, files, structured JSON data, as well as audio and video streams.</li>
<li><strong>Focus Areas/Target Challenges</strong>: A2A focuses on enabling dynamic interaction, capability sharing, and task coordination between opaque, autonomous agents, especially in enterprise-grade workflows. It aims to break down agent silos, simplify enterprise integration, and foster a more interconnected, powerful AI ecosystem. A2A addresses different problems than MCP, with MCP focusing on connecting agents with tools/data, while A2A focuses on collaboration between agents.</li>
<li><strong>Core Technologies Used</strong>: HTTP(S) (as the transport layer, requiring TLS encryption), JSON-RPC 2.0 (as the payload format for requests and responses), Server-Sent Events (SSE) (for real-time streaming communication from server to client, such as task status updates).</li>
</ul>
</section>
<section>
<h3>Agent Network Protocol (ANP)</h3>
<ul>
<li><strong>Description</strong>: ANP is an open-source protocol with the vision of becoming "the HTTP of the Agentic Web era," designed to build an open, secure, and efficient collaborative network for billions of agents. It aims to address the inadequacies of current internet infrastructure in meeting the specific needs of agent networks. ANP is developed and maintained by the open-source community, which is committed to an open, neutral stance, and the community pledges never to commercialize [[ref6]] [[ref7]].</li>
<li><strong>Key Features/Mechanisms</strong>: ANP primarily addresses the connection and collaboration of agents on the internet, adopting a three-layer architecture:
<ol>
<li><strong>Identity and Encrypted Communication Layer</strong>: Builds decentralized authentication schemes and end-to-end encrypted communication based on W3C DID (Decentralized Identifier) specifications, enabling cross-platform agents to authenticate each other without relying on centralized systems.</li>
<li><strong>Meta-Protocol Layer</strong>: A protocol for negotiating communication protocols between agents, key to enabling self-organization and self-negotiation for efficient collaboration in agent networks.</li>
<li><strong>Application Protocol Layer</strong>: Based on Semantic Web specifications, using JSON-LD and schema.org to describe agent information, capabilities, and interfaces. The entry point for an agent is an Agent Description Document. Uses RFC 8615 to design agent discovery mechanisms, W3C VC to implement credential records for transactions between agents, while reusing many existing specifications such as OpenAPI, WebRTC, etc.</li>
</ol>
<figure>
<img src="anp-did/images/anp-flow.png" alt="ANP protocol architecture and flow" style="max-width: 80%; height: auto;">
<figcaption>Figure 3: ANP three-layer protocol architecture showing the identity layer, meta-protocol layer, and application protocol layer with their interactions</figcaption>
</figure>
</li>
<li><strong>Focus Areas/Target Challenges</strong>: ANP aims to address three core challenges of the agent internet: achieving interconnection between all agents, breaking data silos, and ensuring AI can access complete contextual information; providing AI-native interfaces for efficient interaction with the digital world through APIs or communication protocols rather than mimicking human operations; and utilizing AI for automatic organization and negotiation between agents to build a more economically efficient collaborative network. It particularly focuses on decentralized discovery and collaboration in open internet environments, as well as interoperability across heterogeneous domains.</li>
<li><strong>Core Technologies Used</strong>: W3C Decentralized Identifiers (DIDs), JSON-LD, W3C Verifiable Credentials (VC), end-to-end encryption technologies.</li>
</ul>
</section>
<section>
<h3>Agent Connect Protocol (ACP) </h3>
<ul>
<li><strong>Description</strong>: ACP is an open-source protocol led by Cisco and developed in collaboration with partners such as LangChain and Galileo as part of the AGNTCY initiative, designed to provide a communication layer for autonomous agents to collaborate and share resources in distributed systems [[ref12]].</li>
<li><strong>Key Features/Mechanisms</strong>: ACP adopts RESTful APIs as the standard interface, defining how agents interact, including retrieving workflows that agents can execute, creating and managing context threads, and running agents. It supports stateful communication threads, allowing agents to negotiate and reason together during tasks, and implements loosely coupled interactions through message passing. Agent discovery is achieved through the Agent Directory and OASF (Open Agentic Schema Framework) documents, which are standardized JSON files describing agent capabilities, invocation methods, input/output patterns, and more. ACP supports asynchronous-first interactions, multi-part messages, and observability features.</li>
<li><strong>Focus Areas/Target Challenges</strong>: ACP primarily addresses communication barriers and collaboration efficiency issues between heterogeneous agents (potentially built on different technology stacks or frameworks) in enterprise environments. It aims to enable scalable, standardized multi-agent interactions, allowing multiple agents to work together as a logical unit to complete complex tasks.</li>
<li><strong>Core Technologies Used</strong>: RESTful APIs, JSON (for OASF documents and message schemas). Can be integrated with workflow frameworks such as LangGraph.</li>
</ul>
</section>
<section>
<h3>Agent Communication Protocol (ACP) </h3>
<ul>
<li><strong>Description</strong>: Agent Communication Protocol (ACP) is an open-source standard contributed by IBM to the Linux Foundation, designed to provide a shared language for heterogeneous AI agents to enable connection, collaboration, and complex task execution. The protocol's primary goal is to eliminate vendor lock-in and promote the development of agent ecosystems through an open governance model [[ref13]].</li>
<li><strong>Key Features/Mechanisms</strong>: ACP defines a standardized RESTful API that supports synchronous, asynchronous, and streaming interactions, adopting a peer-to-peer interaction design. Its core features include:
<ul>
<li><strong>No Specialized SDK Required</strong>: The protocol is designed to enable interaction without specialized SDKs, allowing direct use of standard HTTP tools while also providing Python/TypeScript SDKs.</li>
<li><strong>Offline Discovery</strong>: Enables agent discovery through metadata that can be embedded in distribution packages for offline discovery, using Agent Detail models to describe agents.</li>
<li><strong>Peer-to-Peer Interaction</strong>: Emphasizes peer-to-peer interaction, supporting direct communication and collaboration between agents.</li>
<li><strong>Complementary to MCP</strong>: Forms a complementary relationship with Model Context Protocol (MCP), focusing on inter-agent communication.</li>
</ul>
</li>
<li><strong>Focus Areas/Target Challenges</strong>: ACP primarily addresses interoperability issues between heterogeneous AI agents, enabling cross-framework and cross-technology stack agent collaboration through a shared communication language. The protocol particularly emphasizes avoiding vendor lock-in, using an open-source, Linux Foundation governance model to ensure the openness and neutrality of the standard.</li>
<li><strong>Core Technologies Used</strong>: HTTP, JSON, OpenAPI Specification, Python/TypeScript SDKs. The protocol relies on underlying HTTP(S) and enterprise-grade security practices of the deployment environment, supporting discovery and interaction in secure/air-gapped environments.</li>
</ul>
</section>
<section>
<h3>Protocol Comparison Analysis</h3>
<p>To clearly compare the above major protocols, the following table summarizes some of their key features:</p>
</section>
</section>
<table>
<thead>
<tr>
<th>Feature</th>
<th>Model Context Protocol (MCP)</th>
<th>Agent-to-Agent Protocol (A2A)</th>
<th>Agent Network Protocol (ANP)</th>
<th>Agent Connect Protocol (ACP)</th>
<th>Agent Communication Protocol (ACP)</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Main Supporters/Initiators</strong></td>
<td>Anthropic</td>
<td>Google with 50+ industry partners</td>
<td>ANP open-source community</td>
<td>Cisco (AGNTCY initiative)</td>
<td>IBM (contributed to Linux Foundation)</td>
</tr>
<tr>
<td><strong>Main Goals/Focus Areas</strong></td>
<td>Providing structured external context for LLMs/agents, solving M×N integration problems</td>
<td>Cross-vendor/framework heterogeneous agent interoperability, task collaboration, and dynamic negotiation</td>
<td>Agent connection and collaboration on the internet</td>
<td>Structured, persistent multi-agent collaboration and workflows in enterprise environments</td>
<td>Providing shared language for heterogeneous AI agents to enable connection, collaboration and complex task execution; eliminating vendor lock-in</td>
</tr>
<tr>
<td><strong>Communication Style</strong></td>
<td>Client-server</td>
<td>Client-remote agent (peer-to-peer concept, can have intermediaries), task-oriented</td>
<td>Peer-to-peer protocol architecture</td>
<td>RESTful API, execution-based messaging, supports stateful threads</td>
<td>HTTP-based RESTful API supporting synchronous, asynchronous and streaming interactions; peer-to-peer interaction</td>
</tr>
<tr>
<td><strong>Core Technologies Used</strong></td>
<td>JSON-RPC, HTTP, SSE</td>
<td>HTTP(S), JSON-RPC 2.0, SSE</td>
<td>W3C DIDs, JSON-LD, W3C VC, End-to-End Encryption</td>
<td>RESTful APIs, JSON</td>
<td>HTTP, JSON, OpenAPI Specification, Python/TypeScript SDKs</td>
</tr>
<tr>
<td><strong>Discovery Mechanism</strong></td>
<td>Typically application-integrated or managed by host application</td>
<td>Agent Cards (JSON metadata, typically published at /.well-known/agent.json)</td>
<td>Based on RFC 8615, typically published at /.well-known/agent-descriptions</td>
<td>Agent Directory, Agent Manifests (JSON)</td>
<td>Through metadata (can be embedded in distribution packages for offline discovery), Agent Detail model</td>
</tr>
<tr>
<td><strong>Identity Management Method</strong></td>
<td>OAuth 2.1</td>
<td>Out-of-band authentication schemes</td>
<td>W3C DIDs (Decentralized Identifiers)</td>
<td>Depends on enterprise integration (e.g., OAuth)</td>
<td>Relies on underlying HTTP(S) and enterprise-grade security practices in deployment environment; protocol itself does not strictly specify</td>
</tr>
<tr>
<td><strong>Emphasized Security Features</strong></td>
<td>Secure context acquisition (e.g., via TLS), local-first security</td>
<td>TLS, server authentication, client/user authentication</td>
<td>TLS, end-to-end encryption, DID-based authentication</td>
<td>TLS, enterprise-grade security practices</td>
<td>Relies on HTTPS transport security; supports discovery in secure/air-gapped environments</td>
</tr>
<tr>
<td><strong>State Management</strong></td>
<td>Typically stateless or managed by client/host application, though MCP servers may expose stateful resources</td>
<td>Supports long-running task state tracking (stateful interactions)</td>
<td>Can support stateful interactions (determined by application protocol layer)</td>
<td>Stateful communication threads</td>
<td>Supports stateful interactions (e.g., through Await mechanism)</td>
</tr>
<tr>
<td><strong>Key Differentiators/Unique Aspects</strong></td>
<td>Focuses on the "last mile" connection between models and tools/data, complementary to other protocols</td>
<td>Emphasizes open standards for agent collaboration across different systems and vendors, supports multiple interaction modalities</td>
<td>Designed for agent interaction and collaboration in untrusted internet environments</td>
<td>Deep collaboration in controlled enterprise environments</td>
<td>Open-source, Linux Foundation governance, avoids vendor lock-in; emphasizes peer-to-peer interaction; complementary to MCP; designed to interact without specialized SDKs</td>
</tr>
</tbody>
</table>
<section>
<h2>Building AI-Native Data Networks Based on Agent Network Protocol</h2>
<p>Current internet infrastructure is primarily designed for human interaction through browsers and graphical user interfaces. However, the rise of the Agentic Web requires us to reimagine a network environment more suitable for AI agents' native interactions. This "AI-native data network" would no longer be merely a platform for displaying human information, but an optimized space for agents to efficiently acquire data, invoke services, and collaborate.</p>
<p>The core characteristics of such a network would include:</p>
<ul>
<li><strong>Machine-readable interfaces first</strong>: Services and data sources would expose their functionality and information through standardized, agent-friendly APIs (rather than primarily relying on human user interfaces). This would greatly reduce the complexity and overhead for agents to access and utilize network resources.</li>
<li><strong>Enhanced semantic and structured data</strong>: Data would not only be accessible but also understandable. Drawing on semantic web concepts and combined with modern AI's understanding capabilities, data would be given richer semantic descriptions and structured representations, enabling agents to reason and make decisions more precisely.</li>
<li><strong>Communication protocols optimized for AI</strong>: Beyond general agent network protocols, underlying network communications may also need to be optimized for agent interaction characteristics, such as supporting low-latency, high-throughput multimodal data exchange, and more flexible communication patterns.</li>
<li><strong>Dynamic service discovery and composition</strong>: Agents would be able to dynamically discover needed services and data in this network, and flexibly combine them according to task requirements, achieving complex collaborative task solutions.</li>
</ul>
<p>AI-native data networks would be key infrastructure for the Agentic Web to fully realize its potential, enabling agents to interact with the digital world in their most proficient way (i.e., directly processing information through protocols and APIs), thereby catalyzing higher levels of automation, intelligence, and collaborative efficiency.</p>
</section>
<section>
<h2>Future Outlook: Reshaping the Open Network Through Connection</h2>
<p>The evolution of the internet profoundly confirms a core principle: "Connection is Power." In a truly open, interconnected network, free interaction between nodes can maximize innovation potential and create enormous value. However, today's internet ecosystem is increasingly dominated by a few large platforms, with vast amounts of data and services confined within closed "digital islands," concentrating the power of connection in the hands of a few tech giants.</p>
<p>The advent of the Agentic Web era provides us with a historic opportunity to reshape this imbalanced landscape. Our goal is to drive the internet from its current generally closed, fragmented state back to its open, freely connected origins. In the future Agentic Web, each agent would simultaneously play the dual roles of information consumer and service provider. More importantly, every node should be able to discover, connect, and interact with any other node in the network without barriers. This vision of universal interconnection would greatly reduce the barriers to information flow and collaboration, returning the power of connection truly to each user and individual agent.</p>
<p>This marks an important shift: from platform-centric closed ecosystems to protocol-centric open ecosystems. In the latter, value acquisition depends more on the unique capabilities and contributions that participants bring to the network by following open protocols, rather than relying on control over a closed platform. This shift would stimulate more intense application-layer innovation and competition, as the key to success is no longer "locking in" users, but providing superior agent services, similar to the innovation patterns historically promoted by open protocols like TCP/IP and SMTP.</p>
</section>
<section>
<h2>Building the Future of a Collaborative Agentic Web</h2>
<p>Standardized agent network protocols are crucial for unleashing the potential of the Agentic Web, realizing certain aspects of the original semantic web vision, and fostering innovation. They are the cornerstone for building a network where machines can process information more intelligently and assist humans more effectively.</p>
<p>We urge all stakeholders to actively participate in the standardization process through the W3C. This is an opportunity to shape the future network—one that is more intelligent, collaborative, and empowering, built on foundations of openness and trust. A well-designed Agentic Web has tremendous transformative potential, and now is the critical moment to lay its solid foundation.</p>
</section>
<section>
<h2>Security Considerations</h2>
<p class="ednote">This section is expected to be expanded. And warmly welcome contributions from the security community. We are actively following relevant work within W3C,
including the <a href="https://github.com/w3c-cg/threat-modeling/blob/main/models/ai-in-browser.md">AI in the Browser</a>, which will inform our approach to security considerations.</p>
<p>To be added.</p>
</section>
<section>
<h2>References</h2>
<ol>
<li id="ref1"><a href="https://www.scientificamerican.com/article/the-semantic-web/" target="_blank" rel="noopener">Tim Berners-Lee, James Hendler and Ora Lassila. The Semantic Web. Scientific American, 2001.</a></li>
<li id="ref2"><a href="https://arxiv.org/html/2503.20793v1" target="_blank" rel="noopener">Semantic Web – A Forgotten Wave of Artificial Intelligence?</a></li>
<li id="ref3"><a href="https://arxiv.org/abs/2504.16736" target="_blank" rel="noopener">The Agentic Web: A Paradigm Shift in Web Architecture for an LLM-powered Internet</a></li>
<li id="ref4"><a href="https://arxiv.org/html/2504.21030v1" target="_blank" rel="noopener">LLM Agents Architecture: A Survey</a></li>
<li id="ref5"><a href="https://outshift.cisco.com/blog/building-multi-agent-marketing-campaign-agntcy" target="_blank" rel="noopener">Building Multi-Agent Marketing Campaign with AGNTCY</a></li>
<li id="ref6"><a href="https://github.com/agent-network-protocol/AgentNetworkProtocol/blob/main/01-agentnetworkprotocol-technical-white-paper.md" target="_blank" rel="noopener">Agent Network Protocol Technical White Paper</a></li>
<li id="ref7"><a href="https://github.com/agent-network-protocol/AgentNetworkProtocol" target="_blank" rel="noopener">Github: AgentNetworkProtocol</a></li>
<li id="ref8"><a href="https://google.github.io/A2A/specification/" target="_blank" rel="noopener">Agent-to-Agent (A2A) Protocol Specification</a></li>
<li id="ref9"><a href="https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/" target="_blank" rel="noopener">A2A: A new era of agent interoperability</a></li>
<li id="ref10"><a href="https://outshift.cisco.com/blog/mcp-acp-decoding-language-of-models-and-agents" target="_blank" rel="noopener">MCP & ACP: Decoding the Language of Models and Agents</a></li>
<li id="ref11"><a href="https://modelcontextprotocol.io/specification/2025-03-26" target="_blank" rel="noopener">Model Context Protocol (MCP)</a></li>
<li id="ref12"><a href="https://github.com/agntcy/acp-spec" target="_blank" rel="noopener">Agent Connect Protocol (ACP) Specification - AGNTCY</a></li>
<li id="ref13"><a href="https://agentcommunicationprotocol.dev/introduction/welcome" target="_blank" rel="noopener">Agent Communication Protocol (ACP) - Introduction</a></li>
<li id="ref14"><a href="https://www.w3.org/TR/did-core/" target="_blank" rel="noopener">Decentralized Identifiers (DIDs) v1.0. W3C Recommendation, 19 July 2022.</a></li>
<li id="ref15"><a href="https://w3c-ccg.github.io/did-method-web/" target="_blank" rel="noopener">did:web Method Specification. W3C Credentials Community Group.</a></li>
</ol>
</section>
</body>
</html>