What visitor ID stitching assumes, and what an agent breaks
Tealium AudienceStream's visitor ID stitching (see our visitor ID stitching guide) resolves an event to a profile using identifiers in a precedence order you define: a verified login ID typically outranks a device ID, which outranks an anonymous cookie. That model was built for a world where every request originates from a browser carrying at least one of those signals. An agent session is where that assumption quietly stops holding.
Three request shapes now hit the same checkout flow, and they carry three different identity postures:
| Path | What identity signal exists | Can AudienceStream stitch it to the real customer? |
|---|---|---|
| Human, logged in, own browser | Cookie + device ID + a login-bound customer ID | Yes - standard precedence rules apply, nothing new |
| Agent browsing (operator-style, e.g. ChatGPT agent or Atlas driving a browser) | A session cookie may be set for that single session; no prior device history to match against | Partially - a profile forms, but it is orphaned from the customer's known profile unless that session itself completes a login |
| Agent API action (fetch or checkout via API, no browser involved) | No cookie, no device ID, no browser session of any kind | No - unless the request payload itself carries an explicit customer identifier, there is nothing for the stitching rules to key on |
| Agent discovery, human completes checkout (the majority pattern since the Agentic Commerce Protocol's Instant Checkout was rolled back in March 2026) | The human's own browser session at the final step | Yes at checkout - but the agent's earlier discovery/research step is what typically goes unlinked to that same person |
Scale makes this worth solving now rather than later. HUMAN Security's 2026 benchmark and Cloudflare Radar data put automated requests at 57.5% of HTML web traffic; Adobe Analytics recorded a 4,700% year-over-year increase in AI-driven visits to US retail sites in 2025 and measured AI-driven traffic converting 42% better than non-AI traffic in March 2026, and Shopify's AI-attributed order volume grew roughly 11x between January 2025 and March 2026, per industry analysis. The same source estimates around 70.6% of AI referral activity is invisible to a standard GA4 setup - a detection problem, distinct from this one, but evidence of the same underlying shift: identity signals that used to be reliable no longer are.
What breaks if you treat the agent session as a new anonymous visitor
This is the default outcome if nobody intervenes, because it is exactly what the stitching rules are designed to do with a request that matches none of the identifiers they already know: create a fresh profile. The consequences compound the same way they do for any unresolved identity, just faster and less visibly, since nobody is watching for a specific "agent" failure mode yet:
- Duplicate customer profiles. The same person exists twice: once under their known, logged-in identity, once under a new anonymous profile the agent's request generated. Every AudienceStream implementation guide warns about this exact failure mode for ordinary anonymous-to-known transitions - an agent session is just a new, currently-unhandled way to trigger it.
- Fractured attribute history. Computed attributes - lifetime value, lifecycle stage, purchase badges - split across two profiles. Each individually understates the customer, and any audience built on a lifetime-value threshold silently excludes people it should include.
- An orphaned or double-counted sale. If the agent-originated profile never merges, the sale attributes to an anonymous visitor your reporting cannot explain. If a human session for the same person also logged intent around the same purchase, some models double-count it instead - the opposite failure, same root cause.
- Audience membership incoherence. Segmentation and activation run against whichever profile happens to hold the qualifying event. A customer who should be excluded from a win-back campaign because they just bought stays in it, because the purchase landed on their other profile.
The claim worth stating plainly: none of this is a Tealium defect. AudienceStream faithfully executes whatever stitching logic you give it, including logic that was never told an agent-originated event could exist. The gap is a missing identity input, not a missing platform feature.
The fix: carry an explicit identifier into the event, don't infer one
Device-fingerprint and cookie-based stitching is a reasonable bet for a human browser, where the same device tends to reappear. It is a poor bet for an agent, which has no persistent device history to build a fingerprint from and, in the API-only case, no device signal at all. Inferring identity from behavior here is guessing dressed up as resolution.
The more defensible model treats an explicit, already-authoritative identifier - a hashed email, a login-scoped customer ID, an account reference the merchant already trusts - as the highest-precedence signal in the stitching hierarchy, arriving through whatever channel actually carries the transaction:
- Capture the event at the layer that actually sees the agent request - typically server-side, since an API-only agent action never touches a browser to run a client-side tag. If the request never fires JavaScript, it needs a second collection path, not a better client-side script.
- Require the identifier at the point of transaction, not after. Whatever completes the sale - your commerce backend, a merchant redirect flow, an authenticated API call - is the one place a durable customer reference genuinely exists. Capturing it there and forwarding it into the event beats trying to reconstruct it later from behavioral signals.
- Feed that identifier into AudienceStream ahead of device or cookie signals in your precedence rules, exactly as a verified login already outranks an anonymous cookie today. This is a configuration change to existing stitching logic, not a new feature.
- Test the merge deliberately - a synthetic agent-originated event carrying a known identifier, checked against the same known profile, the same verification discipline our visitor ID stitching guide recommends for any anonymous-to-known merge.
Note what this does not solve: an agent action that never carries any customer identifier at all has nothing to stitch on, by construction. No stitching rule invents an identity that was never presented. That is a capture-design problem upstream of AudienceStream, closer to the server-side collection question covered in capturing agent traffic server-side when no JavaScript fires.
AP2 mandates as a future identity signal (a hypothesis, not a Tealium feature)
Google's Agent Payments Protocol (AP2), announced September 2025 with 60-plus partners including Mastercard, PayPal, Amex, and Coinbase, defines three signed Mandates - Intent, Cart, and Payment - structured as W3C Verifiable Credentials; the protocol was donated to the FIDO Alliance in April 2026, per eco.com's protocol explainer. AP2 was designed as a payment-consent and authorization layer - it establishes that a specific agent was authorized, by a specific person, to complete a specific transaction. It was not designed as a customer-identity-resolution protocol.
Labeled hypothesis: because a signed Cart or Payment Mandate already binds a transaction to a specific authorizing identity, it is plausible that the mandate reference could double as a durable, cryptographically-verifiable stitching key - arguably a stronger signal than a hashed email, since it is signed rather than merely asserted. This is our inference from how the protocol is structured, not a documented capability. No announced Tealium integration, or general CDP connector, consumes AP2 mandates as an identity source as of this writing. Treat it as a design bet worth watching, not a feature to build a roadmap around yet. The fuller protocol picture - AP2 alongside ACP, MCP, and WebMCP - is covered from a measurement angle in agentic commerce protocols for measurement people.
A related but separate identity question: Web Bot Auth (the Cloudflare-led IETF draft built on RFC 9421 HTTP Message Signatures, shipped into Cloudflare Verified Bots in July 2025) lets an agent cryptographically prove which agent it is. That answers a different question than AP2's mandates - it verifies the actor, not the customer it is acting for. Both matter; neither substitutes for the other, and conflating them is an easy mistake to make when reading vendor material about "agent identity" broadly. Whether an agent can validly consent on a customer's behalf at all is a governance question ahead of the technical one - see can an AI agent legally consent on your customer's behalf.
Why this is smaller today than the trend line suggests
Since the Agentic Commerce Protocol's Instant Checkout was rolled back in March 2026, most current agent-commerce journeys end in product discovery plus a merchant redirect - the agent researches, a human completes checkout in their own browser. That is the easier stitching case: the human's session at checkout still carries ordinary identity signals, and the harder problem is usually just linking the agent's earlier discovery step back to that same session, not reconciling a fully unattended purchase. Genuine end-to-end API purchases with no human browser step are the less common case as of September 2026, but the growth trend - Shopify's 11x AI-order growth, Adobe's 42%-better conversion figure - points toward that harder case becoming ordinary, not rare. Building the explicit-identifier stitching model now is cheaper than retrofitting it once agent-originated purchases are a routine share of revenue.
A model you can defend, not a guess
State this the way any identity-resolution decision should be stated to a room that will ask what breaks it:
- Basis: an explicit, already-authoritative identifier passed at the point of transaction outranks any inferred device or cookie signal, for both human and agent-originated events. This is the same precedence principle AudienceStream already applies to a verified login - extended to a new event source, not a new rule.
- What would break it: an agent architecture that never surfaces a customer identifier to the merchant at all (some current agent-checkout flows genuinely do not); a merge-rule oversight that lets a same-session agent cookie get treated as durable device history it is not; assuming AP2 mandates are already a working identity input when no such integration exists yet.
- What to verify: run a synthetic agent-originated event carrying a known identifier through to a real merge, the same test discipline used for any anonymous-to-known stitching change - confirm the combined profile shows unified attribute history, not just a second identifier sitting beside an unchanged original profile.