Architecting a Trustless Coordination Network for Independent Economic Agents: Interoperability, Portability, and Adoption Dynamics

Full report

On this page

The deployment of autonomous software agents has accelerated a fragmentation problem across the digital economy. As independent economic agents are developed using disparate frameworks, runtimes, memory architectures, and tooling, integrating these systems to coordinate tasks currently scales at an unsustainable [Figure omitted from source export] complexity1. Every new agent-to-agent connection historically demands bespoke integrations for authentication, transport, schema negotiation, and error handling. For a coordination network to become viable across independently developed entities, it must function as a decentralized overlay. This overlay must act as a common protocol suite that adds counterpart discovery, private communication, and secure work exchange without requiring participants to abandon their existing proprietary stacks3.

Achieving this integration requires a precise combination of cryptographic identity, capability-based delegation, standardized task lifecycles, and tamper-evident audit trails. Voluntary adoption in open networks relies entirely on the premise of portability and the absence of lock-in. Economic agents will only utilize a shared network if they retain sovereign control over their state, identities, and economic relationships5. Systems that enforce a specific cognitive architecture or trap execution histories face insurmountable adoption headwinds. Conversely, networks that guarantee an exit path and allow agents to utilize competing infrastructure providers naturally reduce switching costs, thereby incentivizing widespread, voluntary participation5.

1. An Interoperability Map Across the Agent Lifecycle

A coordination network must formalize the boundaries between independent agents while leaving their internal reasoning loops entirely opaque. The agent lifecycle in a multi-agent network moves through distinct phases of identity provisioning, discovery, negotiation, delegation, execution, and economic settlement. The table below maps these lifecycle stages to the exact interoperability standards required to fulfill them, establishing the foundational architecture of the proposed overlay network.

 

2. Comparison of Relevant Standards and Proprietary Approaches

To construct a robust coordination network, architects must evaluate overlapping and competing standards. Terminology across these specifications is often similar, but the architectural intent, maturity, and adoption evidence differ fundamentally. The analysis below distinguishes between specifications designed for internal agent-to-tool operations and those built for external agent-to-agent delegation.

2.1 Capability Discovery

For agents to transact, they must first discover counterpart capabilities without prior manual integration. The industry currently utilizes two divergent approaches to manifest publication.

Google's Agent2Agent (A2A) protocol relies on a static JSON manifest hosted at a standardized web path, typically /.well-known/agent.json. This Agent Card defines the agent's identity, supported transports (e.g., HTTP, gRPC), required security schemes, and an array of supported skills3. The explicit problem A2A solves is global counterpart discovery. By reading an Agent Card, an unfamiliar client knows exactly how to formulate a request to an opaque receiving agent across the network. A2A reached its v1.0 specification in March 2026 and was subsequently donated to the Agentic AI Foundation (AAIF) under the Linux Foundation4.

Conversely, the Model Context Protocol (MCP) utilizes a dynamic manifest designed to expose specific executable tools, read-only resources, and prompt templates to a local host1. MCP's discovery mechanism relies on the client querying the server via JSON-RPC to list tools. While MCP saw explosive adoption—reaching 97 million monthly SDK downloads and 17,000 public servers by Q1 2026—its discovery model is explicitly designed for an LLM host querying its own configured environment2.

A2A and MCP solve fundamentally different slices of the discovery problem. A2A handles the inter-agent query of "who are you and what autonomous tasks can you accept?" whereas MCP handles the intra-agent query of "what deterministic functions can I execute in this environment?" A coordination network should utilize A2A for inter-agent public discovery, while individual agents use MCP internally to interact with their proprietary toolsets4.

2.2 Authentication and Delegated Authority

Delegating tasks across independent agents introduces the "multi-hop" authorization problem. A human user authorizes Agent A, which delegates a sub-task to Agent B, which subsequently invokes Service C21. The network requires cryptographic proof of this entire chain.

The prevailing industry standard utilizes OAuth 2.1 Token Exchange, formalized in RFC 8693\. Under this specification, Agent A exchanges its initial token for a new token explicitly scoped for Agent B, utilizing sub and act claims to track the delegation23. The critical limitation of RFC 8693 in an autonomous network is centralized coupling. The specification requires agents to contact the Authorization Server (AS) at every single hop22. If the AS is unavailable, or if the agents operate across disparate sovereign trust boundaries, the delegation chain breaks.

