This article is complemented by a summary infographic that gives the overview in a single image: Agentic protocols in 2026, in one infographic. The article, for its part, develops what an image cannot detail.

In 2026, the protocols that let artificial intelligence agents connect to tools, talk to each other, act on the web, display interfaces, buy and pay have multiplied. An agent is a piece of software that uses a large language model (LLM, Large Language Model, a model trained on very large text corpora) to decide on its own a sequence of actions in order to reach a goal.

A companion infographic maps all these protocols, layer by layer. This article extends that overview: it does not repeat the detail, but sheds light on what an image cannot develop.

Three questions guide the reading.

• When several protocols overlap, what is the real difference between them?
• Who governs these protocols, and why does the governance model matter?
• What does a concrete use case look like, combining the most mature protocols?

The protocols at a glance

This table lists, in text form, the protocols mapped by the infographic, in alphabetical order, with one sentence on what each one enables. It serves as an accessible complement to the image, whether for reading on a small screen or for search.

Acronym	Full name	What it enables
A2A	Agent-to-Agent Protocol	Lets agents from different vendors collaborate on a task.
A2UI	Agent-to-User Interface	Lets an agent describe an interface. The client software, for example an assistant, displays it with its own graphical components.
ACP Commerce	Agentic Commerce Protocol	Lets a user buy directly inside an agent’s interface (born in ChatGPT).
ADS (AGNTCY)	Agent Directory Service	Lets an agent publish its descriptive record in a distributed directory and discover other agents there.
AG-UI	Agent-User Interaction Protocol	Lets an agent stream in real time what it is doing to the interface that displays it, so the user can follow progress.
ANP	Agent Network Protocol	Lets you build a decentralised network of agents, where each one carries a self-sovereign identity.
AP2	Agent Payments Protocol	Lets a user authorise a purchase made by an agent, in a provable way.
Identity (AGNTCY)	AGNTCY Identity	Lets an agent hold an identity and a signed credential, verifiable by a third party, attesting who it is.
Mastercard Agent Pay	Mastercard’s agentic payment program	Lets an agent pay on the Mastercard network, after authenticating the agent and verifying the buyer’s intent.
MCP	Model Context Protocol	Lets an agent connect to external tools, data and services.
MCP Apps	MCP interface extension (SEP-1865)	Lets an MCP server return an interactive interface instead of plain text, displayed in the conversation between the user and the assistant.
MPP	Machine Payments Protocol	Lets machines pay each other over HTTP, adding management of the payment lifecycle (recurring subscriptions, continuous streaming).
NLIP	Natural Language Interaction Protocol	Lets agents, or an agent and a human, exchange messages in a common wrapping format that standardises their structure whatever the sender.
NLWeb	Natural Language Web	Lets a website become queryable in natural language, by a user or an agent.
OASF (AGNTCY)	Open Agentic Schema Framework	Lets agents describe what they can do in a standardised format.
SLIM (AGNTCY)	Secure Low-latency Interactive Messaging	Carries messages between agents quickly and encrypted.
TAP	Trusted Agent Protocol	Lets an agent buying for a human prove to the merchant that it is legitimate, and not a malicious bot.
UCP	Universal Commerce Protocol	Lets an agent buy for a user from an online merchant: discover products, fill a cart and pay, in an open way.
WebMCP	Web Model Context Protocol	Lets a website declare actions that the browser-embedded agent, for example Claude in Chrome, can run.
x402	Native payment in HTTP (code 402)	Lets you pay directly, over the web, for access to content or a service, for micropayments between machines.

Untangling the protocols that overlap

Several protocols occupy neighbouring ground, which causes confusion. For each family, we first give the usage context, then the comparison dimension by dimension. The summary table appears at the end of each comparison.

Agent to agent: A2A, ANP and NLIP

These three protocols serve to make agents communicate with each other, for example when one company’s agent must delegate a task to a partner’s agent. What separates them comes mainly down to identity and trust.

Identity

This dimension covers two notions that should not be confused: the agent’s identity, that is the identifier that designates it, and authentication, that is the proof that it does control this identity. The next section details them. The three protocols position themselves differently.

A2A prescribes no model. It is the called agent that sets, in its record (the Agent Card), the authentication method or methods required of those who want to call it, for example OAuth 2.0, OpenID Connect, an API key or mutual authentication by certificates. The calling agent obtains the credentials through a separate channel, the card never containing them. In practice, it is most often a federated identity, managed by an identity provider.

