Skip to main content
Verification should test the whole loop, not only whether a field appeared in one response. Setup reports three independent milestones: First opportunity, First confirmed interaction, and First report. Do not treat the first as proof of the other two.

​
HTTP and server-rendered HTML

1

Check the product result

Confirm the response status, original fields/body, cache behavior, and latency remain correct.
2

Check the handoff

Find _agentFeedback, the HTML script, or the Agent-Feedback header. Confirm the action URL is HTTPS, its capability starts with afr2_, and no af_live_ product key appears. A consent_required handoff has only requiredAction.submitDecision; a feedback_ready handoff has submit.
3

Check the evidence state

The response creates an opportunity, not a confirmed interaction.
4

Follow the current action

In Never ask, submit one bounded report. In an ask mode, use an actual explicit user decision: submit only approved or declined, and submit a report only when approval returns a separate feedback_ready action. Confirm the linked interaction becomes confirmed and any approved report is visible.
5

Check idempotency

Submit a contradictory duplicate and confirm Epode returns the original accepted report.
For Node:
The doctor validates response injection, the trusted Epode origin, and the scoped capability without creating a report. It proves the company-side handoff only. In an ask mode it validates the answer-first contract but never fabricates user approval. Use a real customer-agent task to prove confirmation and the first report. For a request-mode cached route, inspect the opted-in variant explicitly:
For an authenticated product route, add only that product’s test authentication header. Never send AGENT_FEEDBACK_KEY to the product URL or put it in a query string. Confirm the ordinary authenticated request still works before checking the feedback handoff.

​
MCP

Call server/discover, tools/list, and one normal product tool. Confirm the product tool creates a confirmed MCP interaction even before feedback returns. For consent_required, ask the exact question and call record_product_feedback_consent; call report_product_feedback only when the result or approved decision returns feedback_ready. If the feedback tool returns retryable: true, retry it once with the identical handle and report. A second successful response must resolve to the same stored report.

​
Failure tests

  • Disable Epode connectivity and confirm your product response still succeeds promptly.
  • Send an expired or forged capability and expect rejection.
  • Include a prompt, transcript, credential, raw payload, or unknown field and expect rejection.
  • Test an excluded route, error, stream, binary, JSON array, and scalar response.
  • Gracefully stop the process and check whether the SDK reports any terminal telemetry flush error.
  • For serverless or edge isolates, verify the platform lifecycle hook keeps bounded telemetry work alive; a frozen isolate may drop an opportunity even though feedback submission still works.

​
Recover by milestone

  • No opportunity: verify the current write key is deployed, startup has no key-validation warning, the exact path matches include, the response is an eligible 2xx result, and AGENT_FEEDBACK_ENABLED is not false.
  • Opportunity but no confirmation: the company-side HTTP integration works. Exercise the response with a feedback-aware runtime; generic HTTP clients may ignore the action. An MCP product-tool call should confirm immediately, so check protocol/version/header validation if it does not.
  • Confirmed but no report: follow only the action returned for the current state. Ask modes require a real user decision, and approval returns a separate feedback_ready action before reporting.