Decentralized alternatives seek to eliminate this bottleneck. User Controlled Authorization Networks (UCANs) use nested JSON Web Tokens (JWTs) tied to Decentralized Identifiers (DIDs) to pass capabilities offline25. While highly decentralized, UCANs suffer from quadratic token bloat as the delegation chain grows, and their flat URI scope structure lacks the expressiveness required for complex agent policies9.

Biscuit, combined with Invocation-Bound Capability Tokens (IBCTs), provides a highly mature alternative. Biscuit utilizes Ed25519 public-key signatures and a Datalog policy language to create append-only delegation blocks9. It allows a parent agent to attenuate (restrict) scopes, budgets, and time-to-live (TTL) limits for a sub-agent completely offline. Because verifiers only need the root public key to evaluate the Datalog chain, Biscuit eliminates the latency penalties and centralization bottlenecks of OAuth 2.19.

Concurrently, traditional financial networks have introduced proprietary agent identity solutions. In 2026, Mastercard announced Agent Pay, which issues an Agentic Token via the Mastercard Digital Enablement Service (MDES), binding the cardholder, the registered AI agent, and the scope of the mandate into a single credential28. Visa introduced the Trusted Agent Protocol, which utilizes signed HTTP headers to attest the agent's identity and user consent before routing the authorization28. While effective for fiat settlement, these proprietary models introduce ecosystem lock-in.

For independent economic agents coordinating general computing tasks, offline attenuation is paramount. Biscuit/IBCT provides the most rigorous cryptographic foundation for agentic delegation, supporting expressivity and offline verification without reliance on financial intermediaries or centralized identity providers9.

2.3 Task and Result Representation

Agent reasoning requires varying, non-deterministic amounts of time. Synchronous Remote Procedure Calls (RPCs) inevitably time out or block execution threads when an agent takes hours to evaluate a complex objective.

The A2A specification addresses this by modeling agent interactions around a stateful Task object. Tasks progress through a strictly defined lifecycle: TASK\_STATE\_SUBMITTED, TASK\_STATE\_WORKING, TASK\_STATE\_INPUT\_REQUIRED, TASK\_STATE\_COMPLETED, and TASK\_STATE\_FAILED4. This paradigm allows a client agent to submit a complex prompt and either poll the server periodically or stream the resulting state changes via Server-Sent Events (SSE)4.

To track intermediate milestones without exposing proprietary reasoning, the Durable Activity Record Protocol (DARP) adapts the W3C ActivityStreams 2.0 framework12. DARP emits standardized JSON-LD milestone records, such as task.started, task.progressed, and task.blocked12.

The coordination network must adopt the A2A Task state machine as the primary external contract. DARP should be utilized to map an agent's internal, proprietary step-by-step reasoning into standardized milestones for external observability. This ensures transparency for the client while protecting the server agent's proprietary model weights, internal scratchpads, and raw tool outputs4.

2.4 Structured Messaging and Asynchronous Updates

The transport layer dictates how payloads move between agents. A2A relies heavily on JSON-RPC 2.0 over HTTP, utilizing SSE for unidirectional streaming updates31.

The evolution of the Model Context Protocol provides a critical lesson in transport architecture. In its July 2026 update (specification 2026-07-28), MCP shifted to a completely stateless protocol at the network layer. Specification Enhancement Proposal 2567 (SEP-2567) removed the initialize handshake and the Mcp-Session-Id header33. Consequently, all requests became independently routable, cacheable, and traceable via W3C Trace Context propagation33.

Stateless communication prevents silent state corruption and reduces infrastructure overhead. When agent topologies span independent economic zones, maintaining persistent stateful connections is highly brittle. The proposed coordination network must mandate stateless REST or JSON-RPC over HTTP, utilizing SSE solely for asynchronous push notifications and status streams, eliminating the need for sticky routing and shared session stores32.

2.5 Tool Invocation

The Model Context Protocol has achieved near-universal industry consensus for connecting LLMs to data silos, effectively collapsing the integration math from [Figure omitted from source export] to [Figure omitted from source export]1. An agent only needs one MCP client to speak to thousands of potential MCP servers.

However, exposing tools directly across a public network boundary carries severe security risks. A prominent vulnerability documented extensively in 2026 is "tool metadata poisoning." In this attack vector, malicious instructions are embedded directly within the tool descriptions or schemas provided by the server. When the LLM parses the manifest to understand the tool, the poisoned metadata acts as an indirect prompt injection, hijacking the agent's reasoning loop34. Researchers have demonstrated that an agent can connect to an approved, allowlisted MCP server, yet still be compromised through this "rug pull" technique, as the attack subverts the agent's logic without violating traditional role-based access controls36.

