An agent protocol changed. What should you recheck?

A project announcement or code commit is a review trigger. It does not prove a released integration is compatible, secure or ready to accept payment.

协议更新痛点：看到新版本，不清楚自己的集成要改什么。先锁定实际版本、官方变更和验收条件，再运行任务证据与预算检查。

A small change review you can repeat

1. Record the exact version or commit your integration runs. Distinguish a repository commit from a tagged release.
2. Open the official source and identify the field, network, payment flow or proof interface that changed.
3. Mark whether the change is relevant to your implementation. Unknown is a valid result.
4. Recheck your explicit acceptance rules on representative cases. Keep old-version and new-version evidence separate.
5. Recalculate retry and fallback budgets if the failure path changed. Document the result and unresolved questions before rollout.

Read the official-source watch · x402 source repository

Use the tool matching the evidence you have

The protocol profiles are an editorial release snapshot. The live source watch does not silently update those reviewed definitions. Agent Evidence checks supplied records and denominators, not reviewer independence or answer truth.

What counts as a useful output?

A short review that names the affected version, the original source, the cases you reran and what remains unknown. Keep a report rather than a claim that “the protocol is now safe”. If the change does not affect your integration, record that conclusion with its reason.

Inspect conflicting-evidence examples · Run the same calculators through MCP

By the AGI Scorecard team. Method reviewed 19 September 2026. Examples are fictional; source updates have their own dates.