Skip to main content
An interaction is a single, instrumented product response that Agent Feedback has observed and assigned a unique ID. Every time your middleware intercepts an eligible response, it creates an interaction — initially treated as an opportunity — and embeds the compact feedback contract before the response leaves your server. That interaction record lives independently of whether any agent ever submits an outcome.

​
Two classifications

Interactions start in one of two states depending on the product surface they came from. Once feedback is received, an unclassified opportunity can be promoted to confirmed.

Unclassified

Applies to HTTP JSON, HTML, and header responses. These are opportunities: the feedback contract is present and valid, but Agent Feedback cannot verify whether an agent consumed or acted on it. Generic agents that do not implement the protocol may ignore the contract entirely. A feedback-aware runtime can still submit deterministically, which promotes the interaction to confirmed.

Confirmed

Applies to MCP tool calls and to any HTTP interaction where a valid outcome is later submitted. Confirmed interactions have explicit, protocol-backed evidence of agent engagement and are the authoritative signal in your dashboard metrics.
Best-effort collection over HTTP is genuinely useful — most agents that read and act on a product response are also capable of following the submit instructions. Confirmed interactions are simply the highest-fidelity signal.

​
How an interaction gets promoted

An unclassified HTTP interaction becomes confirmed the moment the backend accepts a valid outcome submission against its capability token. MCP tool calls skip the unclassified state entirely. Because the MCP protocol exposes report_product_outcome as an explicit registered tool, the interaction is confirmed immediately with mcp evidence.

​
Customer references

You can pass an optional customerRef to any SDK middleware. This is an opaque string that your own code supplies — for example, an account ID from your auth layer — and it scopes that interaction to one of your customers in the dashboard.
customerRef is your reference, not the agent’s identity. Agent Feedback never attempts to identify the agent. Do not pass any value derived from agent-supplied input.

​
Sessions

Sessions let you group a sequence of related interactions into a single continuity unit — for example, a multi-step task a customer agent performs across several requests. Agent Feedback only creates or joins a session when it can verify the continuity claim through one of the accepted proof methods:
  • Company-provided: your server explicitly supplies a sessionRef in the middleware options
  • MCP: the MCP protocol itself establishes session continuity
  • Signed continuation: a signed continuation token proves the request belongs to an existing session
Time-window grouping — inferring that two interactions belong together because they happened close in time — is never used. Every session association has explicit, verifiable provenance.

​
What you see in the dashboard

Each product scopes its own interaction list. For every product you can see:
  • Interaction count — total instrumented responses over the selected time window
  • Classification breakdown — the ratio of confirmed to unclassified interactions
  • Outcomes — success, partial, and failure tallies with note samples
  • Sessions — grouped continuity units with their constituent interactions
  • Per-product scoping — interactions never bleed across products or workspaces
Drill into any individual interaction to see its surface type, operation, status code, duration, customer reference, session membership, and the full outcome review if one was submitted.