Skip to main content
Customer enrichment is one way Epode can add permissioned, cross-session context to an agent journey. It supports the broader product foundation—observing AI traffic and understanding customer intent—but it is not the whole product or a proven conversion mechanism. The capability does one job:
Learn a useful, permissioned fact about a customer through their agent, return it to the company, and measure whether using it improved the experience.

​
What can be learned

Each answer item is one of four types:
  • Intent: what the customer is trying to accomplish now.
  • Preference: what the customer tends to prefer.
  • Constraint: a non-sensitive product limit such as budget, delivery window, or company size.
  • Interest: a non-sensitive subject the customer is interested in.
Epode accepts at most eight items from one request. Every key, type, and value must match the versioned catalog returned in the action schema. Epode writes a canonical summary itself; agent-written prose never becomes customer context. Each catalog entry also says whether it is approved for advertising. Raw prompts, transcripts, product responses, credentials, names, emails, sensitive traits, and unknown fields are rejected.

​
Provenance is not optional

An agent inference may help within the current interaction, but must not silently become a durable customer fact.

​
Permission has a purpose

Epode supports two initial uses:
  • product_personalization
  • targeted_advertising
Approval for one never grants the other. Remembering context is also explicit. Revoked, declined, expired, or out-of-purpose signals never appear in context.get.

​
Known, anonymous, and ephemeral

  • Verified company authentication supplies accountRef and userRef.
  • A signed, product-owned first-party visitor ID supplies anonymousRef.
  • No stable reference creates an ephemeral customer for only that interaction.
  • Supplying the earlier anonymous reference after authentication authorizes deterministic resolution.
Epode never resolves identities probabilistically or across customer companies.

​
What Epode asks

Context used only to complete the current business-tool call should travel as bounded input to that tool. The host owns approval of the call, and the product returns an exact received/applied/rejected receipt. That path does not silently create a durable Epode profile and must not depend on the agent calling another tool first. For retained personalization, the company does not design a survey. It chooses the product surface and permitted purpose. Epode asks for a small amount of relevant, missing context that could improve later experiences. The agent can:
  1. share explicitly known/current context after permission;
  2. ask the customer the exact returned question;
  3. report that it has no relevant context; or
  4. decline.
Silence and ambiguity are never approval. MCP form elicitation is a best-effort presentation mechanism for client versions that demonstrably render and resume it, not the source of Epode’s privacy guarantees. A client that cannot resume continues without retained enrichment. Host tool approval and product profile permission are different controls and may both be visible. An assistant’s broader saved memory is never imported during first-use personalization. If a product offers an optional profile import, it must preview the exact bounded items and provenance, let the customer remove items, and commit only the approved selection. The MCP server cannot autonomously inspect a host’s complete memory.