Consequently, while the coordination network governs how agents delegate tasks to each other using A2A, MCP must remain the standard for how agents talk to their own local or heavily vetted enterprise tools. The network architecture must not mandate the exposure of raw MCP endpoints across the public boundary, as doing so extends tool poisoning and prompt injection risks into the untrusted sphere20.

2.6 Identity Portability

Identities must be cryptographically verifiable and entirely portable to prevent vendor lock-in. Several Decentralized Identifier (DID) methods exist, but they offer vastly different operational tradeoffs.

• did:key: Ephemeral and derived directly from a cryptographic keypair. It is fast and supports offline verification, but fundamentally lacks key rotation and revocation capabilities38.
• did:web: Relies on DNS infrastructure. It is highly accessible but ties identity strictly to domain ownership, exposing agents to infrastructure lock-in, centralized control, and DNS hijacking39.
• did:tdw (Trust DID Web): An evolution of did:web incubated by the Decentralized Identity Foundation (DIF). It incorporates a verifiable, append-only JSON Lines history (did.jsonl) of the DID Document40.

For robust agent identity, the network must adopt the W3C Verifiable Credentials Data Model v2.0 (published as a W3C Recommendation in May 2025\) anchored to did:tdw identifiers7. did:tdw represents the optimal balance for independent agents. It allows an agent to host its identity via standard HTTP infrastructure while generating a Self-Certifying Identifier (SCID)40. If the agent migrates to a new host, the cryptographic history migrates with it, ensuring that the identity outlives the domain and completely mitigating vendor capture.

2.7 Transaction Receipts and Audit Records

Accountability in an autonomous network requires durable proofs of execution.

The IETF Supply Chain Integrity, Transparency, and Trust (SCITT) framework provides a standardized architecture for immutable transparency logs14. Under the AI Agent Execution Profile of SCITT, agents generate an AgentInteractionRecord (AIR) formatted as a CBOR Object Signing and Encryption (COSE) payload (specifically COSE\_Sign1)14. This payload is submitted to an independent Evidence Custodian acting as a Transparency Service.

A multi-agent network cannot rely on the localized, mutable logs of individual participants. By enforcing SCITT-compliant COSE receipts for task completions, economic agents can generate irrefutable, cryptographically verifiable proofs of service execution14. These receipts are agnostic to the signature format and form the basis of automated dispute resolution.

2.8 Economic Settlement

Traditional payment models, such as monthly subscriptions and OAuth-gated API keys, fail for autonomous systems. Subscriptions require human-in-the-loop signups, and credit card processing is too slow and expensive for sub-cent API calls17.

The L402 protocol unifies authentication and payment into a single machine-native credential. L402 combines the Lightning Network—capable of instant, high-volume, low-cost microtransactions—with the HTTP 402 "Payment Required" status code16. When an agent requests a paid resource, the server issues a macaroon (a programmable authorization token with embedded caveats) alongside a Lightning invoice. Once the payment settles, the Lightning Network reveals a 32-byte cryptographic preimage. The agent presents this preimage alongside the macaroon to access the service16.

L402 removes the need for accounts, passwords, or human intervention. Verification is a local computation for the server, eliminating external database lookups and making it the ideal, privacy-preserving settlement layer for high-frequency agent commerce17.

3. The Smallest Viable Common Interface (SVCI)

To maximize voluntary adoption across the ecosystem, the cost of joining the network must remain strictly marginal. Adoption should require only a lightweight adapter at the network edge, preserving the agent's internal architecture, memory layout, and preferred Large Language Model2. The Smallest Viable Common Interface (SVCI) consists of four non-negotiable requirements:

1. Identity Anchor: An agent must publish a did:tdw identity document. This establishes a cryptographic presence, enables verifiable history logging, and provides a SCID for ultimate portability40.

2. Discovery Manifest: The agent must host an A2A-compliant Agent Card at /.well-known/agent.json. This JSON document must map to its DID and expose a minimum of one capability (skill), alongside defined routing endpoints and authentication schemes3.

3. Stateless Request Handler: The agent must expose a single HTTP endpoint capable of parsing A2A JSON-RPC 2.0 envelopes (specifically implementing the message/send and tasks/get RPC methods)11.

