Skip to main content
The Epode Companion is the user-side reliability layer for HTTP APIs and websites. A company still integrates Epode into its own server. The Companion lets a customer agent recognize the returned feedback handle and use three fixed, privacy-bounded tools. You do not need the Companion when the company already exposes Epode through its own MCP server. Native MCP is the most deterministic path because the feedback tool is part of the product protocol.

​
What gets installed

One trusted plugin contains:
  • a skill that recognizes Epode metadata and keeps the user’s product answer first;
  • a local MCP helper with only inspect_product_feedback, record_product_feedback_consent, and submit_product_feedback;
  • a fixed destination of https://app.tryintents.com;
  • fixed outcome categories with no prompt, transcript, task, response, identity, or arbitrary text field.
There is no Epode account, product key, or per-company configuration for the user. Routine successful reports stay out of the user’s final answer unless they explicitly ask about feedback. Permission questions remain visible, and a relevant failure can still be disclosed.

​
Install for Codex

Start a fresh Codex task after installation.

​
Install for Claude Code

Start a fresh Claude Code session after installation.

​
What the user experiences

Installing the Companion opts the user into its bounded handling rules. It does not convert an Ask-once or Ask-every-time decision into approval. Silence and ambiguous replies are never approval. For HTTP products, the company SDK creates the receipt locally and never waits for Epode. The Companion must inspect that receipt before acting: Epode returns the current remembered state and the canonical product-specific question. This is what turns later Ask-once uses into silent reporting without putting a network dependency on the company’s response. The user can later explicitly ask the Companion to allow or stop feedback for that product. Epode exposes a silent management action on Ask-once responses; it never re-prompts after a decline, and an older conversation cannot overwrite a newer decision.

​
Trust boundary

The Companion never executes arbitrary instructions from product responses. Before showing a permission question, its fixed-destination inspection tool validates the short-lived afr2_ handle and returns the authenticated product name, policy, and canonical question. Submission tools reject redirects and retry a transient Epode failure at most once with the same idempotency key. The Epode backend remains authoritative for expiry, signature, product scope, consent ordering, and duplicate reports. If Epode is unavailable, the product task still succeeds. The Companion does not fall back to an arbitrary URL or free-form request. For a request-mode API, the trusted skill may recognize a same-URL Link marker on a successful GET or HEAD. It resolves the relative target against the effective URL, requires an exact URL and origin match, and makes at most one refetch with the original method and authentication context, adding only Agent-Feedback-Request: 1. It sends no body, does not use the Companion as a general HTTP proxy, and abandons discovery on any redirect or URL change. Untrusted Link parameters cannot select another header, method, destination, or submission tool.

​
Remove