Protocol overview

The Epode protocol is deliberately small enough to implement with standard HTTP, JSON, HMAC-SHA256, UUID, and base64url libraries.

Public discovery

GET https://app.tryintents.com/.well-known/agent-feedback-v1.json

The discovery document publishes supported feedback modes, report fields, MCP binding information, privacy rules, and downloadable SDK/protocol artifacts.

Product-authenticated telemetry

POST https://app.tryintents.com/api/v2/telemetry/batches
Authorization: Bearer af_live_...
Content-Type: application/json

Only company-side SDKs use the product key. Telemetry must be queued and sent off the primary response path. For durable Ask once, the company-side adapter also uses the product key for a bounded state lookup:

POST https://app.tryintents.com/api/v2/consent/state
Authorization: Bearer af_live_...
Content-Type: application/json

{"subject":"afsub1_..."}

The subject is derived from a stable opaque customerRef. The raw reference is not sent in this consent-state lookup and never appears in the agent-facing feedback envelope. When customerRef is configured, opportunity telemetry separately sends and stores that opaque value so the dashboard can group product usage by customer. Use an internal non-personal account or tenant ID, never a name or email address.

How the `afsub1_` subject is derived

Per the protocol specification (also inside the downloadable protocol bundle below):

subject = "afsub1_" + base64url(
  HMAC-SHA256(
    SHA256("epode-consent-scope:" + consent_scope),
    "customer-ref:" + customerRef
  )
)

The HMAC key is the SHA-256 hash of the product’s consent scope, so the subject stays stable across product-key rotation without ever exposing the raw customer reference. conformance.json in the protocol bundle contains a deterministic signing vector; older conformance keys without an explicit consent scope use the key ID as their scope.

Capability-authenticated decision

An unresolved ask-mode interaction carries no report schema. After asking the exact returned question, the customer’s agent submits only the explicit decision:

POST https://app.tryintents.com/api/v2/consent/decisions
Authorization: Bearer afr2_...
Content-Type: application/json

{"decision":"approved"}

Approval returns a separate report action. Refusal returns no action, and silence stores no decision.

Capability-authenticated report

POST https://app.tryintents.com/api/v2/reports
Authorization: Bearer afr2_...
Content-Type: application/json

The customer’s agent receives only a short-lived interaction capability. It never receives the company key.

Downloadable conformance bundle

curl -fsSLO https://app.tryintents.com/static/agent-feedback-protocol-v1-0.5.28.zip
unzip agent-feedback-protocol-v1-0.5.28.zip

Use the included schemas and signing vector as the source of truth for a new adapter.

​Public discovery

​Product-authenticated telemetry

​How the afsub1_ subject is derived

​Capability-authenticated decision

​Capability-authenticated report

​Downloadable conformance bundle