4. Authorization Validator: The agent must deploy a lightweight middleware capable of verifying Biscuit/IBCT Datalog policies or L402 macaroons9. This ensures the caller has cryptographically proven its delegated authority or has settled economic payment before the agent invokes any internal LLM reasoning.

Everything outside of this SVCI remains entirely at the discretion of the agent owner. The network makes no assumptions about how the agent triggers LLM inference, how it structures its episodic memory, or whether it uses MCP or proprietary libraries to actuate internal tools20.

4. Capability-Negotiation and Version-Discovery Proposal

Introducing new protocol versions in a decentralized network creates the severe risk of trapping legacy participants or silently corrupting semantic state33.

Historically, network design followed Postel's Law (The Robustness Principle): "Be liberal in what you accept, and conservative in what you send." In the context of LLMs and autonomous agents, Postel's Law is fundamentally dangerous and explicitly deprecated48. AI agents attempting a "forgiving interpretation" of malformed JSON-RPC payloads or ambiguous tool schemas will systematically hallucinate missing parameters. This hallucination leads to unpredictable downstream execution and severe security vulnerabilities, including metadata poisoning36.

The Strict Versioning Protocol

The coordination network must definitively invert Postel's Law, enforcing a paradigm of strict validation at the boundary and explicit failure on ambiguity.

1. Header-Based Routing and Versioning: Every A2A JSON-RPC request must carry an A2A-Version header (e.g., A2A-Version: 1.0). If the receiving agent does not support this exact version, it must immediately halt processing and return a VersionNotSupportedError rather than attempting to interpolate or parse the payload11.

2. Schema Enforcement and Semantic Context: Payloads must be subjected to strict JSON Schema validation and JSON-LD context resolution. Any extraneous fields, missing required parameters, or data type mismatches (e.g., supplying a string instead of an integer) must trigger a hard HTTP 400 rejection47.

3. Forward Compatibility via Explicit Extensions: Borrowing from MCP's 2026 extension model, experimental features must be negotiated explicitly. The client includes an A2A-Extensions header (e.g., https://example.com/extensions/v1)11. If the server does not recognize the extension, it must execute the core task strictly without the extension, or reject the task entirely if the client marked the extension as critical.

This explicit strictness guarantees that no agent silently corrupts its state by guessing the intent of an unfamiliar protocol variant, ensuring highly deterministic multi-agent interactions.

5. Integration-Cost Model for an Unfamiliar Agent

The economic logic of joining the network must clearly outweigh the friction of adoption.

In the current point-to-point state, integrating with [Figure omitted from source export] counterparts requires an agent development team to write, test, and maintain [Figure omitted from source export] custom API wrappers. If a counterpart updates its API, the integration breaks. The cost function for integration is [Figure omitted from source export]2. Assuming a standard enterprise software engineering cost of $10,000 per bespoke API integration, connecting with 50 economic counterparts requires a $500,000 capital expenditure, plus significant recurring maintenance overhead.

In the proposed network state, the agent team builds exactly one SVCI adapter. This adapter translates incoming A2A JSON-RPC tasks into the agent's internal job queue and wraps outbound requests in standardized A2A task envelopes. The cost function flattens to [Figure omitted from source export]2.

Implementing the A2A SVCI adapter and generating a did:tdw profile takes an estimated two to four weeks of engineering time for a backend developer (an expenditure of approximately $15,000 to $30,000). Once the agent is compliant with the network boundary, the marginal technical cost to discover, negotiate, and transact with the 50th, 500th, or 5000th agent drops to effectively zero. The network enables instantaneous counterparty discovery via the Agent Card, completely eliminating bilateral integration costs and dramatically accelerating the speed of commerce.

6. Portability Plan for Identities, Task Records, and Receipts

Voluntary adoption is historically driven by the freedom to exit. If the coordination network effectively captures an agent's data or identity, enterprise and independent developers will refuse to deploy high-value workloads. Portability is not merely a technical feature; it is the primary economic driver of trust in decentralized systems.

6.1 Identity Portability

Using did:tdw (Trust DID Web), the agent's identity is anchored to a web domain for discoverability but remains cryptographically self-certifying40. If an agent operating at agent1.vendorA.com wishes to migrate its infrastructure to vendorB.com, the DID Controller generates a new log entry in the did.jsonl file updating the service endpoints. The Self-Certifying Identifier (SCID) remains completely unchanged40. Any counterparty verifying the agent's signature traces the cryptographic history seamlessly to the new host. The identity outlives the infrastructure, granting the agent total sovereignty.

