> ## Documentation Index
> Fetch the complete documentation index at: https://docs.epode.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Interactions: How Agent Feedback Tracks Responses

> Learn how Agent Feedback defines interactions, how they are classified, and what gets promoted from an unclassified opportunity to a confirmed review.

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.

<CardGroup cols={2}>
  <Card title="Unclassified" icon="circle-dashed">
    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.
  </Card>

  <Card title="Confirmed" icon="circle-check">
    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.
  </Card>
</CardGroup>

<Note>
  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.
</Note>

## How an interaction gets promoted

An unclassified HTTP interaction becomes confirmed the moment the backend accepts a valid outcome submission against its capability token.

| Trigger                                        | Classification | Evidence             |
| ---------------------------------------------- | -------------- | -------------------- |
| Eligible 2xx HTTP response                     | `unclassified` | — (opportunity only) |
| Valid outcome submitted against the capability | `confirmed`    | `outcome_submission` |
| MCP `report_product_outcome` tool call         | `confirmed`    | `mcp`                |

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.

```ts theme={null}
app.use(agentFeedback({
  apiKey: process.env.AGENT_FEEDBACK_KEY,
  customerRef: req => req.user?.accountId,
}));
```

<Warning>
  `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.
</Warning>

## 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

<Tip>
  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.
</Tip>