ANP chooses self-sovereign identity: each agent carries a decentralised identifier (DID, Decentralized Identifier, a W3C standard) and proves its identity by cryptography. Both models rely on cryptography; what separates them is the distribution of control: here, no imposed central identity provider, the identifier is managed by its holder, most often the agent.

NLIP does not handle identity. It focuses only on the format of the messages exchanged.

Governance

A2A is stewarded by the Linux Foundation and the Agentic AI Foundation, ANP by an open-source community with no formal foundation, NLIP by Ecma International.

Maturity and adoption

A2A clearly dominates adoption, with a stable specification and many players. ANP remains experimental, carried by a nascent community. NLIP is standardised but little adopted.

In practice

The real head-to-head is between A2A and ANP. A2A’s federated pragmatism wins on short-term adoption, while ANP’s self-sovereignty remains a longer-term bet. The latter also depends on the web’s centralised infrastructure: DNS, the directory that translates a domain name into an address, and certificate authorities, the bodies that issue the certificates proving that a site is indeed the one it claims to be.

NLIP shares the same ground, making agents communicate, but with a smaller ecosystem. That is what places it in this family, even if it weighs little in a real choice.

Protocol	Identity	Governance	Maturity
A2A (Agent-to-Agent Protocol)	No imposed model (most often federated)	Linux Foundation, AAIF	Production
ANP (Agent Network Protocol)	Self-sovereign identity (DID)	Open-source community	Experimental
NLIP (Natural Language Interaction Protocol)	Not handled (message format only)	Ecma International	Preview

Agent identity and authentication

The word identity covers three notions that are best kept separate.

• Identity: the identifier that designates the agent, stable over time, and the information attached to it.
• Authentication: proving that an agent does control the identity it claims, generally by a cryptographic proof, for example a digital signature made with a secret key that only it holds.
• Credential verification: checking that an attestation about the agent, for example that it belongs to a given company or that it is allowed to make purchases, signed by an issuer, is authentic and has not been altered.

Two families of standards answer these needs, with two opposite trust models.

The federated model: OAuth 2.0 and OpenID Connect

This is the mature and by far the most widespread approach. A trusted third party, the identity provider (internal to the company, or external such as Google, Microsoft or Okta), manages the agent’s identity and issues a signed token that proves this identity. Whoever receives this token trusts the provider that issued it, and therefore accepts the agent’s identity. OAuth 2.0 handles authorisation, that is what the agent is allowed to access, and OpenID Connect, built on top, adds authentication, that is the proof of who the agent is. Trust therefore depends on a central intermediary, the identity provider that issues the tokens.

The self-sovereign model: DID and verifiable credentials

Here, no imposed central identity provider. A DID (Decentralized Identifier, a W3C standard) is generated and controlled by its holder, which can be the agent itself, but also the organisation or the service that operates it, depending on the DID method used. This DID points to a document that publishes its public keys. The holder proves identity by signing a challenge with the corresponding private key. Both models therefore rely on cryptography; what separates them is the distribution of control, a central third party on one side, the DID holder on the other. Attestations about the agent, what it is and what it can do, take the form of verifiable credentials (Verifiable Credentials, another W3C standard). A verifiable credential is a document signed by an issuer. To check it, a verifier tests the signature with the issuer’s public key: it obtains proof that the document does come from that issuer and has not been altered. Verification nonetheless assumes that the verifier trusts the issuer, and a full verification may require checking the credential’s status or revocation. This model is emerging and still little adopted.

AGNTCY Identity: combining the two

AGNTCY Identity does not reinvent identity, it assembles the two previous approaches, the federated model and the self-sovereign model. An agent can reuse an existing federated identity (an OAuth provider, or its A2A Agent Card) or generate a DID, then attach verifiable credentials to it. It is a bridge between the federated world, mature, and the self-sovereign world, emerging.

In practice

These approaches overlap, because they aim at the same goal: giving an agent a trustworthy identity and a way to prove it. They do not oppose each other on function nor on the use of cryptography, which both employ, but on the distribution of control: a central third party that attests, or an identifier that its holder controls itself. The two can also coexist, and that is what AGNTCY Identity does. Today, the federated model remains the default choice, the self-sovereign one being the emerging direction.

Approach	Trust model	Who controls the identity	Maturity
OAuth 2.0 and OpenID Connect	Federated: a third party attests who the agent is	An identity provider	Mature, very widespread
DID and verifiable credentials	Self-sovereign: distributed control, proof by cryptography	The DID holder (agent or its operator)	Emerging
AGNTCY Identity	Combines federated and self-sovereign	Either	In deployment

