Cause 1: no JavaScript ran, because there was no page
Your tag - GA4, a pixel, whatever you run - is triggered by a browser executing JavaScript on a rendered page. An agent completing a purchase or a form submission through a direct API call to your backend never renders anything. There's no DOM, no script execution, no trigger condition. This is not a bug in your tag; the tag's entire premise didn't occur.
Fix: add a server-side event trigger keyed to the backend action itself (order created, lead submitted, booking confirmed) rather than relying solely on a client-side pageview or click. How to verify: pick a known agent-completed action from your order/lead logs, confirm a corresponding event now lands in your analytics with a timestamp and identifier that reconcile against the backend record. If it reconciles, the trigger is working; if you only "expect" it worked because the dashboard count went up, you haven't verified anything.
Cause 2: no referrer, because none was generated
A Referer header is generated by a browser's navigation stack when a user clicks a link or a page requests a resource in context. An agent fetching a URL via a direct HTTP request outside that stack has no navigation event to generate one from - it isn't stripping the header for privacy, the header structurally has nothing to be populated with. Analytics platforms that classify traffic partly by referrer will file these sessions under "Direct" or drop them, not under "AI."
Fix: stop treating "no referrer" as synonymous with "no source." Reclassify a portion of the Direct bucket using composite signals - see how to detect AI agent traffic - rather than relying on a header that agents frequently have no way to send. How to verify: run the reclassification against a sample of known-agent sessions (identified some other way, e.g. backend correlation) and confirm they land in the agent bucket instead of Direct.
Cause 3: the identity signals don't match what your filters expect
Analytics platforms and bot-management tools both maintain their own lists of "known bots" - and an agent's actual signature (a UA token, an IP range, a signed request) frequently isn't on either list yet, because the agent is new or the list hasn't been updated. The result is either silent filtering (the platform's built-in bot exclusion drops it) or misclassification (a generic bot-management rule buckets it as spam). See agent traffic filtered as bot spam for the full diagnosis of this specific failure mode, and spoofed agent user-agents for the mirror-image problem of traffic that fakes a legitimate identity.
For any of these three fixes, the test is the same: find a specific, timestamped backend record of an agent-completed action, then confirm a specific, timestamped analytics event exists that reconciles against it - same identifier, same window. A dashboard total that "looks about right" is not verification.