6.2 Task Record and Memory Portability

Task execution histories are highly valuable assets used for fine-tuning future agent models. By utilizing the Durable Activity Record Protocol (DARP), agents emit standardized milestones (task.started, task.completed) in JSON-LD format12. Because DARP separates the activity log from the proprietary platform database, the agent can export a newline-delimited JSON (JSONL) ledger of all historical tasks. This ledger can be ingested directly by any competing framework without data transformation, ensuring that the agent's memory and performance history remain perfectly portable.

6.3 Receipt Portability

Economic transactions require durable, independent proofs. Because the network utilizes SCITT COSE receipts, the cryptographic proof of a transaction is entirely independent of the network's transport layer14. Receipts are stored locally by the agent in an append-only archive. Even if the original transparency log goes offline or a vendor ceases operations, the mathematical proof held by the agent remains valid and verifiable by any third-party auditor in perpetuity. This guarantees that economic settlements cannot be contested due to infrastructure failure.

7. Conformance Scenarios for Future Independent Implementation

To prevent network fragmentation and ensure seamless interoperability, implementations must be tested against a rigorous, deterministic conformance suite. Borrowing from the highly successful modelcontextprotocol/conformance matrix—which requires a 100% pass rate (e.g., 67/67 server tests) for Tier 1 classification—the network will establish an automated testing repository51.

Conformance testing must be completely deterministic, requiring no LLM processing or "AI judgment." The test runner executes specific JSON-RPC interactions directly against an agent's SVCI adapter.

Tier 1 Conformance (Fully Supported) Requirements:

1. Discovery Scenario: The test runner issues an HTTP GET to /.well-known/agent.json. The agent must return a structurally valid Agent Card containing properly typed AgentSkill objects and correct MIME type declarations11.

2. Stateless Capability Scenario: The runner issues an A2A message/send payload containing an unrecognized A2A-Version header. The agent must successfully trap the error and return a JSON-RPC error without altering internal state or attempting to process the payload11.

3. Authorization Attenuation Scenario: The runner provides a Biscuit token (IBCT) with an expired TTL or an escalated Datalog scope9. The agent's authorization middleware must cryptographically reject the token and return an HTTP 401 Unauthorized, proving that multi-hop delegation limits are strictly enforced.

4. Task State Machine Scenario: The runner initiates a valid task. The agent must accurately reflect the TASK\_STATE\_WORKING status. The runner then issues a tasks/cancel request. The agent must immediately transition the state to TASK\_STATE\_CANCELED and halt further processing11.

5. Economic Constraint Scenario: The runner requests a resource requiring L402 payment but supplies an invalid cryptographic preimage. The agent must successfully return a 402 Payment Required header and an unfulfilled macaroon17.

Agents that pass 100% of these deterministic scenarios are classified as Tier 1, providing absolute confidence to counterparties that the agent will behave predictably and securely on the network51.

8. Recommendations: What to Standardize Immediately and What to Leave Flexible

The historical success of internet protocols (such as TCP/IP and HTTP) lay in their strict regulation of the "wire" and their total leniency regarding the "application." The agent coordination network must adhere strictly to this philosophy.

8.1 Standardize Immediately (The Wire)

1. The Identity and Discovery Format: The network must immediately standardize on did:tdw for identity and the A2A Agent Card for discovery. The mechanism by which agents find each other must be strictly uniform to enable exponential network effects3.

2. The Transport and State Machine: Standardize entirely on stateless JSON-RPC 2.0 over HTTP, mapping all interactions to the A2A Task Lifecycle. Independent agents must share a rigid, mathematical understanding of what it means for a task to be "submitted," "blocked," or "completed"4.

3. Cross-Boundary Authorization: Standardize on Biscuit/IBCT for capability delegation and L402 for economic micro-transactions. This ensures agents can transact securely and attenuate permissions offline without relying on centralized OAuth authorization servers or financial intermediaries9.

4. Audit Receipts: Standardize on SCITT COSE receipts for task settlement. A universally verifiable non-repudiation mechanism is mandatory for machine-to-machine commerce14.

8.2 Leave Entirely Flexible (The Application)