Transport and messaging: SLIM, NLIP and AG-UI

Three building blocks may seem redundant, because all three carry messages or events between two components. They differ in the link they cover and in the role they play.

The link covered

This is the most important distinction. SLIM and NLIP connect agents to each other. AG-UI connects an agent to the interface the user sees. AG-UI is therefore not a competitor of SLIM or NLIP: it works on a different link.

The role

SLIM is a transport, the pipe through which messages travel between agents.

NLIP is an envelope, the common format in which these messages are written.

AG-UI is an event stream: it sends to the interface, as it goes, what the agent is doing, such as the text it produces, the tools it calls or the state of its execution, so the user can follow live.

What each one brings

SLIM provides a low-latency, end-to-end encrypted channel, through the Messaging Layer Security (MLS) mechanism, with several exchange modes: request-response, publish-subscribe, send without reply and continuous streaming. One may wonder why create SLIM when the web already has HTTP, WebSocket, gRPC or AMQP. The answer is that SLIM can substitute for these transports at the application level: the A2A adapters explicitly allow agents to talk over SLIM instead of a direct HTTP or gRPC connection. What it brings compared to them is end-to-end encryption that stays valid even when passing through untrusted intermediate relays, and exchange modes suited to agents, brought together in a single layer.

NLIP does not provide a transport on its own: it structures the messages, then relies on existing transports such as HTTP, WebSocket or AMQP.

AG-UI defines a list of typed events, transmitted over HTTP and Server-Sent Events, a technique where the server pushes its messages to the browser as they come.

In practice

These blocks combine rather than oppose each other. One could carry NLIP messages over a SLIM transport, SLIM competing mainly with the direct use of HTTP between agents. And one agent can talk to other agents via A2A carried by SLIM, while reporting its work to the user via AG-UI. None of the three is yet widely adopted: SLIM is in deployment, AG-UI too, NLIP in preview.

Building block	Link covered	Role	Technical basis
SLIM (AGNTCY)	Between agents	Transport, the pipe	gRPC, MLS encryption
NLIP	Between agents, or agent and human	Envelope, the format	HTTP, WebSocket or AMQP
AG-UI	Between an agent and its interface	Real-time event stream	HTTP and Server-Sent Events

Commerce: UCP versus ACP Commerce

These two protocols serve the same moment of the journey: letting an agent buy for a user on a merchant site, from product discovery to payment.

Target platform

UCP is an open, multi-platform standard: a merchant exposes its capabilities in the UCP format, and any agent that speaks this standard discovers its products, fills a cart and pays.

ACP Commerce covers the same thing, but it was born centred on ChatGPT. It now aims to be an open standard, published under the Apache 2.0 licence, even though it remains co-steered by OpenAI and Stripe rather than by a neutral foundation.

Stewarded by

UCP is steered by a governance board on which Google and Shopify sit as permanent members, joined by Stripe in April 2026, ACP Commerce by OpenAI and Stripe.

Maturity

The nuance is real. UCP is more advanced: a purchase journey is already in production on Google products, such as Search or the Gemini app, even though it is gradually extending to new merchants. ACP Commerce is at its first deployments.

In practice

Their designs converge, to the point that a merchant will probably have to support both. The decisive difference lies in governance. In March 2026, OpenAI removed integrated payment in ChatGPT and refocused on product discovery: this episode illustrates the risk of a standard co-steered by two players, which can change course according to their interests. UCP relies on a broader industry board, which makes a comparable shift less likely.

Protocol	Target platform	Stewarded by	Maturity
UCP (Universal Commerce Protocol)	Open, multi-platform	Google, Shopify, Stripe (board)	Progressive production
ACP Commerce (Agentic Commerce Protocol)	Centred on ChatGPT originally, aims to be open	OpenAI, Stripe	Deployment

Payment: authenticate, authorise, settle

Paying through an agent is not a single operation, but a chain of three links: authenticate the agent, authorise the purchase, then settle the amount. The protocols in this layer spread across these three links, and the right reading is to follow them one by one rather than compare the protocols two by two.

Authenticate the agent

