Measuring AI-agent usage inside your product without polluting DAU and retention

What it is

"Product-agent usage" is the case where an AI agent - an MCP client, a general-purpose assistant with browsing or tool access, or an operator-style browser - acts inside your actual product on a user's behalf: calling your API, driving your UI through browser automation, or invoking tools you've exposed through an MCP server. It's a different problem from AI-crawler indexing (a bot reading your marketing pages) and from human AI-referral traffic (a person who read an assistant's answer and clicked through as themselves) - here, the agent IS the user, executing real product actions, and every one of those actions lands in Amplitude as a normal event unless you deliberately mark it otherwise.

The scale of the broader shift is already measured, even if not yet inside any one product's own instance: automated requests now make up the majority of raw web traffic (Cloudflare Radar has put automation above 57% of HTML traffic against a shrinking human share, and HUMAN Security's 2026 benchmark reports automation growing roughly 8x faster than human traffic). That's a website-traffic figure, not a product-usage one, but the same underlying shift - assistants and agents increasingly acting instead of a person clicking - is what's now reaching authenticated products through APIs and MCP surfaces, not just public pages. The posture the wider industry has converged on for web traffic - stop trying to block agents, measure them instead - applies just as directly inside a product as it does on a marketing site.

Because agent access most often arrives through the same API, SDK, or MCP tool surface a human-driven session would use, an agent-originated event usually carries the same shape (same event name, same properties) as a human one. MCP, the agent-to-tool layer of the wider 2026 agent-protocol stack, is one of the most common paths this access now arrives through when a product deliberately exposes tools for an assistant to call - which means the calling context (an MCP tool invocation, a service-scoped API credential, an automated browser session) is what actually distinguishes the two, and that context has to be captured at the point the event fires, not reconstructed afterward from behavior patterns alone.

When you need it

• Your product exposes an API, SDK, or an MCP server that a third-party agent (an MCP-connected assistant, a custom tool or action, an operator-style browser) can call on a user's behalf, and those calls run through the same event pipeline that captures human-driven usage.
• Leadership is asking why DAU, activation, or a specific funnel moved with no shipped product change to explain it, and undisclosed agent-driven usage is a plausible answer worth testing before any other theory.
• Support or account teams flag usage that doesn't read as human - near-instant multi-step sequences, activity on a fixed schedule, engagement at hours or a cadence no person keeps - and analytics needs a way to confirm or rule that out with data instead of anecdote.

Implementation, done properly

1. Capture the calling context at the event, server-side, at the moment it happens - not as a downstream inference. A property like `actor_type` (human / agent / unknown) or `access_channel` (ui / api / mcp), set from how the request actually arrived (a session cookie versus a scoped API key versus an MCP tool invocation), is reliable in a way that pattern-matching behavior after the fact never fully is.
2. Treat `unknown` as its own visible state, not a default that quietly folds into `human`. A calling context you can't confidently classify should show up as its own segment size on a dashboard - something a team can choose to investigate - rather than disappearing into the human count and inflating it invisibly.
3. Build a saved cohort or segment for agent-attributed events and users the same way you'd build any behavioral cohort in Amplitude, then apply it as a standing breakdown or exclusion filter on the metrics leadership actually reads - DAU/MAU, the activation funnel, the retention curve - instead of rebuilding the same exclusion logic inside every chart separately.
4. Get an explicit, named decision from product leadership on how agent-driven usage should be treated in headline metrics: excluded entirely, reported as its own line, or blended with a visible breakdown. This is a product-strategy call, not a data-modeling one - a product built around an agent-driven workflow may want that usage counted and celebrated, while a seat-based product selling to humans usually doesn't want it inflating adoption numbers it can't actually charge for.
5. Extend the same `actor_type` discipline to activation and retention definitions specifically, not just to a DAU count. An activation funnel built on "did action X within N days" can be satisfied by a single automated test call from an agent integration, and a retention curve can look artificially healthy if an agent polls the same API endpoint on a fixed schedule - both are exactly the kind of quiet distortion a measurement owner ends up having to explain in a room full of people, months after it started.

How to verify it worked

1. In Amplitude's Events explorer, filter to the new `actor_type` (or `access_channel`) property and confirm it's populating consistently across every entry point that can carry agent-originated traffic - your public API, any MCP server you expose, and any documented third-party integration - not just the one entry point you tested first.
2. Pick one account you're confident is agent-driven and one you're confident is human, with a similar raw event count, and compare session shape - timing distribution between events, throughput per minute. A genuinely agent-driven account should look visibly more regular or bursty than typical human variability; if it doesn't, the classification is worth re-checking rather than trusting on the first pass.
3. Recompute DAU/MAU and the activation funnel with the agent segment excluded, side by side with the current blended number, and look at the size of the gap. That delta is itself the finding - it's the number that should get reported alongside the headline metric going forward, not one that quietly disappears once it's been checked once.
4. Re-run this whole check on a standing cadence, not once at setup. Agent-originated usage through an API or MCP surface is one of the fastest-moving segments in product analytics right now, so a share that was negligible last quarter can become material within a couple of release cycles - a one-time classification will go stale exactly when it starts to matter.

Related: Amplitude AI agents: what they do and when to use them · Building behavioral cohorts in Amplitude · Event segmentation in Amplitude: a practical walkthrough

Elsewhere in the agentic-traffic research: What is agentic traffic? Agents vs. AI crawlers vs. AI referrals · Why your AI/agent traffic is undercounted 3-4x · Segmenting AI-agent sessions in GA4 · Classifying agent vs. human requests in server-side GTM

Sources

• HUMAN Security: 2026 State of AI Traffic & Cyberthreat Benchmark Report
• WorkOS: AI agent web traffic - what developers need to change
• ikigai: stop blocking AI bots, start measuring them
• Bounteous: server-side analytics, 2026 and beyond
• Hexagon: the agentic commerce protocol stack (UCP, ACP, AP2, MCP, A2A)

This space moves fast - every landscape figure above links to the primary source it came from. Platform-specific claims are flagged in-line to verify against current vendor documentation.