1. Internal Tool Invocation: The network must not enforce how an agent communicates with its own databases or APIs. Whether an agent uses MCP, direct Python execution, or legacy REST APIs internally is strictly irrelevant to the network. Enforcing MCP across the public network boundary introduces severe tool metadata poisoning and prompt injection risks that degrade the entire ecosystem20.

2. Cognitive Architecture and Runtimes: The choice of underlying large language model, memory indexing strategies (e.g., Vector DBs vs. GraphRAG), and orchestrator frameworks (e.g., LangChain, AutoGen, CrewAI) must remain entirely proprietary. The network cares only about the standardized JSON-RPC input and output at the boundary46.

3. Prompt Construction: The network protocol must never dictate how system prompts are structured, how agents conduct multi-turn reasoning, or how contextual logic is maintained within the agent's execution loop.

By heavily standardizing the boundary interface (identity, discovery, authorization, and task state) while rigorously protecting the sovereignty of the internal runtime, the coordination network achieves global interoperability. Adoption transforms from a complex integration nightmare into a frictionless, high-ROI decision for independent economic agents, accelerating the transition from isolated automated silos to a collaborative, trustless agentic economy.

Works cited

1. Model Context Protocol \- Wikipedia, https://en.wikipedia.org/wiki/Model\_Context\_Protocol

2. What is MCP? The Model Context Protocol Explained \- DataWalk, https://datawalk.com/what-is-mcp-the-model-context-protocol-explained/

3. Agent2Agent (A2A) Protocol: What It Is and How It Works \- Turing Post, https://www.turingpost.com/p/a2a

4. A2A protocol: Architecture and technical specification \- Tyk.io, https://tyk.io/learning-center/a2a-protocol-architecture-and-technical-specification/

5. Chapter 8: Open Standards and Intellectual Property Rights, https://people.bu.edu/tsimcoe/documents/published/OpenStandards\_IPR.pdf

6. Coming full circle: How Self-Sovereign Identity Could Lose Its Way, https://ggreve.medium.com/coming-full-circle-how-self-sovereign-identity-could-lose-its-way-069b480c4399

7. W3C Verifiable Credentials 2.0: The New Standard Reshaping, https://vidos.id/blog/w3c-verifiable-credentials-2-0-the-new-standard-reshaping-enterprise-digital-identity

8. A Novel Zero-Trust Identity Framework for Agentic AI \- arXiv, https://arxiv.org/html/2505.19301v2

9. Agent Identity Protocol for Verifiable Delegation Across MCP and A2A, https://arxiv.org/html/2603.24775v1

10. The Model Context Protocol Explained | by Zia Babar \- Medium, https://medium.com/@zbabar/the-model-context-protocol-explained-5f35223e4d56

11. A2A/docs/specification.md at main · a2aproject/A2A \- GitHub, https://github.com/a2aproject/A2A/blob/main/docs/specification.md

12. DARP: Durable Activity Record Protocol \- Flavio Copes, https://flaviocopes.com/darp/

13. Social Web Protocols \- W3C, https://www.w3.org/TR/social-web-protocols/

14. draft-emirdag-scitt-ai-agent-execution-00 \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-emirdag-scitt-ai-agent-execution/

15. AgentLair Now Issues Verifiable Agent Receipts via SCITT, https://agentlair.dev/blog/scitt-phase-2-receipts/

16. Introduction to L402: Lightning-Powered Payment Protocol for AI, https://www.nervos.org/knowledge-base/introduction\_to\_l402

17. L402 Protocol Explained: HTTP 402 for Machine API Payments, https://satgate.io/blog/l402-protocol-explained

18. Getting Started with Agent2Agent (A2A) Protocol: A Purchasing, https://codelabs.developers.google.com/intro-a2a-purchasing-concierge

19. Build Cross-Language Multi-Agent Team with Google's Agent, https://developers.googleblog.com/build-cross-language-multi-agent-team-with-google-agent-development-kit-and-a2a/

20. All About the A2A Protocol, Now Part of the Agentic AI Foundation, https://rohitghumare.com/blog/a2a-protocol/

21. Cryptographic Chain-of-Custody for Agentic AI Systems \- IETF, https://www.ietf.org/archive/id/draft-helixar-hdp-agentic-delegation-00.html

22. AI agents and the multi-hop delegation problem \- WorkOS, https://workos.com/blog/oauth-multi-hop-delegation-ai-agents