Prove to the merchant that an agent is legitimate, and not a malicious bot. This is the role of TAP (Visa) and Mastercard Agent Pay. Both rely on Web Bot Auth, a signature profile defined by an IETF Internet-Draft, built on top of RFC 9421 (the general standard for HTTP message signatures): the agent signs its web requests with a cryptographic key, and the merchant verifies this signature. Verifying the signature proves the request’s integrity and possession of the key; to conclude that an agent is trustworthy, the merchant must also have a reliable association between this key, the agent’s operator and the program concerned.

Web Bot Auth differs from the approaches seen in the identity section, such as OAuth or DIDs. It does not seek to establish a general identity of the agent, but only to prove to a website, at the level of HTTP requests, that an automated agent is legitimate. It is a narrower building block, specialised in fighting fraud.

Authorise the purchase

Prove that the user did consent to the agent making this purchase for them. This is the role of AP2, which produces mandates. A mandate is a cryptographically signed proof that records what the user authorised: the cart contents, the amount and the conditions. It can serve as cryptographic proof in case of dispute, even though the specification does not guarantee its legal enforceability, which depends on the applicable law.

Settle the amount

The money transfer itself, provided by two neighbouring protocols.

x402 makes the payment go through the HTTP protocol, the very one used to load web pages. Concretely, when an agent requests a paid resource, for example an article, a dataset or a billed programming interface call, the server replies “payment required”, the agent pays, then receives what it asked for. Like MPP, x402 is independent of the payment method in its architecture, but its real use remains dominated by cryptocurrency.

MPP, from Stripe, starts from the same principle and stands out by adding management of the payment lifecycle: recurring subscriptions, continuous-stream payment, cancellation and reconciliation. It goes through Stripe’s banking distribution and settles in stablecoins as well as fiat currencies, for example the bank card or the bitcoin Lightning network.

The overlaps

Two remain: TAP against Mastercard Agent Pay on agent authentication, and x402 against MPP on settlement. The whole payment layer, these three links together, is the youngest and most fragmented part of the landscape.

In practice

x402 also has a use where it stands on its own: pay-per-call of a programming interface or a tool, with no account or subscription, the agent settling each request individually.

Protocol	Link	Technical basis	Stewarded by
TAP (Trusted Agent Protocol)	Authenticate the agent	Web Bot Auth (profile on top of RFC 9421)	Visa
Mastercard Agent Pay	Authenticate and pay	Web Bot Auth, tokenisation	Mastercard
AP2 (Agent Payments Protocol)	Authorise the purchase	Signed mandates	FIDO Alliance
x402	Settle (one-off exchange)	HTTP 402, independent of the payment method	x402 Foundation
MPP (Machine Payments Protocol)	Settle (with lifecycle: subscriptions, streams)	HTTP 402, card and crypto, via Stripe	Stripe, Tempo

Interface: MCP Apps versus A2UI

These two protocols serve to display a graphical interface (a form, a dashboard, buttons) that the agent brings up during the conversation, rather than spelling everything out in text. A word of vocabulary first: the server is the remote program that provides the content, and the client is the software that displays it to the user, for example ChatGPT or an assistant. The two protocols differ in how they transmit the interface.

What the agent sends

MCP Apps sends a genuine small web application, written in HTML and JavaScript, the languages of web pages. It is displayed in an isolated frame (an iframe, that is a web page embedded in another) inside the conversation interface between the user and the agent. A2UI, for its part, does not send code: it sends a description of the desired interface, a list of components such as “a button” or “a text field”, which the client software then turns into an interface with its own graphical elements. This is what is called a declarative approach: you describe the desired result, not how to build it.

Security

MCP Apps runs code provided by the server, that is by the remote program, so its security depends on how well that code is isolated, between the displayed application and the client that hosts it. A2UI is safer by design, because the client runs no foreign code: it only displays components it has itself defined.

Flexibility

MCP Apps can display just about any interface, since it sends real code. A2UI is limited to the components the client already knows how to recognise and build, so less free, but more predictable.

In practice

A2UI must not be confused with AG-UI, whose name is close. They are two different things: AG-UI is the channel that transmits in real time what the agent is doing towards the interface (the how), while A2UI describes the interface itself to display (the what).

Protocol	What the agent sends	Security	Flexibility
MCP Apps	A small web application (HTML, JavaScript)	Depends on code isolation	High
A2UI (Agent-to-User Interface)	An interface description (declarative)	Safe by design	Limited to the client’s catalogue

Web: WebMCP versus NLWeb

These two protocols serve to make a website usable by an agent, each by a different route.

Where it runs

WebMCP runs in the user’s browser, NLWeb on the server that hosts the site.

Interface offered

