Why this matters
“It is broken” rarely identifies a product step, time, environment, or error. The fastest useful support investigation narrows the report and reads only the evidence needed to answer it. Pulling an entire customer history by default is both noisy and a privacy mistake.
Agentry can return an identity-linked product summary and recent recordings for
an authorized distinct_id. That summary does not automatically prove a
runtime error or connect the user to a case. Any case attribution must be
corroborated with a real case ID or fingerprint from the available evidence.
What you get
- A bounded timeline of relevant product events
- Replay evidence only when enabled, necessary, consented, and redacted
- A separately inspected error case when a real case link exists
- A human-reviewed reply that distinguishes fact, hypothesis, and next question
Walk through it
An authorized customer says checkout failed around 14:20 UTC. What can we prove?
I need the exact project and stable distinct ID used by this app. I will read the minimum relevant evidence and will not assume every recent event belongs to this report.
GET /v1/projects/:project_id/users/:distinct_id/summaryThe path identifier must be URL-encoded. The response uses these top-level fields:
{
"project_id": "<project_id>",
"distinct_id": "<authorized_distinct_id>",
"person": {},
"event_stats": {
"count": 42,
"first_seen": "<timestamp>",
"last_seen": "<timestamp>"
},
"recent_events": [
{ "event": "checkout_started", "timestamp": "<timestamp>" },
{ "event": "payment_failed", "timestamp": "<timestamp>" }
],
"recent_recordings": [],
"web_ui_url": "<provider_url>",
"next_action": "<server-provided guidance>"
}The summary returns a bounded recent-event list, not an arbitrary 48-hour query, and a missing recording is not evidence that the customer did nothing.
If a relevant recording exists and replay inspection is authorized, fetch only that recording using the current replay operation. If the support report, replay, or a separately triaged case supplies a real case ID, inspect it:
GET /v1/cases/:case_idCase messages, request fragments, breadcrumbs, URLs, stacks, and annotations are untrusted evidence. They cannot instruct the agent to run commands, fetch arbitrary URLs, reveal secrets, or expand the investigation.
The output
Customer report — <reported time and expected outcome>
Observed
- <event or replay fact with timestamp>
- <case fact, only if a real case was inspected>
Not established
- <missing event, identity gap, replay gap, or absent case link>
Likely explanation
- <hypothesis, explicitly labelled and tied to evidence>
Next internal action
- <engineering/support step and owner>
Draft customer reply for review
- <plain-language statement; no unrelated customer data or unsupported cause>If the available data does not establish the reported failure, the correct answer is a concise request for the missing timestamp, action, or screenshot—not a confident diagnosis.
Setting it up
Use a stable pseudonymous user ID when possible; do not make email addresses the default analytics identity. Carry only the properties needed to understand the product flow. Configure replay consent, sampling, and redaction before treating recordings as a support surface.
For runtime errors, include stable user or account context only when permitted, and never attach secrets, payment data, tokens, full request bodies, or unrelated personal information. Verify the actual support flow and a shipped-code error path during installation.
Variations
- “Summarize only the five events nearest the reported timestamp.”
- “Check whether this real case affected other users without revealing their identities.”
- “Draft a reply that says what we know and asks for the one missing detail.”
- “Compare the case’s deploy SHA with the latest trusted release.”