Skip to main content
Everything an agent reads through Autoplay MCP hinges on one rule:
The user_id an agent sends must equal the user_id activity was stored under — the stable id your activity source identifies the user with.
Activity is keyed by that id. If an agent asks for a different value (an email, a support agent contact id, an anonymous session id), it reads the wrong bucket — or an empty one — and the user looks inactive even though they’ve been clicking around.
The id depends on your activity source. Autoplay is source-agnostic — the source set grows over time:Whichever source you use, the rule is the same: the agent must send that id.

​
🧩 The three layers that must agree

Layers 1 and 2 line up automatically — the connector stores activity under the stable id your source sends. The work is making layer 3 carry that exact value.
Use a stable user id — your internal user primary key, the same one your activity source identifies with. Do not key on email: emails change, and activity is stored under the stable id, so an email lookup reads the wrong bucket.

​
🤝 How each agent satisfies layer 3

Every agent has its own way of passing a trusted identity to the connector. The mechanism differs per agent; the required value is always the same (your activity source’s stable user id).
For anonymous (not-logged-in) users there’s no trusted identity to pass, so an agent can’t reliably pull their activity. This surface is designed for logged-in users your source has identified.

​
🛟 Debugging “no recent activity”

Almost always an identity mismatch. Confirm the same value appears in all three places:
  1. the id your activity source identifies the user with (e.g. PostHog identify, Amplitude user_id),
  2. whatever your agent uses as its verified identity (e.g. Fin’s JWT user_id claim),
  3. the user_id the agent actually sends to the MCP tool (or the REST endpoint).
For where identity is set on the source side, see your source’s setup — e.g. the Quickstart covers posthog.identify.