WebMCP exposes structured actions, prepared in advance, that the agent invokes directly. NLWeb adds a natural-language interface to the website, where you ask a question in plain language.

Target

WebMCP targets the agent embedded in the browser, for example Claude in Chrome. NLWeb addresses both a human and an agent.

In practice

The two approaches do not exclude each other and can coexist on the same site.

Protocol	Where it runs	Interface offered	Target
WebMCP (Web Model Context Protocol)	Browser side	Structured actions	Browser agent
NLWeb (Natural Language Web)	Server side	Natural language	Human or agent

Discovery: AGNTCY’s directory versus A2A’s Agent Card

Before collaborating, an agent must be able to find another one. These two approaches answer this discovery need, with directories organised differently.

Topology

The AGNTCY suite offers a distributed, federated directory (the ADS), spread across several servers on the DNS model. A2A relies first on the agent itself publishing its record (the Agent Card) at a standardised address, which is a decentralised mechanism. The A2A specification prescribes no central directory; enterprise registries, for example at AWS and Google, are one possible discovery strategy among others, not the protocol’s topology.

Format

AGNTCY describes agents in a common schema (the OASF), A2A in the Agent Card format.

Openness

AGNTCY’s ADS standardises a distributed, federated directory service. A2A standardises an agent’s description and leaves several means of discovery open; the cloud registries built on it, for their part, are centralised and proprietary, but they are implementations, not the protocol.

In practice

The two approaches are moreover compatible. An A2A agent can be published in the ADS directory: its record (the Agent Card) is wrapped in an OASF entry, which declares its skills from the common taxonomy, then published on the distributed network where these skills are used for search. AGNTCY thus provides the distributed directory that A2A lacks, A2A being limited to the agent’s description and several means of discovery.

Approach	Topology	Format	Openness
AGNTCY directory (ADS, OASF)	Distributed, federated (DNS-like)	OASF	Open
A2A Agent Card	Publication by the agent (decentralised), plus optional cloud registries	Agent Card	Open description; proprietary cloud registries

The four ACP acronyms

The acronym ACP is the main source of confusion in the field, because it designates four things with no technical link between them.

• IBM’s Agent Communication Protocol, merged into A2A in 2025.
• OpenAI and Stripe’s Agentic Commerce Protocol, described above.
• Cisco’s Agent Connect Protocol in the AGNTCY suite, now frozen because its function overlapped that of A2A.
• The editor Zed’s Agent Client Protocol, which connects a code editor to a coding agent.

In the current landscape, IBM’s Agent Communication Protocol has merged into A2A and AGNTCY’s has been frozen. Still active, in distinct areas, are the Agentic Commerce Protocol for commerce and Zed’s Agent Client Protocol for the connection between code editors and programming agents.

Acronym	Full name	Stewarded by	Status
ACP (IBM)	Agent Communication Protocol	IBM	Merged into A2A
ACP Commerce	Agentic Commerce Protocol	OpenAI, Stripe	Alive
ACP (AGNTCY)	Agent Connect Protocol	Cisco, AGNTCY	Frozen
ACP (Zed)	Agent Client Protocol	Zed	Alive, different area

Who governs these protocols, and why it matters

Governance decides a standard’s stability and openness. Three models coexist, and the model says a lot about the risks for whoever builds on it.

Neutral foundations, under the Linux Foundation

The Linux Foundation hosts four instances of the landscape:

• the A2A project,
• the AGNTCY project,
• the x402 Foundation,
• the Agentic AI Foundation (AAIF).

The latter, founded on 9 December 2025, is the reference foundation for agentic protocols (aaif.io). Its founding projects are MCP, the tool-connection protocol, goose, an open-source development agent from Block, and AGENTS.md, a standardised file format for giving instructions to coding agents. The agentgateway project, a gateway that secures and routes traffic between agents, joined it as a fourth project on 4 June 2026 (two official sources disagree on its founder status), and A2A joined it in August 2026. It had 247 members as of 13 August 2026. This model offers neutral governance, through open processes, with no control by a single player.

The established standards bodies

Four historical bodies govern adjacent standards.

• The W3C hosts the incubation of WebMCP in a Community Group. The document is a draft report; it states itself that it does not constitute a W3C standard and is not on the official standards track.
• The IETF produces the security RFCs that serve as a base for several protocols, including RFC 9421 (HTTP message signatures, the base of Web Bot Auth, of TAP and of Mastercard Agent Pay) and RFC 9207 (issuer validation, required by MCP).
• Ecma International (committee TC56) approved the NLIP suite.
• The FIDO Alliance, specialist in passwordless authentication, governs AP2 since April 2026.

