A Customer You Cannot See Is Already Buying From You: The Engineering Work Behind Agentic Commerce

The Channel That Appeared Without Asking Your Permission

Most commerce channels announce themselves. You decide to open a marketplace storefront, you sign a contract, you allocate a team, you launch. Agentic commerce did not work that way. It arrived as traffic — first as a trickle of odd-looking sessions with no referrer and a strange navigation pattern, then as a channel large enough to show up in the quarterly numbers, and for a great many merchants nobody ever made a decision about it at all.

The scale is now hard to dismiss. Adobe's analytics data shows AI-referred traffic to retail sites more than doubling year over year, with a 393% year-over-year jump in Q1 2026 and cumulative growth of roughly 1,324% since October 2024. On the transaction side, Salesforce attributed 20% of global orders in the 2025 holiday season to AI agents — about $262 billion in sales.

The quality inversion is the part that should change your planning. In March 2025, AI-referred traffic converted 38% worse than traffic from paid search, email and affiliates. In March 2026 it converted 42% better. By May 2026 the gap had widened to 54% better, with revenue per visit running 37% above non-AI channels. Sessions that arrive via an assistant also spend 48% more time on page and browse 13% more pages. This is not a low-intent channel that needs nurturing. It is the highest-intent traffic most retailers currently receive, because the agent has already done the comparison shopping before it sends anyone your way.

The strategic reading is uncomfortable and simple. A channel you did not build for, cannot see clearly in analytics, and have not tested your checkout against is now your best-converting source of demand. And the reason 73% of merchants are not ready for it is not indifference — it is that the readiness work sits almost entirely in engineering, in systems that were designed on the assumption that a human with a browser and a cookie was on the other end.

Why Your Product Data Fails an Agent

Start with the least glamorous layer, because it is where most of the failure actually occurs. Ballerine's 2026 readiness report put 73% of merchants in the not-agent-ready category, and Mirakl's survey of technology partners scored average retailer readiness at 4.4 out of 10. Roughly 40% of ecommerce businesses have started standardising product pages for agent consumption and about a third have not begun.

A decade of product content investment was optimised for two audiences: a human being scanning a page, and a search crawler ranking it. Both tolerate ambiguity remarkably well. A human infers from a photograph that the blue variant is out of stock in medium. A crawler does not need to know, because it is ranking the page, not buying from it. An agent has to resolve the question definitively before it can act, and when it cannot, it does not ask — it moves to a competitor whose data answered the question.

The specific failures repeat across audits. Availability that is rendered client-side after the initial response, so the agent reads a page that never mentions stock. Variant structures where size, colour and configuration exist as UI state rather than as addressable entities with their own identifiers and prices. Pricing that differs between the feed, the page and the cart because three systems each hold a version. Shipping and delivery estimates computed only at checkout, when the agent needed them to make the comparison in the first place. Return policies expressed in a PDF or a marketing paragraph rather than as structured terms.

None of this is exotic engineering. It is catalogue and inventory work — reconciling the sources of truth, exposing variants as first-class objects, moving availability and price into the server-rendered response and the feed, and making delivery and returns queryable before commitment rather than after. It is unglamorous, it touches systems that several teams depend on, and it is the single highest-leverage thing most merchants can do, because everything downstream assumes it.

The Protocol Stack, and Who Actually Has to Implement What

The protocol landscape looks more intimidating than it is, largely because the acronyms are reported as competitors when most of them are layers.

The Agentic Commerce Protocol (ACP), co-developed by OpenAI and Stripe, standardises the checkout handshake between an agent and a merchant — it is what sits behind ChatGPT's Instant Checkout. The Agent Payments Protocol (AP2), Google's contribution with 60-plus partners, covers the trust and authorisation layer: cryptographically signed mandates that prove a human authorised a purchase, with extensions covering both card rails and crypto. The Universal Commerce Protocol (UCP) frames the wider stack. These compose rather than compete; a complete agentic purchase touches the commerce layer and the payment-consent layer separately.

Consolidation is already visible, which is the most useful signal for anyone deciding how much to build. In May 2026 the FIDO Alliance received contributions of both Google's AP2 and Mastercard's Verifiable Intent work. In June 2026 Adyen shipped a modular API suite supporting UCP, ACP, AP2 and Meta's checkout simultaneously — integrate once, reach every agent surface. Most merchants will meet this stack through their existing payment service provider and commerce platform rather than by implementing specifications directly.

