A customer says my AI agent did not work for them. How do I find what happened?

Rius takes you from a support ticket to the failing span in a few clicks. On the Users page, type the customer’s exact user ID, click Find, open their row, and open the failed trace from the time they wrote in. The span details of that trace show where the run went wrong.

How it works

Rius groups traces by end user. Each span names its end user with user.id, enduser.id or enduser.pseudo.id, and Rius takes the first one that is set. The SDKs set user.id on every span of a request that runs inside a user scope. A trace with no end user on any span counts as anonymous.

The Users page lists the top 50 users for the sort you choose, over a window of 15m, 1h, 1d, 7d (the default) or 30d. Searching by the exact user ID reaches anyone outside that top 50.

A user’s page shows how that person experienced your agents:

• Failed traces: traces whose root span ended in error.
• Error rate: the share of their traces with at least one errored span, including runs that recovered.
• Recent traces: their 8 newest traces, each with a state of completed, recovered, failed or running, plus the time, trace name, agent, span count, errors and duration.
• Failed traces list: their 6 latest traces with at least one errored span. Recovered runs are included, so this list can be longer than the Failed traces tile.

The figures count only finished traces. A run appears once every span of it has ended.

Set it up

1. Make sure your agent attributes each request to the customer. Initialize the SDK once, then run each request inside a user scope: rius.user in Python or withUser in TypeScript. Use an opaque user ID rather than an email, and use the same ID your support team sees on the ticket.

   import rius
    
   client = rius.init(
       api_key="ri_...",
       service_name="my-agent",
   )

2. Open Users in the console and set the time window to cover when the customer wrote in. Use 7d or 30d if the report is a few days old.

3. Type the customer’s exact user ID and click Find. Then click their row to open their page.

4. Check the Failed traces tile and the Failed traces list. Match the time on each row to the time of the ticket, then click that row to open the trace.

5. In the trace, find the span that ended in error and read its details. If you kept content capture on, which is the default, the span also carries the prompt and response, so you can see what the customer asked and what the agent did. The Monitor AI agents in production guide covers the rest of the workflow.

6. If the list shows no failure at that time, open Recent traces and look at the runs around it. A run that recovered is labelled recovered, not failed, and a run still going shows as running.

To check your setup before a customer needs it, run one request inside a user scope with a test ID such as test-user-1. Open Users, type test-user-1, click Find, and open the row. Once the trace has finished, the page shows 1 trace, your agent under Agents that served this user, and the trace under Recent traces.

What you get

• A direct path from a customer’s ID to the trace from the time they wrote in, without scrolling through every run.
• A clear read on whether the problem is theirs or yours. Compare their error rate and cost per trace with the agent’s own numbers on the Agents page. If theirs are well above, the cause is probably specific to that user: their data, their account settings or the kind of questions they ask.
• A view of how widespread it is. Sort the users list by Failed. If a handful of users account for most failures, look at what they have in common before you change anything that affects everyone.
• Context on their experience: Sessions, Cost and TTFT p50, the median time to first token on their streaming calls.
• A written account on demand. When root-cause analysis is on for the workspace, an admin can click Summarise this user on their page. The summary covers the page’s window, up to the newest 7 days, and counts as one analysis against your analysis budget.
• The same lookup from your tools. The trace tools on the Rius MCP server take a user_id argument, and list_users and user_activity_summary work by user too.

When something else fits

If the customer’s runs carry no user ID, they sit in the anonymous row, which opens the trace list filtered to traces with no end user. Use the time, agent and error filters there, and add a user scope in your code so the next lookup is by ID. If a run is still going or crashed before it finished, it does not count as a finished trace yet. Turn on partial spans in the SDK so a running or crashed run leaves a record.

Related