Skip to main content
When a product is instrumented with Agent Feedback, every eligible successful response carries a compact, self-contained feedback contract. Your agent runtime does not need to be pre-configured with product-specific knowledge — the contract tells you exactly where to submit an outcome, how to authorize the request, and when to do it. This page explains the three places that contract can appear, how to parse it reliably, and what the key fields mean before you submit.

Where the contract appears

Agent Feedback embeds the same feedback envelope in one of three locations depending on the response’s content type. Check them in order: JSON body first, HTML body second, header last.

1. JSON responses — _agentFeedback field

For application/json responses whose top-level body is an object, the SDK appends _agentFeedback directly to that object without changing any existing fields.

2. HTML responses — <script id="agent-feedback"> tag

For text/html responses, the SDK injects the same JSON object into a <script> tag placed before </head> or </body>.

3. Header fallback — Agent-Feedback header

For arrays, scalars, and other response types where the body cannot be mutated safely, the SDK base64url-encodes the JSON envelope and delivers it in the Agent-Feedback response header, accompanied by a Link header pointing to the discovery document.

Parsing the contract

The agent helper functions handle all three locations for you. Pass the response object and the already-parsed body (JSON value or raw text string), and the function returns the envelope if one is present and valid, or undefined/None/nil otherwise.
feedbackFromResponse accepts any object implementing Pick<Response, "headers"> and a body of unknown type. It checks the JSON _agentFeedback field first, then an HTML <script id="agent-feedback"> tag, then the Agent-Feedback header.

Key contract fields

Understanding these fields helps you decide when and how to submit.
string
Always best_effort_without_agent_adapter for HTTP and HTML responses. Generic agents that treat response-body instructions as untrusted may not submit at all, so actual submission rates depend on whether the runtime is feedback-aware. Using the helper functions makes submission deterministic regardless of LLM behavior.
string
Always after_outcome_known_before_final_response. Submit the outcome after your agent completes its product task and knows whether it succeeded — but before delivering the final answer back to the user. This ordering is important: once you have given the user their answer, the moment for feedback has passed.
string (ISO 8601)
Capability tokens expire approximately two hours after issuance. If your agent workflow takes longer than two hours from the moment of the product response to outcome submission, the submission will be rejected as expired. Submit promptly.
string
The literal value is "Never include prompts, transcripts, credentials, personal data, or raw product content." This is a binding constraint on the note field you send. The contract contains no user data itself — keep it that way in your submission.
Every instrumented response sets Cache-Control: private, no-store because each capability token is unique to that interaction. Do not cache instrumented responses or share them across agent sessions.
If feedbackFromResponse returns undefined or None, the product response was not instrumented or did not include a valid contract. This is normal for responses that were excluded from instrumentation (errors, redirects, health endpoints, binary bodies). Continue with your product task as usual.