Agent Standards Watch — 2026-07-26

The AgentAtlas Standards Watch is a weekly, source-linked briefing for people shipping AI products. This edition covers verified records for interoperability, portable Skills, commerce, payments, specification-driven delivery, agent runtimes, and telemetry semantics. It does not treat social engagement, commentary, or a repository timestamp as proof of adoption. The goal is to separate stable releases from previews and maintenance activity so teams can decide what deserves implementation work.

Together, the sources cover a broader operating surface: how teams define work, give agents capabilities, connect systems, authorize transactions, run workflows, and observe results. These layers do not share maturity, release cadence, or compatibility. Pin exact versions, record the evidence behind each decision, and evaluate upgrades in a reversible environment.

1. [Model Context Protocol](https://github.com/modelcontextprotocol/modelcontextprotocol/releases/tag/2025-11-25)

Verified from Model Context Protocol on May 29, 2026. The official release record identifies **2025-11-25** as stable and **2026-07-28-RC** as a preview, not the stable specification. For teams evaluating MCP interoperability, the practical signal is that the stable specification and the release candidate are separate compatibility targets.

For Model Context Protocol, teams should implement and advertise the stable protocol version they have actually tested. Release candidates are useful for compatibility trials, but production claims should stay tied to stable behavior until the maintainers publish a final release.

**A practical evaluation:** Record the negotiated protocol version, exercise initialization and one read-only tool call against the stable specification, then run any release-candidate work in a separate compatibility suite. Review the [official specification](https://modelcontextprotocol.io/specification/) before changing a production implementation.

2. [Agent2Agent Protocol](https://github.com/a2aproject/A2A/releases/tag/v1.0.1)

Verified from Agent2Agent Protocol on May 28, 2026. The official release record identifies **v1.0.1** as stable. For teams evaluating agent-to-agent interoperability, the practical signal is that A2A has a current stable 1.0-series release that teams can pin instead of coding against an unspecified moving target.

For Agent2Agent Protocol, agent-to-agent integrations need an explicit contract for discovery, task state, messages, artifacts, authentication, and failure handling. Pinning the stable release makes conformance tests and upgrade decisions reproducible.

**A practical evaluation:** Validate one end-to-end task against the stable specification, including cancellation and an error path, and retain the exchanged task states as evidence. Review the [official specification](https://a2a-protocol.org/latest/specification/) before changing a production implementation.

3. [Agent Skills](https://github.com/agentskills/agentskills/commit/38a2ff82958afee88dadf4831509e6f7e9d8ef4e)

Verified from Agent Skills on Jul 10, 2026. The official repository is at revision **38a2ff82958a**; activity shows maintenance, not necessarily a specification change. For teams evaluating portable agent capabilities, the practical signal is that portable skill packages are being actively maintained, while repository activity alone does not establish a new compatibility promise.

For Agent Skills, a useful skill should make its trigger, instructions, dependencies, and expected result inspectable. Teams should version the package, review executable assets, and test the same skill across supported agent environments before calling it portable.

**A practical evaluation:** Install one narrowly scoped skill in an isolated project, inspect every bundled instruction and script, and verify its output and permission boundary in each supported host. Review the [official specification](https://agentskills.io/specification) before changing a production implementation.

4. [Universal Commerce Protocol](https://github.com/Universal-Commerce-Protocol/ucp/commit/20bb02d1e089e2ddcf9f33509a38b7106c237c67)

Verified from Universal Commerce Protocol on Jul 24, 2026. The official repository is at revision **20bb02d1e089**; activity shows maintenance, not necessarily a specification change. For teams evaluating agentic commerce, the practical signal is that commerce workflows now have a dedicated protocol surface, but an active repository is not evidence that a particular merchant or platform supports it.

For Universal Commerce Protocol, commerce integrations must preserve authoritative product, price, availability, consent, order, and fulfillment state across system boundaries. Compatibility should be proven with the merchant's current implementation and documented extensions.

**A practical evaluation:** Run a sandbox purchase from discovery through order status, verify totals and consent at every boundary, then exercise inventory change, cancellation, and refund paths. Review the [official specification](https://ucp.dev/) before changing a production implementation.

5. [Agent Payments Protocol](https://github.com/google-agentic-commerce/AP2/commit/e1ea56db72a6385bce3e5c1112b3a56ce60acb43)

Verified from Agent Payments Protocol on Apr 29, 2026. The official repository is at revision **e1ea56db72a6**; activity shows maintenance, not necessarily a specification change. For teams evaluating agentic payments, the practical signal is that agent-initiated payment work requires explicit authorization evidence and auditable state transitions, regardless of protocol availability.

For Agent Payments Protocol, payment automation should separate shopping intent, purchase authorization, credentials, execution, and dispute evidence. A protocol can structure that exchange, but it does not replace payment-provider controls or local compliance review.

**A practical evaluation:** Use a sandbox to test an approved amount, a changed amount, an expired authorization, and a refund while confirming that every actor and state transition is auditable. Review the [official specification](https://ap2-protocol.org/) before changing a production implementation.

6. [GitHub Spec Kit](https://github.com/github/spec-kit/commit/c0fe0e43cd728ebc3dd1f714343f3921510a157f)

Verified from GitHub Spec Kit on Jul 24, 2026. The official repository is at revision **c0fe0e43cd72**; activity shows maintenance, not necessarily a specification change. For teams evaluating specification-driven delivery, the practical signal is that the maintained Spec Kit workflow gives teams an explicit path from specification to plan, tasks, and implementation, while a repository update alone does not prove that workflow changed.

For GitHub Spec Kit, specification-driven delivery should preserve traceability from user intent and constraints through technical decisions, bounded tasks, and acceptance evidence. The documents are useful only when they guide implementation and stay synchronized with verified outcomes.

**A practical evaluation:** Run one small feature through specification, planning, task decomposition, and implementation; require every task and acceptance check to trace back to a stated requirement. Review the [official specification](https://github.github.com/spec-kit/) before changing a production implementation.

7. [OpenAI Agents SDK](https://github.com/openai/openai-agents-python/commit/f663a06aea23c859be8e8555c005ac912bd58337)

Verified from OpenAI Agents SDK on Jul 26, 2026. The official repository is at revision **f663a06aea23**; activity shows maintenance, not necessarily a specification change. For teams evaluating agent runtime operations, the practical signal is that the official Agents SDK repository is actively maintained, while teams still need to verify sessions, approvals, tool behavior, and tracing against the exact revision they deploy.

For OpenAI Agents SDK, an agent runtime should make state, delegation, consequential tool calls, and execution traces inspectable. Repository activity is a prompt to rerun compatibility and safety tests, not evidence that a deployed integration remains correct.

**A practical evaluation:** Pin the evaluated SDK version and run one workflow that persists session state, pauses for approval before a write, resumes, and exposes the complete trace for review. Review the [official specification](https://openai.github.io/openai-agents-python/) before changing a production implementation.

8. [OpenTelemetry Semantic Conventions](https://github.com/open-telemetry/semantic-conventions/commit/0ca7fe5c0ebd5ce4d597c436dac3132db03aedd0)

Verified from OpenTelemetry Semantic Conventions on Jul 25, 2026. The official repository is at revision **0ca7fe5c0ebd**; activity shows maintenance, not necessarily a specification change. For teams evaluating telemetry semantics, the practical signal is that the OpenTelemetry conventions repository is actively maintained, so agent telemetry needs an explicit stability and upgrade policy rather than ad hoc field names.

For OpenTelemetry Semantic Conventions, shared semantic conventions make traces portable across instrumentation and observability backends. Teams should record which convention version they emit, avoid treating experimental fields as stable contracts, and validate sensitive attributes before export.

**A practical evaluation:** Capture one end-to-end agent trace, validate its span names and attributes against the convention version you support, and confirm that sensitive prompt or tool data is excluded or redacted. Review the [official specification](https://opentelemetry.io/docs/specs/semconv/) before changing a production implementation.

What to do with this week's signals

• Pin stable protocol versions in architecture decisions and dependency records.
• Test one real but reversible workflow instead of relying on a synthetic demo.
• Recheck the linked specification when the official monitor reports a material release or repository update.

Closing view

Dependable execution and clear evidence matter more than the number of protocols named on a landing page. Use these records as starting points, then validate decisions against your users, data, threat model, and operating constraints. The next watch publishes only after the same citation and quality gates pass.

Sources

• [modelcontextprotocol/modelcontextprotocol](https://github.com/modelcontextprotocol/modelcontextprotocol/releases/tag/2025-11-25) — 5/29/2026, 12:51:22 UTC
• [a2aproject/A2A](https://github.com/a2aproject/A2A/releases/tag/v1.0.1) — 5/28/2026, 11:34:36 UTC
• [agentskills/agentskills](https://github.com/agentskills/agentskills/commit/38a2ff82958afee88dadf4831509e6f7e9d8ef4e) — 7/10/2026, 00:11:48 UTC
• [Universal-Commerce-Protocol/ucp](https://github.com/Universal-Commerce-Protocol/ucp/commit/20bb02d1e089e2ddcf9f33509a38b7106c237c67) — 7/24/2026, 11:59:20 UTC
• [google-agentic-commerce/AP2](https://github.com/google-agentic-commerce/AP2/commit/e1ea56db72a6385bce3e5c1112b3a56ce60acb43) — 4/29/2026, 16:51:41 UTC
• [github/spec-kit](https://github.com/github/spec-kit/commit/c0fe0e43cd728ebc3dd1f714343f3921510a157f) — 7/24/2026, 20:42:56 UTC
• [openai/openai-agents-python](https://github.com/openai/openai-agents-python/commit/f663a06aea23c859be8e8555c005ac912bd58337) — 7/26/2026, 10:02:25 UTC
• [open-telemetry/semantic-conventions](https://github.com/open-telemetry/semantic-conventions/commit/0ca7fe5c0ebd5ce4d597c436dac3132db03aedd0) — 7/25/2026, 18:43:10 UTC