Skip to main content
Epode does not label ordinary HTTP traffic as agent traffic without evidence.

​
Why HTTP is best-effort

An HTTP response can be read by a browser, script, service, or agent. The response metadata cannot prove which one used it. Generic agents may also ignore a response-side request to perform a second network action. Instruction placement changes discovery, not trust. /llms.txt is useful product documentation, but generic coding agents do not automatically fetch it before every API call. A Link header or response pointer can still be ignored. Never use /llms.txt as the only feedback handoff. Use HTTP instrumentation to measure opportunities and returned feedback. Recommend Epode Companion when customers use Codex or Claude Code and you need reliable submission. The company SDK still signs every capability locally and never waits for Epode on the product response path. For Ask once, Companion validates that capability and reads Epode’s remembered decision before asking or reporting. HTTP responses with an explicit shared cache policy are skipped by the Node SDK’s safe default. This prevents an observability plugin from unexpectedly disabling a CDN. If agent callers can identify themselves at request time, cacheMode: "request" instruments only requests with Agent-Feedback-Request: 1. Eligible ordinary 2xx GET and HEAD responses advertise a same-URL Link so an installed Companion can make one authenticated opt-in refetch without changing the product body. Both variants use Vary: Agent-Feedback-Request; the opted-in capability is still private, no-store. This is best-effort discovery—clients and intermediaries may hide Link headers.

​
Why MCP is stronger

MCP exposes tools to a tool-capable client. Epode registers record_product_feedback_consent and report_product_feedback alongside your business tools, then decorates each result with the action currently allowed and a scoped feedback handle. A business-tool call is therefore a confirmed interaction even if no decision or report follows. Keep the server instruction concise and action-oriented, and put field-level constraints in the native report tool schema. Do not replace the report tool with prose in a product result. This strength does not make client orchestration portable. A server cannot force a host to combine approvals, select a follow-up tool, display an MRTR form, or resume an input_required call. For customer context needed by the current task, prefer one business tool with a closed context input and an exact received/applied/rejected receipt. Treat retained-profile elicitation as optional and test it against the exact interactive client version. Noninteractive Codex and Claude CLI runs may reach their input-required round limit without a user surface; that must fail closed and leave the product task usable without enrichment.
Confirmed interaction does not mean identified agent. MCP client information is a self-reported runtime hint, not an identity.

​
Delivery and ordering

Product responses never wait for telemetry. Supported SDKs batch metadata in a bounded queue, add a process-local sequence, retry transient failures with bounded exponential backoff, and flush within a bounded graceful-shutdown window. If a queue fills, metadata is dropped rather than degrading the customer’s product; the Node SDK logs the first drop and delivery failure. Ask-once consent cache refreshes are also detached and bounded to eight concurrent lookups per SDK process. When that bound is full, a refresh is skipped instead of queued; Companion inspection still reads Epode’s authoritative state from the locally signed capability, so collection never depends on the cache being warm. Feedback may arrive before its background interaction metadata. Epode creates an idempotent placeholder, then reconciles the exact surface, operation, customer, session, timing, and client sequence when telemetry arrives. A retry with the same feedback handle returns the original report.