23. On-behalf-of identity at machine speed: what AI agents change, https://www.oleria.com/blog/on-behalf-of-identity-at-machine-speed

24. Agent Identity and Delegated Authorization: OAuth Patterns for, https://tianpan.co/blog/2026/04/18/agent-identity-delegated-authorization-oauth-agentic-actions

25. UCAN \- Boris Mann, https://bmannconsulting.com/notes/ucan/

26. Use UCAN tokens for delegated authorization \- NFT.Storage, https://classic-app.nft.storage/docs/how-to/ucan/

27. Agent Identity Protocol for Verifiable Delegation Across MCP and A2A, https://arxiv.org/pdf/2603.24775

28. How AI Agents Authenticate Purchases in 2026 | Support \- Eco, https://eco.com/support/en/articles/15192005-agent-identity-verification-how-ai-agents-authenticate-purchases-in-2026

29. A2A v1.0 Builder's Guide Part 1: Discovery, Tasks, and Clients, https://aaif.io/blog/a2a-v1-0-a-builder-s-guide-part-1-discovery-tasks-and-clients

30. w3c/activitypub \- GitHub, https://github.com/w3c/activitypub

31. A Review on Agent-to-Agent Protocol: Concept, State-of-the-art, https://www.techrxiv.org/doi/pdf/10.36227/techrxiv.174612014.42157096/v1

32. Specification \- A2A Protocol, https://a2a-protocol.org/v0.3.0/specification/

33. The 2026-07-28 MCP Specification Release Candidate, https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/

34. Command Injection: Uncovering A New Attack Vector of MCP Server, https://www.keysight.com/blogs/en/tech/nwvs/2026/01/12/mcp-command-injection-new-attack-vector

35. Exposing Developer Pitfalls in MCP Tool Server Security under Multi, https://arxiv.org/html/2604.21477v2

36. Your AI Agent Trusts Every Tool It's Ever Been Introduced To \- DZone, https://dzone.com/articles/ai-agent-tool-trust

37. MCP Security: What 4 Chatbots Agree and Miss \- Adversa AI, https://adversa.ai/blog/security-risks-of-the-model-context-protocol-can-autonomous-agents-handle-adversarial-testing-conversation-with-chatgpt-claude-grok-deepseek/

38. Requirements for DID Method Standardization \#10 \- GitHub, https://github.com/decentralized-identity/did-methods/issues/10

39. Decentralized Identity (DID): The Complete Guide to Self-Sovereign, https://medium.com/@ancilartech/decentralized-identity-did-the-complete-guide-to-self-sovereign-identity-in-web3-871bfcdc3335

40. The did:webvh DID Method \-- did:web \+ Verifiable History \- v1.0, https://identity.foundation/didwebvh/

41. DIF Announces Two New Work Items in Identifiers & Discovery, https://blog.identity.foundation/id-discovery-work-items/

42. ietf-scitt \- Supply Chain Integrity, Transparency, and Trust \- GitHub, https://github.com/ietf-scitt

43. Why L402 Is the Internet-Native Payments Protocol for Agents, https://lightning.engineering/posts/2026-03-11-L402-for-agents/

44. L402: Lightning HTTP 402 Protocol \- Builder's Guide, https://docs.lightning.engineering/the-lightning-network/l402

45. L402: Lightning HTTP 402 Protocol \- GitHub, https://github.com/lightninglabs/l402

46. Protocol Conformance vs. Runtime Agency in Agent-to-Agent Systems, https://medium.com/@vivekvjnk/architectural-blueprint-protocol-conformance-vs-runtime-agency-in-agent-to-agent-systems-8f773531e764

47. A Semantic View of Agent Communication Protocols \- arXiv, https://arxiv.org/html/2604.02369v2

48. Secure Input Handling, https://www.cs.ru.nl/\~erikpoll/papers/secure\_input\_handling.pdf

49. Postel's Law and the Three Ring Circus | Hacker News, https://news.ycombinator.com/item?id=43487128

50. CRLF is obsolete and should be abolished \- Hacker News, https://news.ycombinator.com/item?id=41830717

51. Conformance Testing and Quality Metrics \- DeepWiki, https://deepwiki.com/modelcontextprotocol/modelcontextprotocol/6.3-conformance-testing-and-quality-metrics

52. MCP Promoted Its Rust SDK to Tier 1\. Here Is What That Means, https://www.digitalapplied.com/blog/mcp-sdk-conformance-tiers-what-tier-1-means