the category

Your users and your agent are one dataset.

Analytics for AI products is split in two, and the split is in the wrong place. If the thing you are building is an agent, the user journey and the tool calls are the same story — and every tool on the market makes you pick a half.

computing…

The split, and why it hurts

Product analytics
PostHog · Mixpanel · Amplitude

Sees: pageviews, signups, funnels, retention, cohorts

cannot see a single tool call your agent makes

LLM tracing
LangSmith · Braintrust · Arize · AgentOps

Sees: tool calls, latency, errors, conversation traces

cannot see the signup, the funnel, or whether anyone converted

Neither is badly built. They were designed before the product and the model were the same thing. But it means the questions that decide whether an AI product works sit exactly on the boundary, where nobody can answer them:

Analytics for AI products is split in two, and the split is in the wrong place. Product analytics tools (PostHog, Mixpanel, Amplitude) record what people do — pageviews, signups, funnels, retention — and have no visibility into the agent inside your product. LLM tracing tools (LangSmith, Braintrust, Arize, AgentOps) record what the agent does — tool calls, latency, errors, conversations — and have no visibility into the product around it. If the thing you are building IS an agent, that boundary runs straight through the middle of every question worth asking: how many people who signed up ever used the agent, whether the ones whose tool calls errored churned, which step of the journey the agent is actually costing you. smolanalytics stores both in one append-only event log with one generic event model, so a funnel can start at a pageview, pass through an agent_tool_call, and end at a checkout as a single computed report. No joining two vendors, and no exporting one into the other.

Why it works here

There is one event model. An agent event is not a special record type in a separate system — it is an event with a name and properties, exactly like a pageview, keyed to the same person:

POST /v1/events
{ "name": "signup",          "distinct_id": "u_8123" }
{ "name": "agent_tool_call", "distinct_id": "u_8123",
  "properties": { "tool": "run_query", "latency_ms": 780, "error": false } }

Because they are the same shape in the same store, a funnel across them is one query rather than an integration. That is an architectural consequence, not a feature we added: it is why a tool built on a fixed agent-trace schema cannot follow, and why one built on product events alone has nothing to join to.

Everything else stays true across both halves. The agent reports — tool latency at p50/p90/p99, an error taxonomy, conversation health — are computed from the same engine that renders your funnels, and show up in the same dashboard.

Send agent events with the key you already have.

No separate SDK, no schema migration, no second bill. If you are already sending product events, agent events go to the same endpoint and start showing up in the same reports.

keep reading