That is genuinely good news, and it is also where teams get complacent. Your PSP absorbing the protocol surface does not absorb the work behind it. The mandate has to be stored somewhere you can retrieve it. The checkout session your PSP exposes still has to be driven by your inventory, your pricing, your tax and shipping logic, and your idempotency guarantees — because an agent that retries a request is not a human who clicks twice and calls support when charged twice. The specification is handled for you. The system it plugs into is not.

Agent Identity: You Are Blocking Traffic You Now Want

For fifteen years the correct default at the edge was to treat automated traffic as hostile. Bot management, rate limits, WAF rules and CAPTCHA gates were built on the reasonable assumption that a non-human client was scraping, carding or hoarding inventory. That assumption is now half wrong, and the half that is wrong is the half that converts at 54% above your other channels.

The industry answer is cryptographic agent identity. Web Bot Auth uses HTTP Message Signatures (RFC 9421) with a per-agent Ed25519 key, a Signature-Agent header and a published JWKS directory, so an agent can prove which agent it is rather than merely claiming a user-agent string. It is backed by Cloudflare, Amazon, Akamai and OpenAI, with an IETF working group chartered in 2026, and edge platforms now expose it as a policy primitive. Cloudflare's collaboration with Visa, Mastercard and American Express extended the same mechanism into payment-network agent authentication through the Trusted Agent Protocol.

The practical consequence for engineering is that bot policy becomes a three-way decision rather than a binary one: verified agents you want, verified agents you do not want, and unsigned traffic. Signed shopping agents from assistants your customers actually use get through, with their own rate limits and their own instrumentation. Unsigned automation keeps meeting the old defences. Platforms are already enforcing this asymmetry — Shopify applies its strictest rate limits to storefront traffic arriving without a signed identity, which means an unprepared merchant is not neutral toward agents, it is actively degrading them.

This work is small in code and large in coordination. Someone has to own edge configuration, decide the allowlist policy, separate agent traffic into its own rate-limit and observability bucket, and then keep that policy current as the set of certified agents changes. In most organisations no team owns all three of those, which is precisely why the work stalls.

You Are Still the Merchant of Record

Here is the sentence that should route this discussion to your risk function as well as your engineering leadership: in every protocol currently deployed, the merchant remains the merchant of record. The agent decides, the assistant surfaces the transaction, the payment network moves the money — and the chargeback, the refund, the support cost and the inventory loss land with you.

The dispute framework was designed around a human buyer who can be asked what they intended. Analyses of agentic chargebacks describe the resulting evidence gap directly: representment relies on device fingerprints, session history, IP consistency and behavioural signals that simply do not exist when a model bought on someone's behalf. Visa's own threat analysis frames it as an identity deficit at the point of payment: authorisation context and purchaser context can no longer be correlated the way every fraud model assumes.

Nobody agrees who should absorb this. When asked who pays for a bad agent-driven transaction, survey responses split 39% to the AI provider, 20% to the customer, 14% to the merchant or platform, 11% to the bank or processor and 15% to a shared model. Note that only 14% think it should be the merchant, and the merchant is currently the party who carries it. Gaps like that close eventually through network rules and regulation, and they close slowly.

The engineering mitigation is unromantic and effective: capture the evidence at the moment of purchase, because it does not exist afterwards. Store the signed mandate or intent credential alongside the order. Record which agent transacted, under which delegation chain, against which product state — the price, the availability and the terms the agent actually saw, not the ones live today. Make all of it retrievable by order reference inside the representment window your acquirer works to. Merchants that build this treat an agentic dispute as a documented transaction. Merchants that do not are conceding chargebacks they might have won, and they discover this only after the disputes arrive.

The European Layer: SCA Has No Agent Exemption

European merchants have an additional constraint that most of the agentic commerce coverage, written from a US perspective, quietly omits.

Agent-initiated payments in Europe remain squarely within PSD2 and its regulatory technical standards, including Strong Customer Authentication. There is no special extra-regulatory regime for autonomous purchasing. An agent buying on a customer's behalf does not dissolve the authentication requirement; it relocates it, and the burden of designing a flow where a human authenticates something they are not physically present for lands on the merchant and its PSP.

PSD3 and the accompanying Payment Services Regulation address part of this through delegated authentication, which lets a third party perform SCA on the issuer's behalf. The timing matters for planning: publication in the Official Journal is expected around the end of Q2 2026, with an eighteen-month transition putting real application in late 2026 to Q1 2027 at the earliest. Agentic volume is not waiting for that date, so there is an interval — the one you are in — where the commercial pressure is live and the regulatory accommodation is not.