These bodies bring formal and lasting standardisation, but at a slower pace.

Company-led steering, and its risk

Several standards are not governed by a neutral foundation.

• UCP is steered by industry boards (Google, Shopify and Stripe for the governance board, plus a broader technical board).
• ACP Commerce is co-steered by OpenAI and Stripe.
• TAP and Mastercard Agent Pay are steered by their card networks.
• NLWeb is an open-source project from Microsoft, with no formal governance.

A standard led by a company can evolve according to its interests: OpenAI’s removal of integrated payment in ChatGPT, in March 2026, is the clearest example. For an architect, this justifies preferring, at equal function, a standard carried by a neutral foundation.

Concrete use cases, on the most mature protocols

Here are a few combinations that are real or close to real, without aiming for exhaustiveness, sticking to the most advanced protocols: MCP and A2A are in production, UCP and MCP Apps too, NLWeb is in deployment with named adopters. The identity and payment layers, younger, complement these use cases without being battle-tested at scale yet.

An enterprise agent that acts and delegates (MCP and A2A)

An internal agent queries databases and business services through MCP servers, which give it access to its tools. When a subtask falls outside its scope, it delegates it to a partner’s specialised agent, via A2A, without knowing that agent’s internal workings. MCP connects the agent to its tools, A2A connects agents to each other: it is the basic duo of an agentic architecture, and both protocols are in production.

An agentic purchase on a Google surface (UCP)

Since February 2026, a US buyer can complete an Etsy or Wayfair purchase directly in Google’s conversational mode or in the Gemini app, thanks to UCP: the merchant publishes its capabilities, the agent negotiates the cart and triggers the payment. It is the most accomplished commercial use to date. The complementary layers exist but are younger: TAP to authenticate the agent to the merchant, AP2 to authorise a purchase in the user’s absence.

An interactive dashboard in the conversation (MCP Apps)

An MCP server of sales data no longer returns a long list of figures, but an interactive dashboard displayed in the conversation. The user filters, sorts and explores without rewriting a query, and the model sees these actions and can react. This use is real today in Claude, ChatGPT, VS Code and Goose.

A site made conversational for agents (NLWeb on top of MCP)

Publishers such as O’Reilly, Allrecipes or Tripadvisor expose their content in natural language with NLWeb. Since each NLWeb instance is itself an MCP server, an agent can query the site like any other tool. NLWeb is built on top of MCP, which shows how protocols stack up rather than replace each other.

Conclusion

The September 2026 landscape reads better by separating what is settled from what is still being sought. The tool and agent layers converge towards two shared, jointly governed standards. The commerce and payment layers remain a field of competition between big players. For an architect, the practical approach is to build on MCP and A2A, to choose the commerce layer according to the surfaces and partners targeted, and to follow the payment layer without committing too early.

The open question for the coming months is whether the payment layers converge, or not, around a common authorisation model. On the identity side, A2A already has, since version 1.0, a first verifiable building block, the Agent Card signature (in JSON Web Signature format), which proves the record’s integrity and origin; what remains to build is a fuller trust model and a proof of identity at the level of each exchange, not just of the record.

Bibliography and sources

• MCP: Model Context Protocol specification
• A2A and client authentication: a2a-protocol.org and A2A agent-discovery documentation
• ANP: agent-network-protocol.com
• Decentralized identifiers (DID): W3C DID standard
• Verifiable Credentials: W3C data model
• AGNTCY suite (SLIM, ADS, OASF, Identity): docs.agntcy.org
• NLIP: Ecma International TC56 committee
• WebMCP: Web Machine Learning Community Group report
• NLWeb: NLWeb repository on GitHub
• AG-UI: docs.ag-ui.com
• MCP Apps: MCP Apps extension overview
• A2UI: a2ui.org
• UCP and its governance: ucp.dev and UCP announcements
• ACP Commerce and the removal of integrated payment: agenticcommerce.dev and OpenAI’s announcement on product discovery
• AP2: ap2-protocol.org
• TAP: Trusted Agent Protocol at Visa
• x402: x402.org
• MPP: Machine Payments Protocol on Stripe’s blog
• Mastercard Agent Pay: Mastercard Agent Pay page
• Governance: Linux Foundation and Agentic AI Foundation; W3C; IETF; FIDO Alliance