Consolidated research · finalized reference
AI acronyms, agent protocols, commerce, identity, and governance
A durable field guide to what each term means, where it is used, whether a specification exists, how implementations behave, what can run locally or remotely, how portable it is, and what an enterprise must govern beyond the wire protocol.
There is no single agent protocol. The durable architecture is a composable stack: MCP for capabilities, A2A for delegation, UI protocols for interaction, commerce protocols for checkout, authorization artifacts for user intent, payment protocols for settlement negotiation, and existing identity and policy standards for control.
The highest-risk gap is not message transport. It is preserving identity, authorization, semantics, evidence, and recovery while requests cross adapters and organizational boundaries.
Know what kind of thing you are evaluating
AI language places management methods, design patterns, transport protocols, specifications, and laws into the same acronym soup. Evaluation starts by separating them.
| Type | Meaning | Examples | Enforcement |
|---|---|---|---|
| Acronym | An abbreviation, not an implementation contract. | AI, LLM, RAG, OKR | None by itself. |
| Technique or pattern | A reusable way to design or operate a system. | RAG, ReAct, HITL | Engineering practice and evaluation. |
| Convention | A voluntarily adopted shared format. | AGENTS.md, llms.txt, Agent Skills | Tool adoption and ecosystem expectation. |
| Specification | Normative requirements or a data model. | MCP specification, A2A specification, C2PA | Conformance, contracts, and compatible implementations. |
| Protocol | Messages, states, interactions, errors, and lifecycle rules. | MCP, A2A, x402, MPP | Interoperable clients and servers. |
| Framework | Software used to build or run systems. | ADK, LangGraph, Semantic Kernel | Runtime behavior and vendor support. |
| Governance framework | An organizational risk and control model. | NIST AI RMF | Internal policy, procurement, or sector guidance. |
| Certifiable standard | Auditable management-system requirements. | ISO/IEC 42001 | Certification, contracts, and procurement. |
| Regulation | Legally binding obligations. | EU AI Act | Regulators, courts, and contractual allocation. |
Do not equate “open,” “uses RFC language,” or “has a GitHub repository” with a mature standard. Look for independent implementations, conformance tests, operational interoperability, neutral governance, lifecycle policy, and procurement recognition.
The emerging agent stack
Each layer answers a different question. Combining them is normal. Collapsing them creates ambiguous trust and recovery behavior.
Decision map
Start with the relationship being standardized. Then select the protocol, not the other way around.
Current landscape and enterprise stance
The stance reflects public specifications, SDK breadth, conformance evidence, implementation activity, governance, and observable portability gaps at the research cutoff.
| Protocol | Category | Primary role | Evidence maturity | Position | Local / remote | Portability | Evidence |
|---|---|---|---|---|---|---|---|
| MCPModel Context Protocol | Capability protocol | Agent ↔ tools, resources, prompts, apps | Operationally established core | Adopt | Local and remote | High wire; moderate full-stack | S01S02S03S05 |
| A2AAgent2Agent Protocol | Delegation protocol | Agent ↔ independent agent | Operationally established core | Adopt | Primarily networked; localhost possible | High envelope; moderate behavior | S08S09S11S12S13 |
| ACPAgent Client Protocol | IDE protocol | Coding agent ↔ editor | Operationally credible | Selective adopt | Local stdio and remote transports | Moderate; host capability dependent | S14 |
| AG-UIAgent User Interaction Protocol | UI event protocol | Agent backend ↔ application frontend | Operationally credible | Selective adopt | Remote HTTP/WebSocket patterns | Moderate; adapter dependent | S15S16 |
| A2UIAgent-to-UI | Declarative UI protocol | Remote agent → trusted native component catalog | Emerging implementation | Strategic pilot | Local or remote payload delivery | Moderate; catalog dependent | S17S18 |
| MCP AppsMCP Apps extension | Embedded application protocol | MCP server → sandboxed interactive view | Emerging implementation | Selective adopt | Local or remote MCP | Host-specific today | S06S07 |
| WebMCPWeb Model Context Protocol | Browser capability protocol | Web page ↔ browser-mediated agent | Experimental draft | Experiment | Browser-local page context | Low until browser convergence | S19S20 |
| ACPAgentic Commerce Protocol | Commerce protocol | Buyer agent ↔ merchant checkout | Beta / emerging implementation | Pilot | Remote commerce APIs | Moderate within ecosystem | S21 |
| UCPUniversal Commerce Protocol | Commerce protocol | Discovery, checkout, orders, identity, payments | Operationally credible | Strategic pilot | REST, MCP, and A2A bindings | Promising; semantic variation remains | S22S23S24S25 |
| AP2Agent Payments Protocol | Authorization evidence protocol | User intent and delegated transaction mandates | Emerging implementation | Strategic pilot | Local demos; remote transaction use | Moderate artifact portability | S26 |
| x402x402 | Machine payment protocol | Pay-per-resource over HTTP 402 | Operationally credible | Selective adopt | Local server possible; remote settlement common | High envelope; payment-scheme dependent | S27S28 |
| MPPMachine Payments Protocol | Machine payment protocol | HTTP payment negotiation across methods | Operationally credible but young | Strategic pilot | Local development and remote settlement | Promising; method dependent | S29S30S31 |
| AuthZENAuthorization API | Authorization protocol | Policy enforcement point ↔ decision point | Operationally credible | Adopt | Local or remote PDP | Decision API portable; policies not necessarily | S32 |
| TAPTrusted Agent Protocol | Agent trust protocol | Agent request identity and merchant verification | Emerging implementation | Pilot | Local sample; remote merchant edge | Moderate cryptographic envelope portability | S33 |
| Verifiable IntentVerifiable Intent | Delegation credential | Human → agent constraints and selective disclosure | Draft implementation | Pilot | Portable signed artifacts | Promising; draft and trust-anchor dependent | S34 |
| OASFOpen Agentic Schema Framework | Discovery schema | Agent identity, skills, domains, metadata | Emerging but executable | Pilot | Local schema server or remote registry | High metadata; translation can be lossy | S35S36 |
| Agent SpecOpen Agent Specification | Interchange format | Declarative agents, flows, tools, runtimes | Emerging interchange format | Evaluate | Local files and runtime adapters | Syntax high; semantic behavior moderate/low | S38 |
| Agent SkillsAgent Skills | Packaging convention | Reusable instructions, scripts, references, assets | Useful convention | Adopt | Local packages; distributable remotely | Moderate; runtime and supply-chain dependent | S39S40 |
| AGENTS.mdAGENTS.md | Repository convention | Coding-agent repository instructions | Widely useful convention | Adopt | Local repository | High text portability; behavior host dependent | S41 |
| UTCPUniversal Tool Calling Protocol | Tool discovery/invocation protocol | Agent → native HTTP, CLI, gRPC, WebSocket, MCP tools | Draft with implementations | Evaluate | Local and remote | Potentially high; shifts complexity to client | S42 |
| Web Bot AuthWeb Bot Auth | Request authentication | Bot/agent operator → website | Emerging deployment pattern | Pilot | Remote HTTP | Cryptographic request portability; authorization separate | S43 |
| ERC-8004Trustless Agents | Registry protocol | On-chain identity, reputation, validation | Experimental | Experiment | Remote blockchain; local devnets possible | Registry portable; enterprise trust incomplete | S46S47 |
Origin and governance map
| Initiative | Origin or principal sponsor | Current public home | Governance interpretation |
|---|---|---|---|
| MCP | Originally introduced by Anthropic | Model Context Protocol project; included in the Linux Foundation Agentic AI Foundation portfolio | Open project with growing neutral-foundation governance and working groups. S03S63 |
| A2A | Originally contributed by Google | Linux Foundation A2A project | Neutral foundation governance with multi-vendor SDK and conformance work. S08 |
| Agent Client Protocol | Zed and coding-agent ecosystem | Agent Client Protocol organization | Open ecosystem protocol; adoption depends on editor and agent support. S14 |
| AG-UI | AG-UI / CopilotKit ecosystem | AG-UI project | Open protocol with framework adapters; adapter fidelity is a material concern. S15 |
| A2UI | Google A2UI project | Open early-stage protocol; renderer and catalog convergence still developing. S18 | |
| WebMCP | Browser and web-platform contributors including Google and Microsoft | W3C Community Group draft | Incubation venue, not a W3C Recommendation. S19 |
| Agentic Commerce Protocol | OpenAI and Stripe | Jointly maintained open repository | Founding-maintainer governance with a stated path toward broader stewardship. S21 |
| UCP | Google-led commerce initiative | Universal Commerce Protocol organization | Open-source specification, SDK, and conformance ecosystem. S22S23 |
| AP2 | Google Agentic Commerce | Public specification, SDK models, and samples | Reference-led emerging protocol; broader trust-standard convergence remains in progress. S26 |
| x402 | x402 ecosystem | x402 Foundation | Open payment protocol with multi-language implementation and extension activity. S27 |
| MPP | Tempo and Stripe | MPP specifications and SDK ecosystem | Maintainer-led young protocol with cross-language implementation. S29S30 |
| AuthZEN | OpenID Foundation community | OpenID AuthZEN working group repository | Standards-oriented authorization interoperability work. S32 |
| TAP / Verifiable Intent | Visa / Mastercard-led initiatives | Public reference repositories | Payment-network trust contributions; not universal enterprise authorization systems by themselves. S33S34 |
| OASF / AGNTCY | Cisco-originated AGNTCY ecosystem | AGNTCY open repositories | Discovery, schema, directory, and secure agent infrastructure portfolio. S35S36 |
| Agent Spec / NLWeb / Web Bot Auth | Oracle / Microsoft / Cloudflare | Separate public projects | Company-originated open work solving agent interchange, conversational web, and signed-bot identity respectively. S38S61S43 |
Protocol briefs
Each brief answers the same operational questions: current state, use case, deployment model, portability, and required controls.
Capability layer
MCP — Model Context Protocol
The default open protocol for connecting an agent host to tools, resources, prompts, and optional interactive applications.
- Current
2025-11-25stable at the cutoff.- Next
2026-07-28release candidate: stateless core, extensions, Tasks, Apps, authorization hardening.- Run
- Local subprocess, remote HTTP, containers, serverless, or hybrid gateways.
- Portability
- Strong wire and schema portability. Moderate auth, approval, UI, and behavioral portability.
Use when
A host needs structured access to an API, database, repository, search system, workflow, prompt library, or user interface.
Enterprise controls
- Separate protocol termination from domain authorization.
- Run stable and candidate conformance suites in CI.
- Publish an explicit host capability matrix.
- Propagate user, workload, delegation, trace, deadline, and idempotency context.
Coordination layer
A2A — Agent2Agent Protocol
The default candidate for delegating outcomes to an independent, opaque agent while preserving task lifecycle and artifacts.
- Current
- Stable 1.0 specification.
- Bindings
- JSON-RPC, gRPC, and HTTP+JSON.
- Run
- Localhost, internal network, multicloud, or cross-organization.
- Portability
- Strong task-envelope portability. Behavioral equivalence remains framework-specific.
Use when
The remote party owns its workflow and returns status, messages, artifacts, or requests for more input.
Enterprise controls
- Treat Agent Cards and remote artifacts as untrusted input.
- Test cancellation, resubscription, push authentication, deadlines, and idempotency.
- Preserve user and workload identity across every hop.
- Do not flatten autonomous agents into generic tool calls when task semantics matter.
Developer experience
ACP — Agent Client Protocol
Separates a coding agent from the editor surface, similar in spirit to how language servers separate language intelligence from IDEs.
- Run
- Local standard I/O and remote transports.
- Owns
- The agent owns model, runtime, authentication, and tools; the editor owns interaction.
- Complements
- MCP can supply tools to the coding agent.
- Gap
- Tool schemas, reasoning events, process lifecycle, and MCP configuration may not bridge identically.
Evidence S14
Experience layer
AG-UI, A2UI, MCP Apps, and WebMCP
Decision rule
Choose by trust boundary and rendering ownership. A shared acronym does not make these alternatives interchangeable.
Commerce layer
ACP commerce and UCP
Both describe agent-mediated commerce, but they differ in ecosystem origin, lifecycle breadth, conformance evidence, and governance maturity.
Architecture rule
Keep a canonical internal commerce domain. Implement ACP and UCP as adapters. Preserve raw protocol evidence for disputes and migration.
Transaction layer
AP2, x402, and MPP
Architecture rule
Authorization evidence is not settlement. Payment is not checkout. Checkout is not dispute resolution. Model each independently.
Trust layer
OAuth, AuthZEN, TAP, and Verifiable Intent
Identity remains the least consolidated layer. Different mechanisms prove different actors, authorizations, and transaction facts.
- OAuth/OIDC and workload identity: principals and delegated access.
- AuthZEN: a portable policy decision interface, not a portable policy language.
- Visa TAP / Web Bot Auth: signed agent-originated HTTP requests.
- Verifiable Intent / AP2: user-imposed transaction constraints and evidence.
“ACP” is not one protocol
OpenAI and Stripe commerce and checkout specification.
Coding-agent-to-editor integration.
IBM/BeeAI initiative that joined the A2A direction.
AGNTCY REST-oriented agent invocation specification, now archived.
Control: spell out the name in every architecture diagram, ADR, catalog, dependency record, telemetry attribute, and procurement document. S14S21S37
What public code changed
Specifications explain intent. Repositories reveal operational maturity, integration loss, version drift, and the difference between reference code and an interoperable ecosystem.
Implementation and framework surface
| Ecosystem | Public implementation surface | Practical implication | Evidence |
|---|---|---|---|
| MCP | Official SDKs across TypeScript, Python, Java, Kotlin, C#, Go, PHP, Ruby, Rust, and Swift; Inspector and conformance tooling. | Broad language portability, but advanced capabilities and host behavior still need a tested matrix. | S03S04S05 |
| A2A | Official Python, Go, JavaScript, Java, .NET, and Rust SDKs; samples, TCK, and multi-hop ITK. | One of the strongest public interoperability test surfaces in the agent protocol landscape. | S11S12S13 |
| Agent Client Protocol | Rust, TypeScript, Python, and Kotlin SDKs plus coding-agent adapters. | Useful editor-agent portability; MCP forwarding and host extensions require pairwise validation. | S14 |
| AG-UI | Reference implementation and adapters for frameworks including LangGraph, CrewAI, Microsoft Agent Framework, Google ADK, AWS Strands, and Mastra. | Framework breadth is high; transformation correctness is the main release risk. | S15 |
| A2UI / MCP Apps | Reference renderers and examples; MCP Apps libraries for views, React, app bridges, and servers. | Host and renderer implementations remain part of the interoperability contract. | S18S06 |
| Commerce | UCP JavaScript and Python SDKs plus conformance; ACP OpenAPI, JSON Schema, RFCs, and examples. | UCP currently exposes stronger independent implementation scaffolding; both still belong behind adapters. | S23S24S25S21 |
| Payments | x402 TypeScript, Python, and Go implementations; MPP TypeScript, Python, Rust, Go, and Ruby implementation paths. | Executable ecosystems exist; commercial and regulatory completeness still depends on the chosen method and provider. | S27S29 |
| Agent interchange | Agent Spec adapters and reference runtime for multiple agent frameworks; OASF validation and registry tooling. | Configuration can move more easily than behavior. Require explicit loss reports and behavioral contract tests. | S38S35 |
Stronger than expected
UCP
SDKs and a language-independent conformance suite move UCP beyond a documentation-only proposal. It is the strongest candidate for a neutral commerce adapter, though not a canonical internal model. S22S23S24S25
Stronger than expected
x402 and MPP
Both expose executable middleware, SDKs, and local practice paths. Their remaining gaps are commercial, regulatory, settlement, refund, and payment-method semantics—not absence of code. S27S29S30S31
More caution required
Agentic Commerce Protocol
The public core is a beta specification with schemas, OpenAPI artifacts, RFCs, and examples. Treat it as an ecosystem adapter until independent conformance and broader implementation evidence mature. S21
Core mature, edge uneven
MCP
Multiple official SDKs, Inspector, and conformance tooling establish the core. Host approvals, remote auth, user attribution, advanced features, and Apps support still require explicit compatibility evidence. S03S04S05S06
“Compatible” must be qualified. A production claim should name the protocol version, SDK, transport, host, extension set, authentication flow, conformance results, and known semantic losses.
Bridge fidelity is the principal interoperability risk
A bridge is a compiler between semantic systems. It can produce valid output while changing meaning.
A protocol bridge is a compiler, not a pipe.
Identity invariants
- User principal
- Agent principal
- Workload principal
- Delegation chain
- Audience and tenant
Tool invariants
- Input and output schema
- Annotations
- Error code and severity
- Side-effect classification
- Approval requirement
Execution invariants
- Cancellation
- Deadline
- Idempotency
- Trace context
- Retry semantics
Content invariants
- MIME type
- Filename
- Structured content
- Binary integrity
- Provenance
Streaming invariants
- Ordering
- Partial versus final
- Duplicate handling
- Replay behavior
- Reconnect semantics
Policy invariants
- Decision inputs
- Obligations
- Human approval state
- Purpose and spend limits
- Runtime re-evaluation
State invariants
- Task identifier
- Checkpoint
- Memory scope
- Artifact lineage
- Session boundary
Failure rule
- Fail explicitly
- Emit compatibility report
- Never silently downgrade
- Retain source envelope
- Provide rollback path
Machine-readable bridge contract
identity:
user_principal: preserve
agent_principal: preserve
workload_principal: preserve
delegation_chain: preserve
tool:
input_schema: preserve
output_schema: preserve
errors: preserve_code_and_severity
execution:
cancellation: preserve
deadline: preserve
idempotency_key: preserve
trace_context: preserve
approval_state: preserve
content:
mime_type: preserve
filename: preserve
structured_content: preserve
binary_integrity: preserve
unsupported_behavior: fail_or_report_explicitly
Measure portability in eight dimensions
Wire compatibility is the beginning, not the conclusion.
1. Wire
Can another implementation parse and produce the message?
2. Schema
Are objects, fields, constraints, and errors equivalent?
3. Behavioral
Will workflows, retries, approvals, and tool use behave equivalently?
4. Identity
Can user, agent, workload, and delegation identities survive movement?
5. Policy
Can authorization intent move independently of runtime code?
6. State
Can tasks, memory, checkpoints, and artifacts move safely?
7. UI
Can another host render equivalent interaction and accessibility?
8. Operational
Can it be deployed, traced, secured, recovered, and audited elsewhere?
Keep canonical identity, task, commerce, authorization, and evidence models inside the enterprise boundary. Treat protocols as versioned adapters. Preserve protocol-native envelopes alongside normalized data where audit or dispute reconstruction matters.
Enterprise reference architecture
The model separates protocol handling from authorization, canonical domains, execution, and evidence.
Reversible decisions
Protocol adapter, SDK, host, renderer, facilitator, and model provider should remain replaceable.
Hard-to-reverse decisions
Canonical data semantics, identity boundaries, evidence retention, and external contracts require stronger design review.
Success criteria
Conformance, zero silent semantic loss, complete trace continuity, bounded authorization, deterministic recovery, and measured interoperability.
Agent transaction model
Machine commerce is a sequence of independently governed states, not one payment call.
Controls before execution
- Merchant and product binding
- Spend, purpose, geography, and time constraints
- Fresh inventory and price validation
- Sanctions, fraud, and policy evaluation
- Human approval for material changes
Controls after execution
- Consume-once authorization state
- Idempotent order and payment processing
- Receipt and fulfillment correlation
- Refund, cancellation, and dispute handling
- Evidence retention and privacy limits
Identity and delegated authority
Never use one token or signature as evidence for every actor and decision.
User principal
Who requested or approved the outcome?
Agent principal
Which agent software or operator produced the action?
Workload principal
Which runtime, service, or deployment sent the request?
Delegation
What exact authority, purpose, limits, audience, and duration were granted?
Use OAuth/OIDC for delegated identity, workload identity or mTLS for services, short-lived audience-restricted credentials, proof-of-possession where risk justifies it, and an external PDP for current authorization. Treat agent-specific IETF drafts as watch items until standards status and implementation converge. S32S44S45
What a request signature proves
Integrity, freshness, and possession of a signing key under the selected verification model.
What it does not prove
The user intended the result, the agent interpreted correctly, content was safe, or policy still permits execution.
Required correlation
Bind principal, task, merchant, resource, amount, policy decision, approval, and resulting artifact or receipt.
Governance and enforcement
Protocol conformance, organizational governance, security guidance, contracts, and law operate on different control planes.
| Layer | Primary purpose | How it is enforced | What it does not do |
|---|---|---|---|
| Protocol conformance | Compatible messages, states, and required behavior. | SDK tests, TCKs, certification, platform onboarding, integration contracts. | Does not establish legal or ethical acceptability. |
| ISO/IEC 42001 | AI management system, ownership, lifecycle controls, continuous improvement. | Certification, procurement, customer requirements, internal governance. | Does not define protocol messages. |
| NIST AI RMF | Govern, map, measure, and manage AI risk. | Voluntary adoption, sector expectations, internal control design. | Is not a certification by itself. |
| OWASP Agentic Top 10 | Threat baseline for agent goal hijacking, tool misuse, privilege, memory, supply chain, and cascading failure. | Threat models, architecture reviews, red teams, release gates. | Does not replace organizational governance. |
| Law and regulation | Legal duties by role, risk, sector, geography, and processing purpose. | Regulators, courts, contracts, and statutory remedies. | Protocol compatibility does not imply compliance. |
The EU AI Act applicability timeline is phased and subject to active implementation and political change. Validate the current official timeline and the system’s actual role and risk category before making a legal conclusion. S56
AEO, GEO, SEO, and OKR
These terms belong in the guide because they are commonly mixed with technical standards, even though they are practices rather than agent protocols.
Content discoverability
AEO and GEO
Answer Engine Optimization and Generative Engine Optimization are industry practices. There is no universal normative protocol, certification, or guaranteed markup. Search-platform guidance continues to emphasize crawlability, useful original content, semantic structure, accurate structured data, provenance, and established SEO fundamentals. S57S58S59
llms.txt is a proposed convention, not access control, ranking control, or a replacement for robots.txt. S60
Management system
OKR
Objectives and Key Results is a goal-setting method. It is governed through organizational ownership, cadence, scoring, and review—not through a standards body. S62
Example objective: Make agent actions trustworthy and portable.
Example key result: 100% of consequential actions carry a current policy decision and correlated evidence record.
Hands-on learning path
The labs progress from wire mechanics to cross-protocol architecture, identity, commerce, and adversarial validation.
Local TypeScript MCP server
Expose read-only search and retrieval tools plus one approval-gated write tool.
- Run through standard I/O.
- Validate with MCP Inspector.
- Reject invalid schema deterministically.
- Keep secrets outside model-visible metadata.
Remote governed MCP
Move the same server to HTTP behind an identity-aware gateway.
- Add OAuth/OIDC and workload identity.
- Use an external PDP.
- Run stable and release-candidate conformance.
- Propagate trace, deadline, and idempotency context.
Mixed-language A2A chain
Use two SDK languages and at least two transport bindings.
- Discover through Agent Card.
- Stream progress and final artifacts.
- Test input-required, cancellation, resubscription, and duplicate delivery.
- Run TCK and ITK.
Three UI representations
Implement the same approval workflow through AG-UI, A2UI, and MCP Apps.
- Compare accessibility and mobile behavior.
- Inject tool failures and reconnection.
- Measure host-specific behavior.
- Record catalog and capability fingerprints.
Commerce adapter contract
Create a canonical checkout model and map both ACP and UCP into it.
- Preserve amount, merchant, product, fulfillment, cancellation, and evidence.
- Run UCP conformance.
- Compile ACP schemas and validate examples.
- Emit an explicit loss report.
x402 and MPP endpoint
Protect one resource with both payment-negotiation protocols.
- Use test assets or test payment configuration.
- Add nonce, expiration, replay protection, resource binding, and receipt.
- Test timeout after settlement.
- Design refund and reconciliation paths.
Delegated transaction authority
Generate and verify AP2 or Verifiable Intent evidence.
- Bind merchant, amount, purpose, and expiry.
- Attempt replay and merchant substitution.
- Change the cart after approval.
- Require runtime policy re-evaluation.
Bridge-fidelity harness
Build a golden corpus crossing MCP, A2A, AG-UI, and an internal event model.
- Track every invariant defined in this guide.
- Fail on silent downgrade.
- Generate machine-readable compatibility reports.
- Retain raw source envelopes.
UTCP versus MCP
Expose the same OpenAPI service through direct native invocation and an MCP wrapper.
- Compare latency and infrastructure.
- Compare credential and egress control.
- Compare observability and approval semantics.
- Document where each boundary is preferable.
Acronym field guide
Use this index to distinguish architectural patterns, governance terms, security mechanisms, and protocols.
| Acronym | Meaning | Type | Use or status |
|---|---|---|---|
| AI | Artificial Intelligence | Umbrella discipline | No single specification |
| ML | Machine Learning | Discipline | Methods and model families |
| DL | Deep Learning | Technique family | Neural-network training |
| GenAI | Generative AI | System category | Produces content or structured outputs |
| FM | Foundation Model | Model category | General-purpose pretrained model |
| LLM | Large Language Model | Model category | Language-centric foundation model |
| SLM | Small Language Model | Relative category | Resource-constrained or specialized model |
| VLM | Vision-Language Model | Multimodal model | Joint vision and language processing |
| MoE | Mixture of Experts | Architecture | Routes tokens to specialist subnetworks |
| RAG | Retrieval-Augmented Generation | Architecture pattern | Retrieval grounds generation |
| GraphRAG | Graph-assisted RAG | Architecture family | Graph relationships augment retrieval |
| CAG | Cache-Augmented Generation | Technique label | Context/cache preloading; usage varies |
| ICL | In-Context Learning | Model behavior | Learns from prompt examples without weight changes |
| SFT | Supervised Fine-Tuning | Training method | Learns from labeled examples |
| RLHF | Reinforcement Learning from Human Feedback | Alignment method | Optimizes preferences from human feedback |
| RLAIF | Reinforcement Learning from AI Feedback | Alignment method | Uses AI-generated preference feedback |
| DPO | Direct Preference Optimization | Training method | Directly optimizes pairwise preferences |
| CoT | Chain of Thought | Reasoning concept | Intermediate reasoning; not a protocol |
| ReAct | Reasoning and Acting | Agent pattern | Interleaves reasoning and tool actions |
| HITL | Human in the Loop | Control pattern | Human participates in execution |
| HOTL | Human on the Loop | Oversight pattern | Human supervises and can intervene |
| RAI | Responsible AI | Governance discipline | Risk, fairness, safety, accountability |
| XAI | Explainable AI | Engineering/research discipline | Makes system behavior interpretable |
| PII | Personally Identifiable Information | Data classification | Privacy and security controls |
| KPI | Key Performance Indicator | Measurement | Tracks operational or business performance |
| OKR | Objectives and Key Results | Management method | Qualitative objective plus measurable outcomes |
| SLI | Service Level Indicator | Reliability metric | Observed service behavior |
| SLO | Service Level Objective | Reliability target | Target range for an SLI |
| SLA | Service Level Agreement | Contract | External commitment and remedies |
| AIMS | AI Management System | Management-system concept | ISO/IEC 42001 organizational control system |
| RMF | Risk Management Framework | Governance framework | Structured risk lifecycle |
| OAuth | Open Authorization | Authorization standard | Delegated access |
| OIDC | OpenID Connect | Identity standard | Authentication and identity over OAuth |
| JWT | JSON Web Token | Token format | Signed or encrypted claims container |
| JWS | JSON Web Signature | Signature format | Integrity and signer evidence |
| JWK | JSON Web Key | Key representation | Portable cryptographic key data |
| JWKS | JSON Web Key Set | Key discovery | Publishes multiple JWKs |
| mTLS | Mutual Transport Layer Security | Authentication | Both peers authenticate with certificates |
| DPoP | Demonstrating Proof of Possession | OAuth security | Sender-constrains tokens |
| PDP | Policy Decision Point | Authorization role | Computes allow/deny and obligations |
| PEP | Policy Enforcement Point | Authorization role | Enforces a policy decision |
| PAM | Privileged Access Management | Security discipline | Controls elevated access |
| KYC | Know Your Customer | Compliance process | Customer identity verification |
| AML | Anti-Money Laundering | Compliance discipline | Detects and prevents illicit finance |
| AEO | Answer Engine Optimization | Content practice | No normative protocol |
| GEO | Generative Engine Optimization | Content practice | Industry term; no universal standard |
| SEO | Search Engine Optimization | Content and technical practice | Search discovery and usability |
| C2PA | Coalition for Content Provenance and Authenticity | Provenance specification | Signed content credentials |
| ONNX | Open Neural Network Exchange | Model interchange | Graphs, operators, and model serialization |
| OASF | Open Agentic Schema Framework | Discovery schema | Agent metadata and taxonomy |
| OTel | OpenTelemetry | Observability standard | Traces, metrics, logs, semantic conventions |
Standards watchlist
These triggers should cause the guide, architecture decisions, or compatibility matrices to be re-evaluated.
MCP 2026-07-28 final publication
Re-run conformance, review breaking changes, extension negotiation, authorization, deprecated capabilities, and SDK support. S02
Neutral governance consolidation
Track Linux Foundation Agentic AI Foundation projects and whether protocol governance, test assets, registries, or shared vocabularies converge. S63
The likely durable outcome is a protocol suite resembling the web: multiple application protocols composed over shared identity, authorization, observability, and governance foundations. This is an analysis, not an established fact.
Provenance and update model
This section makes the guide maintainable as specifications, repositories, and legal timelines evolve.
Evidence priority
Normative specification → official repository and conformance tooling → official SDK and reference implementation → vendor operational documentation → implementation issue evidence → independent analysis.
Claim types
Fact reports a source. Analysis synthesizes multiple sources. Recommendation selects a course of action. Projection describes a plausible future and is explicitly marked.
Research cutoff
All “current” statements are bounded to 2026-07-23. Future-dated releases are described as candidates or scheduled events, not completed facts.
Update triggers
New stable versions, governance transfer, conformance certification, independent implementation, security disclosure, major deprecation, or changed legal applicability.
Validation rule
Do not update only the narrative. Update the source registry, evidence ledger, adoption matrix, compatibility claims, and changelog together.
Known limitations
Public code does not prove private production volume, correctness, security, or complete interoperability. GitHub activity is evidence of implementation, not certification.
Evidence ledger format
The complete machine-readable ledger is embedded in this file as <script id="evidence-ledger" type="application/json">. Each record contains a claim identifier, type, assertion, supporting source IDs, verification date, status, and update trigger.
Release metadata and changelog
Document version: 1.0.0
Research cutoff: 2026-07-23
Source count: 63
Distribution: self-contained HTML; no external runtime assets.
— v1.0.0: consolidated acronym landscape, protocol briefs, public-code validation, enterprise stance, bridge-fidelity model, labs, source registry, and evidence ledger.
Source registry
Direct links are retained so future reviews can verify the exact specification, repository, conformance suite, or official guidance used.
-
S01MCP specification 2025-11-25 Model Context Protocol · Specification · accessed 2026-07-23
-
S022026-07-28 MCP Specification Release Candidate Model Context Protocol · Release candidate / roadmap · accessed 2026-07-23
-
S03MCP GitHub organization and official SDKs Model Context Protocol · Implementation ecosystem · accessed 2026-07-23
-
S04MCP Inspector Model Context Protocol · Developer tooling · accessed 2026-07-23
-
S05MCP Conformance Tests Model Context Protocol · Conformance tooling · accessed 2026-07-23
-
S06MCP Apps specification and SDK Model Context Protocol · UI extension · accessed 2026-07-23
-
S07MCP Apps stable extension 2026-01-26 Model Context Protocol · Specification · accessed 2026-07-23
-
S08A2A protocol repository Linux Foundation A2A project · Specification and implementation · accessed 2026-07-23
-
S09A2A 1.0 specification Linux Foundation A2A project · Specification · accessed 2026-07-23
-
S10A2A 1.0 announcement Linux Foundation A2A project · Release information · accessed 2026-07-23
-
S11A2A public samples Linux Foundation A2A project · Reference implementations · accessed 2026-07-23
-
S12A2A Technology Compatibility Kit Linux Foundation A2A project · Conformance tooling · accessed 2026-07-23
-
S13A2A Integration Testing Kit Linux Foundation A2A project · Cross-SDK interoperability · accessed 2026-07-23
-
S14Agent Client Protocol ACP community / Zed ecosystem · Specification and SDKs · accessed 2026-07-23
-
S15AG-UI protocol AG-UI project · Reference implementation and adapters · accessed 2026-07-23
-
S16AG-UI documentation AG-UI project · Documentation · accessed 2026-07-23
-
S17A2UI Google A2UI project · Specification and renderers · accessed 2026-07-23
-
S18A2UI repository Google · Implementation · accessed 2026-07-23
-
S19WebMCP Community Group draft W3C Web Machine Learning Community Group · Draft specification · accessed 2026-07-23
-
S20WebMCP repository W3C Web Machine Learning Community Group · Experimental implementation · accessed 2026-07-23
-
S21Agentic Commerce Protocol repository OpenAI and Stripe · Beta specification · accessed 2026-07-23
-
S22Universal Commerce Protocol UCP project · Specification · accessed 2026-07-23
-
S23UCP conformance suite UCP project · Conformance tooling · accessed 2026-07-23
-
S24UCP JavaScript SDK UCP project · SDK · accessed 2026-07-23
-
S25UCP Python SDK UCP project · SDK · accessed 2026-07-23
-
S26Agent Payments Protocol Google Agentic Commerce · Specification, SDK, and samples · accessed 2026-07-23
-
S27x402 protocol x402 Foundation · Specification and SDKs · accessed 2026-07-23
-
S28A2A x402 extension Google Agentic Commerce · Protocol extension · accessed 2026-07-23
-
S29Machine Payments Protocol specifications Tempo and Stripe · Specification and SDK links · accessed 2026-07-23
-
S30Machine Payments Protocol announcement Stripe · Release information · accessed 2026-07-23
-
S31Stripe machine payments documentation Stripe · Developer documentation · accessed 2026-07-23
-
S32AuthZEN OpenID Foundation · Authorization API and interoperability · accessed 2026-07-23
-
S33Trusted Agent Protocol Visa · Reference implementation · accessed 2026-07-23
-
S34Verifiable Intent Mastercard-led project · Draft specification and code · accessed 2026-07-23
-
S35Open Agentic Schema Framework AGNTCY · Schema and tooling · accessed 2026-07-23
-
S36AGNTCY Directory AGNTCY · Agent discovery infrastructure · accessed 2026-07-23
-
S37AGNTCY Agent Connect Protocol archive AGNTCY · Archived protocol · accessed 2026-07-23
-
S38Open Agent Specification Oracle · Interchange specification and runtime · accessed 2026-07-23
-
S39Agent Skills specification Agent Skills project · Packaging convention · accessed 2026-07-23
-
S40Agent Skills repository Agent Skills project · Tools and implementation · accessed 2026-07-23
-
S41AGENTS.md Open agent ecosystem · Repository instruction convention · accessed 2026-07-23
-
S42Universal Tool Calling Protocol RFC UTCP project · Draft specification · accessed 2026-07-23
-
S43Web Bot Auth Cloudflare · Identity implementation guidance · accessed 2026-07-23
-
S44AI Agent Authentication and Authorization draft-02 IETF Datatracker · Individual Internet-Draft · accessed 2026-07-23
-
S45Agent Authorization Profile for OAuth 2.0 IETF Datatracker · Internet-Draft · accessed 2026-07-23
-
S46ERC-8004 Ethereum Improvement Proposals · Draft trust registry standard · accessed 2026-07-23
-
S47ERC-8004 contracts ERC-8004 project · Reference contracts · accessed 2026-07-23
-
S48OpenTelemetry MCP semantic attributes OpenTelemetry · Observability conventions · accessed 2026-07-23
-
S49OpenTelemetry GenAI semantic attributes OpenTelemetry · Observability conventions · accessed 2026-07-23
-
S50C2PA Technical Specification 2.4 C2PA · Provenance specification · accessed 2026-07-23
-
S51ONNX API and version documentation ONNX · Model interchange specification · accessed 2026-07-23
-
S52ISO/IEC 42001 ISO · Certifiable management-system standard · accessed 2026-07-23
-
S53NIST AI Risk Management Framework NIST · Governance framework · accessed 2026-07-23
-
S54NIST Generative AI Profile NIST · Risk profile · accessed 2026-07-23
-
S55OWASP Top 10 for Agentic Applications 2026 OWASP · Security guidance · accessed 2026-07-23
-
S56EU AI Act policy and implementation timeline European Commission · Regulation guidance · accessed 2026-07-23
-
S57AI optimization guidance Google Search Central · Search guidance · accessed 2026-07-23
-
S58AI features and website guidance Google Search Central · Search guidance · accessed 2026-07-23
-
S59Schema.org releases Schema.org · Structured-data vocabulary · accessed 2026-07-23
-
S60llms.txt proposal llms.txt community · Proposed convention · accessed 2026-07-23
-
S61NLWeb Microsoft · Open project and reference implementation · accessed 2026-07-23
-
S62Set goals with OKRs Google re:Work · Management practice · accessed 2026-07-23
-
S63Agentic AI Foundation formation Linux Foundation · Governance development · accessed 2026-07-23