There is a second-order effect worth flagging to anyone whose roadmap includes offering delegated authentication rather than merely consuming it. Draft rules classify a bank delegating SCA to a third party as an outsourcing arrangement, which pulls in the EBA Outsourcing Guidelines: prior due diligence, written agreements defining scope and responsibilities, service levels, and documented exit plans. That is a materially different compliance posture than shipping a checkout feature, and it is better understood before the architecture is settled than after.

The European market itself is not hesitating. Agentic commerce dominated Shoptalk Europe 2026 in Barcelona, where more than 4,500 retail and technology leaders spent the week on it, and Zalando's assistant grew from six million users across 2025 to ten million in Q1 2026 alone. The demand signal and the regulatory signal are simply moving at different speeds, and European engineering teams have to build for both.

What Actually Has to Get Built

Stripping out the strategy language, the readiness gap resolves into six concrete pieces of work. They are not equally urgent and they have a natural order.

A machine-readable catalogue surface. Variants as addressable entities with identifiers, prices and availability. Server-rendered stock and price, reconciled across feed, page and cart. Delivery estimates and return terms queryable before commitment. This is first because everything else is worthless without it — an agent that cannot resolve your catalogue never reaches your checkout.

Agent identity at the edge. Signature verification, an allowlist policy for certified agents, separate rate limits, and agent traffic split into its own observability bucket. Second because it is cheap, and because until it is done you may be degrading the exact traffic the rest of the programme is meant to serve.

Intent and evidence capture. The signed mandate, agent identity, delegation chain and the product state the agent transacted against, stored with the order and retrievable by reference. Third because the data is unrecoverable if you skip it, and because the disputes arrive on a lag — by the time you feel the need, the evidence window for the orders in question has closed.

An agent-drivable checkout. A session API with strict idempotency, price and stock locking for the duration of the transaction, pre-commitment tax and shipping quotes, and error semantics an automated client can actually act on. Mostly PSP-mediated, but the guarantees behind it are yours. Then post-purchase: order updates, returns and support flows that reach the human when there is no browser session to notify, and a support function that can handle a customer who has never seen your interface. And finally observability — server-side attribution for a channel with no cookie, often no referrer and no session continuity, because a channel you cannot measure is one you cannot make the case to invest in.

Sequenced this way, the first three are a matter of weeks for a small senior team and account for most of the risk reduction. The remaining three are where the channel becomes something you optimise rather than merely survive.

Staffing Work That Sits Between Four Teams

The reason this work stalls is rarely disagreement about whether it matters. It is that the work crosses catalogue, payments, edge infrastructure, risk and support, and it belongs cleanly to none of them. Every team it touches has a roadmap already committed for the quarter, and the piece each is asked to contribute is too small to justify replanning and too entangled to hand to a junior. So it becomes an initiative that everyone endorses in the steering meeting and nobody starts.

It is also poorly suited to permanent hiring. The heavy phase is a defined project with a real endpoint — get the catalogue clean, get identity verified at the edge, get evidence captured, get the checkout driveable — followed by a much lighter steady state of policy updates as the agent ecosystem shifts. Hiring three permanent engineers for a nine-month build leaves you with the wrong shape afterwards, and the profile you need in the meantime is uncomfortably specific: people who have done payments integration, edge and bot-management configuration, and catalogue reconciliation, and who can hold the compliance constraints in view while doing it.

At StepTo we have run senior engineering teams out of Serbia since 2014, and this is a recognisable shape among the engagements that work well: a parallel track that does not compete with the product roadmap. Your teams keep shipping what they committed to, while a separate dedicated development team owns the agent-readiness build end to end — catalogue and feed reconciliation, the backend and integration work behind checkout and evidence capture, and the edge policy — then hands back documented systems and the runbooks to maintain them. Engineers are assigned by name and stay with the codebase, which matters here because the expensive knowledge is understanding why one merchant's inventory data behaves the way it does, and that takes months to acquire and one rotation to lose.

The nearshore element is more than a rate argument in this particular case. Agent surfaces and their certification requirements are changing month to month, and edge policy changes touch live revenue. When a signed-agent allowlist needs a decision or a checkout change has to be rolled back, four or more hours of overlap with Western European working hours is the difference between resolving it today and resolving it tomorrow. For teams that already have the people and need the specific experience added to an existing group rather than a separate one, staff augmentation against named senior engineers is usually the faster route in.