Here’s how it usually looks. A paid campaign sends someone to your site. They read two pages and leave. Eleven days later they install your app. They poke around for a week, hit the paywall, and subscribe.

Now ask three tools what happened.

The ad platform claims credit for an install. Web analytics shows a bounce. Your CRM has a new customer with no visible origin. And the subscription sits in a billing dashboard with no campaign attached to it.

Nobody is lying. The systems just don’t share a graph. And the further you get from the browser, the worse the disagreement gets.

That’s why we built native SDKs for iOS and Android. But the reason isn’t “we added mobile support.” The reason is that two shifts are landing on the phone screen at the same time, and both of them punish a measurement stack that stops at the web.

The browser was the easy half

For all the noise about the death of third-party cookies, first-party measurement on the web is mostly a solved problem. You own the domain. You control the script. You can follow a journey, resolve identity, and connect a form fill to a deal in your CRM.

Apps never got that treatment. App measurement got outsourced to a different discipline with different rules, built on platform attribution frameworks and mobile measurement partners.

Those tools have real limits. An AppsFlyer analysis of SKAdNetwork found that roughly 32 percent of non-organic installs were misattributed as organic, and that the framework captured only about 64 percent of revenue driven by non-organic installs. Apple’s App Tracking Transparency opt-in has plateaued around 27 percent globally. Which means most iOS attribution decisions now rest on probabilistic or postback modeling instead of a deterministic match.

None of that is a knock on anyone’s engineering. It’s a description of the surface. On the web, first-party is the default. On mobile, third-party estimation is the default, and the numbers quietly reflect it.

So a platform that claims to show where revenue comes from, but can only see the web half of the journey, is describing a business it can only partially observe.

Meanwhile, the app became the storefront

Mobile has been the majority of ecommerce for a few years now: roughly 57 percent of global ecommerce sales in 2024, with projections near 59 percent for 2025.

The more interesting number is where inside mobile the buying happens. About 54 percent of mobile commerce runs through apps rather than mobile browsers, per J.P. Morgan data. The in-app purchase market itself was valued near $190 billion in 2025.

Put those together and the shape of the problem is hard to miss. The surface we measure worst is carrying the most revenue. And it’s growing.

For a subscription business, that isn’t a rounding error. App stores are where the subscription starts, where it renews, and sometimes where it dies. If the only record of that is a platform postback with a fuzzy campaign label, the revenue number and the acquisition number never actually meet.

And the phone is where agents arrive first

Here’s the part that made this urgent instead of just overdue.

Both platforms are turning apps into callable surfaces for AI agents. Apple’s June 2026 developer announcements describe App Intents as the mechanism connecting apps to Siri’s personal context, app actions, and onscreen awareness. Google’s equivalent, AppFunctions, is blunter about it. The documentation calls AppFunctions “the mobile equivalent of tools within the Model Context Protocol,” letting apps behave like on-device MCP servers whose functions an agent can discover and execute. It runs on Android 16 and up, and it’s in private preview with Gemini today.

That’s the WebMCP argument, arriving on mobile ahead of the web.

The implication takes a minute to land. When an agent books, orders, subscribes, or cancels on someone’s behalf by calling a function inside your app, the interaction may never render a screen. No pageview. No click. No session in any sense you’d recognize. A function invocation, a result, and a change in your database.

If the only record of that event is a platform postback, you’ve rebuilt the exact blind spot we started this company to fix, right at the moment it becomes most expensive.

Agents don’t need a prettier dashboard. They need a system of record that knows who the person is, what they authorized, and what it was worth. Which is the same thing your revenue team needs. And the same reason attribution has to live in a first-party graph instead of inside any single platform.

What “native” had to mean

Supporting mobile could have meant a thin wrapper that ships events to a third party and calls it done.

That would have missed the point. So we built the SDKs around four commitments that matter more than any feature list.

Identity has to survive the app lifecycle. People use an app for weeks before they sign in. They sign out on shared devices. They hold more than one account. The SDKs keep anonymous and identified user information across launches, so a late sign-in can still be reconciled against everything that came before it. Logout resets identity, and switching accounts rotates it. That last detail is what stops a shared iPad from fusing two people into one customer record.

Consent has to be a gate, not a setting. Neither SDK collects before consent is granted, and withdrawal is treated as a real state change: pending events get cleared, identity resets, an active upload is asked to cancel. Consent that only stops future collection leaves data sitting on the device and in flight. That’s the version most teams discover during an audit.

Delivery has to assume the network will fail. Mobile clients lose connectivity, get force-quit, and interrupt uploads mid-flight. Pending events live in local SQLite so they survive restarts, move in compressed batches, and are retained and retried when delivery fails or an acknowledgement isn’t recognized. You can also inspect queue depth, dropped events, and the last delivery error. “The SDK said it sent it” is not the same as knowing.

The event has to carry its own context. Campaign parameters and referrer values get extracted from the links that actually drive installs, and every event carries app version, OS version, locale, timezone, and SDK version. That’s what lets you tell a regression in your app apart from a change in a campaign. Getting that distinction wrong costs real money.

What the SDKs don’t do

Purchase observations describe activity your app reported. On their own, they are not a verified record of money that changed hands.

Verified payments, refunds, renewals, and subscription status still require a server-side billing integration with Apple or Google.

I’d rather say that plainly than let an app-reported purchase pass for settled revenue. A number that quietly overstates revenue is worse than one that admits what it’s missing.

Why this belongs in the same graph

The temptation with mobile is to treat it as its own discipline. Its own tooling. Its own reporting.

That’s how you end up with an app dashboard, a web dashboard, and a CRM that agree on nothing.

App events belong in the same place as campaigns, calls, CRM records, orders, and closed revenue. A journey that starts on a phone and closes in your pipeline should read as one journey. A feature interaction three days before a subscription should be visible next to the campaign that created the account.

That’s the whole idea behind the Revenue Graph. And it doesn’t hold if a meaningful share of commerce happens outside it.

The browser was the first surface. The app is the next one. The agents are already on their way.

Setup details are on Convertmax for iOS and Convertmax for Android. If you want to talk through identity stitching or rolling this out across your stack, email help@convertmax.io.

Sources

• AppsFlyer: New data shows 32% of non-organic installs are misattributed with SKAdNetwork

• Digital Applied: Mobile App Marketing Statistics 2026 (ATT opt-in, probabilistic attribution)

• Redstag: What percentage of ecommerce sales happen on mobile devices (Statista, eMarketer, J.P. Morgan data)

• IMARC: In-App Purchase Market Size, Share & Forecast

• Apple Newsroom: New intelligence frameworks and advanced tools (June 2026)

• Android Developers: AppFunctions

That is where Convertmax fits.

Convertmax is a revenue attribution and intelligence platform. It connects first-party customer journeys with CRM activity, calls, commerce, and revenue events, so teams can see how a buyer moved from first touch to closed or paid revenue. For a RevOps team, it supplies the measurement layer behind reporting, funnel analysis, and channel decisions. It is not a replacement for the people who set strategy, own the forecast, or keep the revenue engine running.[1]

The short version: Convertmax directly supports attribution, journey reporting, CRM intelligence, and revenue analysis. It enables better RevOps decisions, but it does not take over RevOps strategy, forecasting, process ownership, or cross-functional leadership.

The real RevOps issue: the data does not travel together

Most go-to-market systems are perfectly capable within their own boundaries. The problem appears when someone asks a question that crosses those boundaries.

Take a closed-won deal. A prospect may have first arrived through paid search, returned later through an organic page, completed a form, booked a call, and then closed after a sales conversation. The ad platform may claim the conversion. Analytics may report a different source. The CRM only sees the deal after the lead is known. Finance sees the payment later still.

RevOps gets stuck reconciling the story after the fact.

Convertmax is designed to connect those events in a Revenue Graph. It keeps the relationship between marketing activity, web behavior, CRM records, conversations, commerce, and revenue intact. First-party tracking and identity stitching help tie an early anonymous visit to a later known contact and the eventual revenue outcome.[2]

That does not eliminate the need for RevOps. It gives RevOps a cleaner foundation for the work that matters.

How Convertmax maps to core RevOps responsibilities

The useful distinction is between what software can measure and what a RevOps team must decide, design, and lead.

How a revenue-intelligence layer maps to RevOps work

• Full-funnel revenue strategy — The platform connects campaigns, pages, calls, CRM activity, and revenue so teams can see the path to purchase. RevOps still sets market priorities, chooses the revenue motion, allocates resources, and makes the trade-offs.

• Reporting, forecasting, and KPI dashboarding — It supports reporting and KPI analysis with connected journey, pipeline, and revenue data. RevOps still defines KPIs, targets, forecast categories, review cadence, and the formal forecast model.

• CRM and tech stack — It syncs HubSpot revenue data, supports optional attribution writeback, and exports to BigQuery or Microsoft Fabric. RevOps still owns CRM architecture, permissions, automation rules, data governance, and workflow design.

• Growth experiments and funnel initiatives — It makes it easier to see campaign ROI, conversion paths, drop-off points, and the sources behind valuable customers. RevOps still designs the test, chooses the treatment, sets the decision rule, and carries out the rollout.

• Cross-functional work — It creates a shared, evidence-based view of how activity becomes pipeline and revenue. RevOps still sets agreements, manages handoffs, resolves conflicts, and leads change across the business.

The point is not to automate a RevOps role out of existence. The point is to stop making skilled operators build their revenue view from exports, screenshots, and competing platform reports.

1. Make full-funnel strategy measurable

A revenue strategy needs a feedback loop. Without one, it is easy to optimize for numbers that look good early in the funnel but do not turn into meaningful revenue. Lead volume can go up while pipeline quality goes down. A campaign can drive low-cost traffic that never gets past a sales conversation.

Convertmax collects first-party session and campaign data, connects the relevant CRM, commerce, and call systems, then applies multi-touch attribution to revenue outcomes. RevOps can use that view to ask the questions a channel report alone cannot answer: Which channels influence customers who close? Which pages help create qualified demand? Where do prospective customers disappear? Which acquisition sources produce higher-value customers?[1]

That can be especially useful when a company is expanding into a new region or launching a new motion. Convertmax will not pick the market or create the go-to-market plan. It can, however, give the team the same revenue lens across channels and campaigns. The difference between attention and actual commercial traction becomes much easier to see.

2. Improve reporting without pretending attribution is forecasting

RevOps reporting should explain what happened and help the next decision happen faster. A collection of disconnected dashboards usually falls short on both counts.

Convertmax brings campaign, channel, page, CRM, call, commerce, and revenue signals into the same attribution model. Its reporting is built to show the touchpoints influencing sales and to connect marketing activity to pipeline, orders, invoices, and payments, based on the sources a team has connected.[1]

But there is a boundary worth keeping clear: attribution reporting is not forecasting.

Convertmax can make the inputs to a forecast more reliable. It can show historical conversion patterns, channel quality, revenue events, and points of funnel leakage. RevOps still needs to define forecast categories, account for opportunity risk and seller judgment, set targets, and own the operating rhythm. A planning model or BI environment may remain the home of the official forecast.

That is not a limitation to hide. It is the correct division of labor.

3. Add a revenue-intelligence layer to HubSpot and the broader stack

For many revenue teams, HubSpot is the operational home of the customer record. It should stay that way. Convertmax is designed to complement HubSpot, not replace it.

The HubSpot integration syncs contacts, closed-won deals, and Revenue Hub objects such as quotes, invoices, payments, subscriptions, and line items. It can stitch the hubspot_contact_id to first-party sessions and campaign data. When attribution writeback is enabled, it can send first-touch and last-touch data, UTM history, attributed revenue, and touchpoints back to HubSpot contact and deal properties.[3]

That gives Sales useful journey context in the CRM, while RevOps and Marketing get a fuller view of how quote-to-cash activity relates to the marketing that preceded it. A deal record does not have to be the first point at which the buyer story becomes visible.

Convertmax also supports exports to BigQuery and Microsoft Fabric for warehouse and BI workflows. It offers Make.com as a bidirectional automation option, alongside webhooks for particular sources and integrations.[4]

The RevOps team still has the important work. It decides which fields are authoritative, what should be written back, how lifecycle stages are defined, and which automations should be allowed to change a record. Software can move data. Someone still has to make the system sensible.

4. Give growth experiments a revenue-grade readout

A landing page can improve its conversion rate and still hurt the business if the additional conversions turn into poor-fit leads. The same thing can happen when a campaign is evaluated on form fills rather than pipeline or paid revenue.

Convertmax helps teams look past the first visible metric. The platform is built to show which campaigns generate pipeline, which channels close customers, which pages convert, which touchpoints influence sales, and where customers drop out.[1] Because the events are tied to the same journey and revenue outcome, a team can evaluate an experiment against business results rather than click-through rate alone.

It does not run the test. It does not choose the headline, build the audience, or decide when to roll out a change. What it does provide is a much less foggy readout once the experiment is underway.

5. Give cross-functional teams one revenue story

Good RevOps does not require every team to use the same software. It requires people to make decisions from facts that fit together.

Finance needs paid-revenue visibility. Sales needs deal and conversation context. Marketing needs a defensible view of channel performance. Product and Operations need to understand where customers find friction. When those functions are looking at unconnected systems, alignment can turn into a debate about whose number is correct.

Convertmax connects the customer journey to those revenue signals in a single reporting layer. Teams using HubSpot can make attribution context available on contact and deal records. Teams with a warehouse can export event, contact, and revenue data to BigQuery or Microsoft Fabric for wider analysis.[3] [4]

The platform will not schedule the meeting, write the service-level agreement, or fix a broken handoff. That remains RevOps work. But it can give those conversations a common starting point: a connected account of what happened before revenue was created.

A sensible division of responsibility

Convertmax delivers the analytical foundation. RevOps owns the operating model built on top of it.

• First-party journey tracking and identity resolution — the platform. Lifecycle definitions, revenue processes, and data governance — RevOps.

• Multi-touch attribution across campaigns, calls, CRM, commerce, and revenue — the platform. Attribution policy, decision rules, and exceptions — RevOps.

• Reporting on channel performance, journeys, pipeline, revenue, and conversion paths — the platform. KPI selection, executive reporting, targets, and forecast methodology — RevOps.

• CRM intelligence, optional attribution writeback, warehouse exports, and selected automation paths — the platform. CRM design, automation logic, permissions, data quality, and change management — RevOps.

• Evidence for funnel leakage and channel quality — the platform. Experiment prioritization, execution, and rollout — RevOps.

The best first step is not to create a larger dashboard. Start with a meaningful question, such as: Which acquisition sources create paid revenue, not merely leads? Connect the systems needed to answer it. Validate identity keys, lifecycle definitions, and revenue events before the results make their way into executive reviews.

Once that first revenue story is trusted, the reporting can grow with it.

A platform like this is not the RevOps function. It makes the function more effective.

RevOps is a people-and-process discipline. Convertmax is analytical software that makes the data part of the discipline more useful.

For teams responsible for revenue operations, it can be the first-party attribution and revenue-intelligence layer across customer journeys, CRM records, calls, commerce, and revenue. That helps the team report with more confidence, investigate funnel performance, connect HubSpot to revenue outcomes, and give stakeholders a more defensible view of what is working.

The team still sets the strategy. It still owns the forecast. It still decides how Sales, Marketing, Finance, Operations, and Product will work together. Convertmax helps those decisions begin with a clearer picture of how the company creates revenue.

That category of platform — a connected measurement layer across journeys, CRM, and revenue — is what we built Convertmax to be. The useful test for any tool in this space is simple: does it leave strategy and process with RevOps, while making the revenue story harder to argue with?

References

1. Convertmax Platform: Revenue Attribution

2. About Convertmax: Building the Revenue Intelligence Layer

3. Convertmax HubSpot Integration

4. Convertmax Integrations

A buyer sees a founder post on Tuesday. The following week, a sponsored video shows up in their feed. Then a thoughtful connection request lands in their inbox. They visit the website, poke around the pricing page, and disappear. A month later, someone at the same company fills out a form after searching for the brand.

In most reporting stacks, LinkedIn gets little or no credit for that deal. Branded search or direct traffic gets it instead.

That isn’t really a LinkedIn problem. It’s a measurement problem.

For a B2B business, LinkedIn is not one channel. It’s three related commercial motions: organic visibility, paid distribution, and outbound relationship building. Each produces a different signal. Each can move a buyer closer to a conversation. And each gets flattened when the only question being asked is, “What was the last thing they clicked?”

Attribution is not a dashboard problem. It is the revenue-intelligence layer that connects exposure, engagement, identity, opportunity, and outcome.

Get that layer right and LinkedIn does more than look better in a monthly report. Marketing makes better content decisions. Sales has more context before reaching out. Paid spend gets judged on opportunity quality, not just lead volume. Leadership gets a clearer read on where demand is actually coming from.

LinkedIn creates research before it creates clicks

A buyer doesn’t have to click a post for it to matter. They might read it in their feed, look up the author later, visit the company site from a bookmarked tab, or send it to a colleague who eventually becomes the known contact in the CRM.

That is normal in B2B. It is especially normal in a longer sales cycle.

LinkedIn describes a buying committee as a group of stakeholders responsible for researching, evaluating, and selecting a vendor. Those groups typically include around six to ten people, often across finance, technical, management, and operational roles.[4] One person may engage with a post. Someone else accepts the outbound request. A third books the demo. The person who signs the agreement may not have clicked a LinkedIn link once.

Last-click reporting gives a very clean answer to a very incomplete question. It tells you where the final observable event happened. It doesn’t show the sequence that made that event possible.

LinkedIn’s conversion reporting is useful for running LinkedIn ads, but it also has boundaries. For most conversion types, its default is a last-touch model that credits the most recent ad click or view within the chosen conversion window.[3] That is a sensible way to operate an ad account. It is not a complete picture of a multi-person buying process that plays out across social, search, email, direct visits, sales conversations, and time.

The answer is not to award LinkedIn credit for every closed deal that follows a post. That is just a different kind of bad reporting. The answer is to place LinkedIn activity in the same record as first-party web behaviour, CRM milestones, and revenue.

Outreach and marketing are usually working the same deal

The usual operating mistake is to treat a founder’s content, a paid campaign, and an SDR’s connection request as separate activities with separate scorecards. From the buyer’s perspective, they can be part of the same conversation.

Marketing publishes a strong opinion on a problem the market is trying to solve. Paid media gets that idea in front of the right account set. Sales follows up with a useful note after the account has already seen the company a few times. The prospect researches quietly. When a meeting finally gets booked, the visible conversion bears little resemblance to the activity that built familiarity.

Without shared attribution, every team optimizes for the only signal it can see.

Narrow report versus revenue-connected model

• Organic LinkedIn — A narrow report rewards impressions, reactions, and follower growth. A revenue-connected model can show which themes drive qualified site activity, known demand, and assisted pipeline.

• Paid LinkedIn — A narrow report rewards platform conversions and cost per lead. A revenue-connected model can show which audiences and creative lead to qualified opportunities and revenue.

• Outbound LinkedIn — A narrow report rewards acceptance and reply rates. A revenue-connected model can show which outreach cohorts produce legitimate engagement, meetings, and opportunity progression.

Those measures should not be collapsed into one number. A popular post can be good for awareness and poor for lead generation. A paid campaign can produce fewer form fills but better opportunities. A connection request can start a real relationship without generating an immediate site visit.

The point of attribution is to keep those distinctions intact while showing how the motions work together. The organic, sponsored, and outbound framework is a useful way to do that.[1]

The three questions your model has to answer

A usable LinkedIn attribution model should answer three business questions. Not fifty. Three.

1. What created the first meaningful signal?

First-touch reporting helps identify the activity that introduced a known buyer or account to the company. That may be an organic article, a sponsored video, an event promotion, or a resource in an outbound message.

That first touch matters because it tells you which ideas and audiences are putting you on the radar. It should not be used to claim that the first touch, by itself, caused the revenue outcome. It almost never did.

2. What moved the buyer forward?

The middle of the journey is where LinkedIn tends to vanish from conventional reports.

Someone reads a point of view. They see a retargeting ad a few days later. They accept a connection request. They click a useful guide in a follow-up message. None of those actions may count as a conversion. They can still help explain why an opportunity progressed.

That is the case for multi-touch attribution. Rather than acting as if only the first or final interaction mattered, multi-touch models assign clearly defined credit across a sequence. A linear, position-based, or time-decay model can all be useful. What matters is that the business states the rule, applies it consistently, and understands that the model is a decision tool, not a truth machine.

3. What produced qualified revenue, not just activity?

This is the real test. LinkedIn should not be judged only on clicks, cost per lead, or even booked meetings. It needs to be connected to qualified meetings, opportunities, pipeline, closed-won revenue, and time to conversion when the sales cycle is long enough to make that meaningful.

LinkedIn supports several conversion-data sources, including Conversions API, the browser-based Insight Tag, CRM-connected data, and CSV uploads.[2] That gives paid teams useful options for optimizing inside Campaign Manager. A broader revenue model still has to reconcile those platform signals with first-party analytics and CRM outcomes.

The numbers won’t match perfectly. They shouldn’t. Platforms, web analytics tools, and CRMs have different identity rules, lookback windows, and credit logic. The mistake is not the difference. The mistake is refusing to explain it.

Treat LinkedIn as three sources, not one blurry source

The first implementation rule is straightforward: separate the motions at the source.

A founder article might be marked organic_social. A sponsored campaign should be paid_social. A resource sent in a one-to-one follow-up belongs in outbound_social. Every program also needs a campaign name that makes clear what it is trying to do, for whom, and when.

Tracking fields that keep the motions separate

• Source — Example: linkedin. Keeps the platform consistent in reporting.

• Medium — Example: organic_social, paid_social, or outbound_social. Separates content, advertising, and sales outreach.

• Campaign — Example: 2026q4_revenue-intelligence. Ties activity to a stated commercial initiative.

• Content — Example: founder-post-01 or sdr-resource-a. Shows which asset or message earned engagement.

• CRM campaign — Example: the same canonical campaign ID. Creates a durable bridge from interaction to opportunity.

This is not glamorous work. It is foundational work.

The tracking has to reach further than URLs, too. Organic posts and paid campaigns need their platform-level performance records. Outreach systems need to record request date, owner, account, persona, campaign, message variant, acceptance, and reply. The site needs first-party event capture for meaningful actions: form starts, resource downloads, demo requests, pricing-page views, booked meetings. The CRM needs to carry lead, account, opportunity, and revenue events forward.

If those records do not connect, the executive report is built out of disconnected anecdotes.

Measure what you know. Label what you infer.

A mature attribution program does not manufacture certainty.

If a prospect receives a connection request and then visits the site anonymously, you cannot honestly claim that a specific person visited unless a legitimate first-party identity event later supports that link. You may have a useful signal. You do not have a named-person fact.

That distinction matters.

Evidence levels and what you can conclude

• Direct — Example: a recipient clicks a clearly tagged resource in a follow-up message. Appropriate conclusion: the person engaged with that resource.

• Consented identity join — Example: a later form submission or meeting booking connects eligible first-party sessions to a CRM record. Appropriate conclusion: the known journey includes earlier verified interactions.

• Cohort signal — Example: accounts in an outreach wave show greater aggregate site activity after launch. Appropriate conclusion: the cohort may be associated with more research; it does not identify an individual visitor.

• Inference only — Example: an anonymous visit happens after a connection request is sent. Appropriate conclusion: do not make a person-level claim.

This is partly about privacy. It is also about judgement. A smaller set of cleanly linked journeys is much more valuable than a huge spreadsheet of guessed identities.

LinkedIn’s own conversion guidance makes the data-source question plain. Browser tags, server-to-server connections, CRM integrations, and uploaded data differ in reliability, data types, and setup requirements.[2] Measurement architecture is not a checkbox. It is a design decision that should involve marketing, sales, operations, and the people responsible for consent and data governance.

Build the dashboard around decisions, not reporting theatre

The best LinkedIn dashboard is not the one with the most widgets. It is the one that helps each team make the next decision.

Dashboard measures by team decision

• Content — Decision: what should we publish again? Measures: profile activity, saves, tracked sessions, identified demand, and assisted pipeline by theme.

• Paid media — Decision: where should spend move? Measures: qualified lead rate, cost per opportunity, pipeline, revenue, and creative performance.

• Sales and SDRs — Decision: which outreach is earning a response worth pursuing? Measures: requests sent, acceptance rate, reply rate, explicit resource engagement, meetings, and opportunities.

• Leadership — Decision: is LinkedIn creating profitable demand? Measures: sourced and influenced pipeline, closed-won revenue, cost per opportunity, time to conversion, and model comparison.

A sequence view is often the most revealing: exposure to content, sponsored engagement, outbound touch, known site activity, meeting, opportunity, revenue. Not every record will have every event. That is fine. The purpose is to make the observed journey available for analysis, not to force every buyer through a pre-drawn funnel.

Start small and make it defensible

Do not begin with a complicated attribution model and a six-month instrumentation project. Begin with a small scope that can withstand scrutiny.

Define the three LinkedIn motions. Standardize campaign naming and URL parameters. Agree on a short event dictionary. Use the same campaign IDs in marketing systems and in the CRM. Then pick one question that would actually change a decision. Perhaps it is whether a certain account segment, content theme, or outreach sequence is generating qualified pipeline.

Once that is working, add more sophisticated views. Compare first-touch, last-touch, and a shared-credit model. Review the results with sales and marketing together. When platform conversions and CRM outcomes disagree, look at timing, identity, and data-source differences before writing off either system.

That is when attribution stops being a retrospective justification exercise. It becomes a learning system.

LinkedIn should not be expected to carry an entire sales cycle by itself. It should not be dismissed because the final conversion happened somewhere else, either. It is where professional attention, credibility, research, and relationships often accumulate before demand becomes visible.

The teams that can connect those signals to the CRM and revenue record will spend smarter, equip sales better, and understand LinkedIn’s real economic role. The work is infrastructure. In a market where everyone says they want revenue intelligence, that infrastructure is the advantage.

References

1. LinkedIn Attribution: Connecting Organic, Sponsored, and Outbound Activity to Revenue

2. Get started with LinkedIn Conversion Tracking

3. LinkedIn conversion attribution model

4. What Is a Buying Committee?

That is easy to picture when the agent is hunting down a pair of shoes. It gets more interesting when a procurement agent renews a SaaS tool, a logistics agent purchases cold-chain data midway through a shipment, or a software-building agent buys a domain, hosting and an API subscription to finish the job it was given.

The payments industry is moving in that direction. Mastercard launched Agent Pay in 2025, then introduced Agent Pay for Machines in June 2026. Visa is rolling out Visa Intelligent Commerce and has announced work to bring Visa payment capabilities into OpenAI experiences. Google’s open Agent Payments Protocol, or AP2, has pulled card networks, payment providers and technology companies toward a shared approach for agent-led transactions. [1] [2]

That does not mean every chatbot can now roam the internet with your personal Visa or Mastercard. Thankfully. We are still early, and the real story is not giving an agent a card in the first place.

It is about giving an agent a controlled right to spend through cards, tokenized credentials, corporate virtual cards, bank-account rails, stablecoins and other methods. The card is the rail. The valuable part is the permission layer around it.

Agentic payment is delegated purchasing authority, not autonomous access to a wallet.

Checkout turns into a policy decision

Digital commerce spent years trying to make payment disappear. Cards on file, wallets and one-click checkout worked because the buyer was assumed to be right there, identifiable, looking at the order.

An agent changes that. It may find an offer, build a cart and ask to pay while its owner is asleep. Or while the employee who set it up is in a meeting. Or after the person who made the original request has forgotten about it entirely.

So the question changes too. It is no longer just, “Is this card valid?” It becomes, “Was this agent allowed to make this purchase, from this merchant, at this price, under these conditions?”

A chat transcript is not enough. “Get me running shoes” is not a good audit trail for a $600 order from a retailer the customer has never used. The system needs to know the product, total amount, merchant, delivery terms, timing, payment method and the boundaries the owner set.

AP2 calls the evidence behind that decision a mandate. In a human-present transaction, the user gives the agent an initial instruction, looks over the cart and approves the final order. In a delegated transaction, the user can set the rules in advance: buy concert tickets when they go on sale, but only in these sections, only before this date, and never above this price. The signed mandate is meant to tie the authority to those conditions and preserve a record from intent through checkout and payment. [3]

Visa and Mastercard use different labels, but they are heading toward the same basic shape. Visa talks about spending limits, merchant-category restrictions, approval thresholds and agent identity signals. Mastercard talks about registered agents, tokenized credentials and verifiable intent backed by explicit consent. [1] [2]

That is the new checkout. Not a button. A policy engine.

What an agent payment flow actually looks like

The glossy version is, “Tell an agent what you want and it buys it.”

The useful version is a bit more careful.

• 1. Define the job — A person or business asks an agent to buy something or finish a bounded task. Check: category, budget, preferred merchants, location, timing and whether it may act without another prompt.

• 2. Create authority — The instructions become a purchase policy or signed mandate. Check: who approved it, which agent can use it, when it expires and what needs a human exception.

• 3. Search and assemble — The agent compares options and builds a proposed cart or transaction. Check: product fit, price, stock, total cost, delivery, cancellation and return terms.

• 4. Approve or validate — The user signs off on the exact cart, or the system checks it against pre-approved rules. Check: amount, merchant, category, date and quantity stay within policy.

• 5. Present payment — The agent uses a tokenized or scoped payment credential on the relevant rail. Check: the credential is valid for this agent, task and transaction, instead of exposing a reusable card number.

• 6. Authorize and fulfill — Merchant, processor, issuer and network handle authorization and fraud checks. Check: agent identity, user intent, risk signals, receipt, delivery and a record for reconciliation or disputes.

Each player only sees part of the deal. The agent needs enough room to do the job. The merchant needs to tell a real shopping agent apart from a scraper, an abusive bot or a fraud attempt. The issuer still needs to decide whether to authorize the charge. The customer needs a receipt, an explanation and an easy way to stop or dispute a purchase.

Visa’s Trusted Agent Protocol is directed at the merchant side. It uses signed information that is specific to the merchant and the stated purpose, time-bound, and intended to resist replay. The merchant can receive the agent’s stated intent, selected customer-recognition data and payment information appropriate to its own flow. [5]

But this part is worth underlining: agent identity is not customer authority. Knowing that a request came from a registered agent is useful. It does not prove the customer wanted that item from that seller at that price. A solid payment design needs both proofs.

There are two ways to approve an agent purchase

The first is familiar: human in the loop. The agent researches, negotiates or fills the cart, then puts the finished order in front of the person for approval. That should be the default for high-value, hard-to-reverse or unusually personal purchases. Travel. Financial products. Medical supplies. Gifts. Anything that starts a recurring commitment. Anything likely to cause regret.

The second is delegated approval. Here the human approves the rules, not every individual charge.

“Reorder printer toner from approved suppliers when inventory drops below 10 units, up to $300 per month.”

“Book the usual hotel near the client office if the nightly rate is under $275.”

“Buy the ticket if it matches the price and seating rules I already set.”

That is where agents earn their keep. No one wants a push notification for every low-stakes, repeatable purchase. But delegated approval only works when the permission is narrow enough to mean something and visible enough to manage.

Here is the control model I would expect serious teams to ship.

Control model for serious teams

• Per-transaction limit — Example: no purchase over $150 without confirmation. Why: a bad decision stays small.

• Time-boxed authority — Example: permission ends after 72 hours or one completed order. Why: less standing access; fewer forgotten permissions.

• Merchant or category allowlist — Example: buy office supplies from named vendors only; no cash equivalents, gift cards or gambling. Why: “buy something useful” stops being dangerously vague.

• Budget and velocity caps — Example: maximum $1,000 per month and five purchases per day. Why: contains loops, compromised agents and faulty instructions.

• Exact-cart approval — Example: require a signed approval once the final price, tax and delivery terms are known. Why: keeps a human checkpoint for decisions that deserve one.

• Step-up authentication — Example: ask for a passkey or biometric confirmation when an exception appears. Why: confirms that a real person, not a prompt or a hijacked session, expanded the authority.

• Kill switch and logs — Example: revoke the agent’s credential immediately and keep a readable decision record. Why: makes recovery possible after something goes wrong.

A corporate agent should not be handed a general-purpose card number in a prompt, a database field or a tool configuration. That is credential sharing with fancier language. Give it a limited-use payment instrument, a budget and a revocable policy instead. Visa describes tokenized credentials and purchase-intent capture in its developer materials. Mastercard’s program is built around agentic tokens, registered agents and controls linked to verified intent. [2] [6]

The unglamorous limits still matter most

There is real momentum here. There is not a universal, settled operating model.

Coverage is patchy. The agent platform, the issuer or credential provider, payment network, processor, merchant and merchant experience all need to line up. Visa says Intelligent Commerce is still being developed and deployed, and that not every described feature may appear in the final product. Mastercard is working with a wide partner group. That is meaningful progress. It is not universal acceptance across the web. [1] [4] [7]

An approved card charge does not mean the agent made a good choice. An agent can misunderstand a request, follow hostile content on a webpage, invent a constraint or simply optimize for the wrong thing. Payment controls limit the damage. They do not make a weak buying agent suddenly discerning. Good product data, constrained tools, confirmation rules and hard testing still matter.

Prompt injection now has a spending consequence. If an agent can browse untrusted pages and call a payment tool, a malicious instruction embedded in a page is not just an information-security problem. It could become an order. Treat web content as untrusted input. Keep payment authority separate from browsing context. And enforce policies outside the model, not through a hopeful instruction that says, “Please be careful.”

Disputes have not gone away. The card system already has chargebacks, fraud monitoring and issuer controls. Agentic commerce adds more actors to the chain: the user, agent provider, merchant, merchant agent, credential provider, issuer, network and orchestration layer. AP2 names authorization, authenticity and accountability as the problems its shared protocol is trying to address. A cryptographic record should help. It will not settle every argument over wrong goods, altered instructions or poor service. [3]

Payment is only one part of commerce. Tax, identity checks, age restrictions, delivery, returns, subscriptions, contracts and customer support remain stubbornly human problems. An agent getting a payment approved is not the same as a merchant delivering a good outcome.

Privacy calls for restraint. Agents may know a lot about a person or a business. A merchant does not need the buyer’s full reasoning history or every personal preference to fulfill an order. Share the minimum needed to complete the transaction. Keep payment credentials and purchase history compartmentalized.

Where the first real value may show up

The early wins will not be agents with unlimited buying power. They will be agents with small, specific authority doing boring work well.

Recurring consumables. Approved B2B procurement. Travel inside a policy. Software services purchased by a build or operations workflow. Small machine-to-machine payments for data, compute, API calls or logistics events. Mastercard’s Agent Pay for Machines is aimed at high-frequency, low-value and programmatic transactions, with settlement across cards, accounts and stablecoins. [4]

Consumer shopping will get the attention because it is easy to see. Business workflows may be where the economics land first. A person can spend ten minutes comparing a jacket. A business cannot spend ten minutes reconciling every $2 service call in an automated supply-chain workflow.

For merchants, the question is not simply whether to accept “AI payments.” The real question is whether the merchant can recognize a legitimate agent, provide reliable product and policy data, return a structured offer, honor a documented authorization and support the customer after the order. Block every bot and you will miss real demand. Trust every bot and you will invite a mess. The useful middle ground is authenticated, attributable automation.

For product teams, the question is simpler: what is the smallest permission that lets this agent do something genuinely useful? Start there. Make the authority easy to inspect. Build the exception path before the autonomous path. And make the system capable of explaining what it bought, why it was allowed to buy it and how to undo it.

The payment rails are coming into view. The advantage will not go to the company that gives an agent a credit card. It will go to the company that gives the agent just enough authority to help, and no more.

References

1. Visa Intelligent Commerce

2. Mastercard unveils Agent Pay, pioneering agentic payments technology to power commerce in the age of AI

3. Powering AI commerce with the new Agent Payments Protocol (AP2)

4. Mastercard launches Agent Pay for Machines to unlock super-fast, always-on payments

5. Visa Trusted Agent Protocol

6. Introduction to Intelligent Commerce

7. How Visa is Partnering with OpenAI to Build the Future of Agentic Commerce

An AI assistant finds a customer, pulls an order, checks inventory, changes an address, creates a return, issues a refund, applies a discount, then drops a note in the CRM. One conversational request. Seven systems. Everyone is impressed.

Then comes the question that matters when the demo has to become a real product:

What, exactly, was the agent allowed to do?

Most teams answer with a list of integrations. It can access Shopify. It can access the OMS. It can access the customer-service platform. It can access the CRM.

That is not an answer. It is a map of the blast radius.

In commerce, access is easy to mistake for usefulness. A broad API token makes an agent look capable because it can reach many systems and finish many flows. But a live customer journey is not a benchmark. It involves money, inventory, delivery promises, customer data, and the occasional irreversible mistake.

The agent that can do everything is rarely the first agent a business should trust.

A Customer Request Is Not a Blank Cheque

Consider a customer who writes:

“My order arrived late and the blue jacket does not fit. Can you help?”

A helpful agent needs to understand the request, find the order, check the return window, see whether another size is in stock, and explain the choices. Up to that point, the work is largely informational.

The last mile is different. An exchange can reserve inventory. A refund moves money. A replacement shipment creates a fulfilment obligation. A discount affects margin. An address change can send a package somewhere else.

Those are not just tool calls. They are business decisions with different owners, rules, and consequences.

The usual shortcut is to give the assistant a general-purpose commerce credential and tell it to use good judgment. It feels flexible. It also asks a language model to turn a messy, ambiguous message into a series of material changes across core business systems.

That is where agent design gets tangled up with permission design.

An agent may need to reason across a lot of context. It should not inherit every action that context makes possible.

OWASP calls this failure mode excessive agency. It describes the damage that becomes possible when an AI system has more functionality, permissions, or autonomy than its job requires. The remedies are straightforward: offer fewer tools, keep them narrow, enforce least privilege in downstream systems, and require approval for high-impact actions.[1]

For commerce, there is one further idea worth adopting.

Permission should describe a specific business moment, not a standing technical relationship.

The Useful Unit of Permission Is an Intent

Traditional integrations are built around systems.

The order platform gets a service account. The CRM gets a service account. The helpdesk gets a service account. The agent works with whatever those accounts can reach.

That made sense when the caller was a human employee or a deterministic workflow. It is a poor fit for an AI system that interprets fresh language every turn, reads untrusted content, and chooses its next tool as it goes.

The permission needs to be more exact:

On behalf of:  Jordan Lee
For:            Order #10482
May:            prepare an exchange for size M
Only if:        item is eligible and size M is available
Cannot:         issue a refund, change the shipping address, or add a discount
Expires:        when the support session ends
Requires:       Jordan's confirmation before shipment is created

That is not a role. It is a delegated, time-bounded mandate.

The distinction can sound a little fussy until the agent receives a vague request, an incomplete request, or a message shaped by something hostile that it has read. A support agent that can retrieve order status is useful. One that can quietly turn a late-delivery complaint into a refund, a discount, and a replacement shipment has been given authority that does not follow from the customer’s words.

The customer did not ask the business to make every possible remedy available. They asked for help.

Permission Has Five Parts

A commerce agent needs more than a generic “can call this API” check. Before an action is accepted, the business should be able to answer five questions.

Five questions before an action is accepted

• Who is acting? The agent’s identity and the user, employee, or workflow it represents. Example: a returns assistant acting for Jordan Lee, not a shared admin account.

• What is it acting on? The exact customer, order, cart, product, or case in scope. Example: Order #10482, not every order linked to the customer record.

• What may it do? One defined operation rather than a broad system capability. Example: create a return label, not “manage returns.”

• Within what limits? Monetary, quantity, geography, and policy boundaries. Example: one unused item under the published return policy.

• When is it valid? Time, session, and workflow state. Example: valid for the current support conversation, before the label is issued.

That separation is useful.

The model can conclude that an exchange seems like the right next option. It can explain why. It can ask the customer which size they want.

The commerce system should decide whether that exchange is actually permitted at that moment, for that item, under that policy, with that inventory position.

That decision should not ride on whether the model phrased its tool call convincingly.

NIST’s AI Agent Standards Initiative identifies agent authentication and identity infrastructure as a research focus for secure human-agent and multi-agent interactions.[2] That attention is well placed. When agents act for people, identity is not an implementation footnote. It is where the transaction begins.

Broad Tools Turn Ordinary Requests Into Security Problems

Here is the sort of tool list an operations agent is often handed:

get_customer(customer_id)
get_order(order_id)
update_order(order_id, fields)
issue_refund(order_id, amount)
create_discount(customer_id, value)
run_sql(query)

It is convenient for an engineer. It is a poor interface for an agent.

update_order carries hidden power. Which fields may change? Can the agent alter an address after fulfilment? Tax? The product itself? Does the update notify the customer? A tool name that hides several business decisions asks the model to infer rules that the software should enforce.

run_sql is worse. It may have a place for a human analyst in a controlled environment. It should not be part of a customer-facing assistant’s normal vocabulary.

The answer is not a longer system prompt. It is capabilities that carry their own boundaries.

Broad tool versus agent-ready capability

• update_order(order_id, fields) becomes request_address_change(order_id, new_address) with fulfilment-state validation.

• issue_refund(order_id, amount) becomes propose_refund(order_id, eligible_line_items) followed by confirm_refund(refund_id).

• create_discount(customer_id, value) becomes offer_service_recovery_credit(case_id) with a policy-defined ceiling.

• get_customer(customer_id) becomes get_support_context(order_id) that returns only the fields needed for that case.

• run_sql(query) becomes a purpose-built reporting or lookup action with fixed, reviewable inputs.

The assistant has not become less helpful. The business has become more explicit.

A narrow capability can validate dates, check stock, enforce policy, apply tax logic, record the reason code, and ask for confirmation. It can explain a denial in a way an operator understands. It can leave behind an audit trail that answers more than “the API returned 200.”

A generic API call cannot do that unless every one of those concerns is rebuilt around it.

The Agent Should Assemble an Option, Not Invent a Commitment

This lands hardest in the customer journey.

There is a real difference between an agent that says, “I found your order. The blue jacket is eligible for a free exchange, and medium is available. Would you like me to send it?” and an agent that creates the replacement shipment because it has decided that is the helpful thing to do.

The first agent removes work. The second one makes a commitment.

Customers change their minds. They may prefer a refund. They may need a different address. They may want to wait for another colour. They may simply have been asking about the policy.

The agent should do the expensive reasoning and the mechanical preparation. The customer should still be part of the moment when intent becomes a commercial act.

This does not mean putting a human approval gate in front of every keystroke. That would make the product miserable. It means putting the right gate at the point where the business takes on a new obligation or changes a customer’s rights.

The pattern is simple:

UNDERSTAND → RETRIEVE → PREPARE → SHOW → CONFIRM → COMMIT

The first four steps can be highly automated. The last step should match the consequence.

Filtering products by a customer’s stated preferences might not need any extra approval. Submitting a financed order, shipping a replacement, or issuing a material refund should make the scope, price, and outcome visible before it is final.

Anthropic makes a related point in its guidance on agent systems. Use the simplest pattern that can solve the task, reserve agents for work that needs flexible decision-making, and use guardrails and stopping conditions when autonomy is necessary.[3] For commerce teams, the practical question is blunt: do we need an agent here, or do we need a well-designed workflow with a language interface?

Often, the answer is both. Let the model handle the messy conversation. Let the workflow handle the commitment.

Better Permissions Produce Better Products

There is an obvious objection. Narrow capabilities take effort to design. They force teams to name the business operations hiding behind an admin interface. They expose policy exceptions that were previously handled through experience and improvisation.

Exactly.

That is not security paperwork. It is product work.

When a team defines request_purchase_confirmation, it has to decide what the customer should see before purchase. When it defines offer_service_recovery_credit, it has to decide which cases qualify and how much discretion makes sense. When it defines create_exchange, it has to decide when stock is reserved and what happens if that stock disappears.

Those questions exist whether an agent is involved or not. Agents just make them hard to avoid.

This is why agentic commerce is not a race to give a chatbot a bigger set of credentials. It is a forcing function for cleaner service boundaries, clearer customer promises, and smaller, more legible business actions.

The best future interface may not be one bot with access to every part of the company. It may be a collection of agents, each carrying a small, temporary mandate and making its work easy to inspect.

Design for Delegation, Not Access

If you are adding an agent to a commerce workflow, start with the commitment, not the model.

Ask what the agent should be able to prepare. Ask what it should be able to explain. Ask which customer or operator needs to see the final decision. Then make the action that changes the world small enough that a policy engine, a human, and an auditor can all understand it.

It will feel a little less magical in a demo. It will be far more useful on a busy Tuesday, when the customer’s message is vague, inventory is moving, a promotion is live, and no one wants to explain why an assistant issued three refunds overnight.

That is the standard worth building toward:

Give agents enough context to help. Give them enough authority to prepare. Give them only the permission required to commit.

The goal is not a bot with the keys to the building.

It is a service that knows which door to open, for whom, and for how long.

References

1. OWASP LLM06:2025 Excessive Agency

2. NIST AI Agent Standards Initiative

3. Anthropic: Building effective agents

It is impressive. It is also a brittle way to build software.

A web page was made for people. We pick up meaning from layout, labels, copy, colour, and years of learned habits. An agent working from screenshots, scraped DOM elements, and simulated clicks has to guess its way through the same experience, one uncertain move at a time. Move a button. Change a label. Run an A/B test. Add a modal. The agent is back to figuring it out.

That is why Model Context Protocol (MCP) matters. It is also why WebMCP may matter more than many teams expect.

MCP is not just another way to put a chatbot in a product. It is an integration contract for a world where software agents need controlled access to the data and actions that run a business. WebMCP brings that idea into the browser, where the customer, the agent, and the product experience are all in the same room.

The practical split: MCP connects agents to services and systems. WebMCP lets a web application state what can happen in the current interface, with structured inputs, structured outputs, and shared, visible context.

If you build ecommerce, customer platforms, internal operations software, or real-time systems, this is not a standards debate for some future quarter. Architecture is being set right now.

Agents are being asked to work through pixels

Most agent workflows begin with the same trade-off: hand the model a browser and teach it to act like a person. It looks at a page, finds an element, clicks it, waits, then does it again. That is useful. It lets an agent work on an existing site without a special integration.

But “works” is carrying a lot of weight.

A person checking out on a retail site knows that “Continue” might mean shipping details, payment details, a carrier offer, or final submission. They understand it from the page around it. An agent sees a possible next move. It might be right. It might also be thrown off by a promotion, a hidden field, an altered class name, or an ambiguous call to action.

The result is an expensive loop: more prompting, more retries, more exception handling, more monitoring. And still no strong assurance that the system has done what was intended. Everything can seem fine until a small front-end release breaks the path.

A clever browser automation layer is not the same thing as a durable integration model.

MCP makes business capabilities usable, not just visible

MCP is an open protocol that connects language-model applications with external data sources and tools. An AI application acts as a host, connects through a client, and reaches a server that can expose resources for context, prompts for reusable workflows, and tools for actions.[1]

That sounds technical, because it is. The business value is simpler: rather than teaching every AI product its own custom way to talk to your order system, product catalogue, analytics stack, CMS, support platform, or operations software, you expose the capability once through a standard interface.

The old question | The better question

• Can the agent find the correct screen and click the right button? — Can it call a clearly defined capability with approved inputs?

• Did the agent scrape enough page text to understand the customer? — Can it retrieve the permitted customer, order, inventory, or product context?

• Will this automation survive the next interface redesign? — Is the business operation beneath it stable and versioned?

An MCP server can make an operation like get_inventory, create_return, quote_shipping, find_customer_order, or publish_campaign_draft available to an agent in a form it can reason about. The action has a name, a description, parameters, and a response. It is not trying to decide what an unlabeled icon was meant to do.

That is especially relevant in commerce. Agentic commerce will not be won by the model that clicks through the most screens. It will be won by businesses that can expose trustworthy product, pricing, availability, fulfilment, and service capabilities without handing broad, ungoverned access to a bot.

MCP brings another benefit that is easy to overlook. A tool is a promise. It makes a team decide what an action does, which data it needs, who can invoke it, what it returns, and when a human must approve. Those are useful decisions whether or not an AI agent ever calls the tool.

WebMCP handles the part APIs do not

An API or an MCP server can tell an agent that a product is in stock and add it to a cart. That alone does not solve the customer experience in front of it.

The customer may already be on a product configuration page. An assistant may be helping compare options in the browser. A complicated date picker, bundle builder, service-plan selector, or application flow may be on screen. The page has state and intent that a generic back-end action does not always carry.

WebMCP is a proposed browser-facing web standard that lets a site register JavaScript-based tools for AI agents. Those tools have natural-language descriptions and structured JSON Schema inputs. They are meant to be invoked in the very web interface where the user is working.[2]

Google’s Chrome documentation puts the improvement plainly: instead of asking an agent to inspect a button or field and infer its purpose, the site declares the purpose so it can be used correctly.[3]

A WebMCP-enabled site could expose a tool for:

Situation on the site | An agent-ready tool

• A visitor needs the right product from a large catalogue — filter_products or compare_products

• A flight, appointment, or delivery interaction has tricky date rules — select_available_time

• A customer needs help in a layered support flow — start_support_request

• A configurable product has interdependent options — configure_product

• A checkout needs a deliberate handoff — request_purchase_confirmation

The names are not the point. The site owns the semantics. It can use its existing validation rules, pricing logic, accessibility work, state management, and customer-facing interface, rather than hoping an outside agent interprets the page properly.

MCP and WebMCP are not rivals

It is tempting to call WebMCP “MCP in the browser.” That is close enough to be handy, but loose enough to lead to messy architecture.

MCP is a protocol for application-to-service connectivity. It is often the right choice when an agent needs controlled access to systems behind the interface or needs to work across several of them. WebMCP is a browser API proposal. It lets a web application expose tools from client-side code and keeps the agent, user, and page in a shared interaction space.[1] [2]

Use MCP when… | Use WebMCP when…

• The agent needs back-end data or business operations — The agent is acting inside an open web application

• The task crosses CRM, ERP, PIM, OMS, support, or analytics systems — Current page state and visible user interaction matter

• You need server-side authorization, audit trails, and lasting integrations — You need the site to express intent beyond what a DOM reveals

• The task can happen without a particular page open — The customer and agent should see and shape the work together

The useful implementations will use both. A commerce assistant might use MCP to look up eligible offers, inventory, and order status. In the browser, WebMCP could let it apply an approved filter, set a configuration, update a visible cart, or ask for confirmation before a purchase.

That is better than giving an agent broad credentials on one side and a mouse on the other.

This is a trust and control question, too

“Agentic” is sometimes treated as a synonym for taking people out of the loop. In most commercial and customer journeys, that is a mistake.

The better goal is to remove mechanical work while keeping intent, approval, and accountability in view. MCP’s specification calls for explicit user consent around data access and tool invocation, along with clear authorization interfaces.[1] WebMCP is built around shared browser context and includes an example of requesting user interaction for sensitive actions such as a purchase.[3]

That is worth protecting. A customer should see what an assistant selected, understand the total, correct an error, and deliberately approve the final commitment. An operator should know whether an agent merely drafted a return, issued a refund, or changed fulfilment. A business should be able to limit the tools an agent sees, the actions it can take, and the moments that require escalation.

Neither standard creates trust by itself. Vague tool descriptions, loose permissions, and hidden side effects are still bad design. But both encourage a more honest kind of agency: offer narrowly scoped capabilities, make inputs and outcomes clear, and keep consequential actions under the right level of control.

The near-term opportunity is not “add AI”

WebMCP is still under active development. Chrome lists it as an origin-trial technology, and the W3C Community Group report is explicit that it is not a W3C Standard.[2] [3] No one should hang a critical customer flow on a draft browser API alone.

Still, this is the right time to pay attention.

The work that prepares a product for WebMCP pays off whether browser support settles in six months or two years. Clean service boundaries. Explicit actions. Stable schemas. Clear validation. Permissions. Observable outcomes. Interfaces that say what they mean. That is not speculative work. It is the basis of good software and dependable AI integration.

Start with one frustrating workflow. In commerce, it might be product discovery, compatibility guidance, returns, order changes, or post-purchase service. Decide what data an assistant needs. Decide what it may do. Make the side effects obvious. Put a confirmation step around the actions that carry real weight. Then work out which capabilities belong behind an MCP server and which should be available in the browser through a WebMCP-style interaction.

The web is moving beyond pages that agents merely look at. The question is whether your business can explain itself, safely and precisely, to the software that will increasingly act for a customer.

References

1. [1] Model Context Protocol Specification, 2026-07-28

2. [2] WebMCP Draft Community Group Report, 26 August 2026

3. [3] WebMCP, Chrome for Developers

Ask an AI assistant for waterproof hiking boots in size 11, under $160, available this week.

It sounds like a search query. It is really a test of the merchant’s operating system.

To answer well, the assistant has to know what “waterproof” means in the catalog, whether size 11 is available right now, which variant meets the price constraint, what delivery can be promised, and where to send the shopper next. A polished product page cannot supply that answer by itself. Neither can a chatbot sitting on top of an old product feed.

This is the part of agentic commerce that tends to disappear beneath the excitement about models, interfaces, and assistant personalities. The constraint is usually more basic: can the business give software a trustworthy answer to a buying question?

That answer comes from the catalog.

Most commerce teams still treat the catalog as a presentation layer. It populates product pages, category grids, campaign emails, and paid-shopping feeds. That made sense when people did the comparison work. An agent changes the job. It must translate a human request into a viable offer, make a recommendation it can stand behind, and hand the buyer to a purchase path without making them start over.

For that, the catalog has to act less like a set of pages and more like a decision engine.

A title, a hero image, and a long description may attract a browser. They do not support a purchase decision. The meaningful unit is a live offer: a particular product or SKU with a current price, availability, relevant constraints, and a stable route to buy. SuggestAPI’s catalog-discovery checklist makes a similar practical case. A discovery system needs current, structured facts. It cannot safely infer them from a storefront built for visual browsing.

A live offer is the new atomic unit of commerce

A merchant can have strong merchandising and still fail this test.

Take a shoe catalog that returns a parent product when an assistant asks for a men’s waterproof boot in black, size 11. The product looks right. The assistant recommends it. The shopper reaches the page and finds size 11 sold out, black unavailable, and the sale price attached to another variant.

The recommendation was not just incomplete. It was commercially wrong.

For a person, that creates friction. For an agent, it erodes trust.

This does not mean opening every internal system to outside software. It means defining a trusted commerce contract. An assistant does not need direct access to the ERP, PIM, OMS, or pricing service. It needs an accurate, governed answer that reflects the commercial truth those systems produce.

That is a leadership choice before it is an integration project.

The work is making product truth usable

Catalog quality has always mattered. Agents simply expose its weak spots sooner.

People are very good at compensating for missing information. They can interpret a clumsy title, guess that “weatherproof” probably means “water resistant,” dig into a sizing guide, or call support when a compatibility claim feels vague. An agent should not make those leaps. It cannot do so reliably.

If a customer asks for a replacement filter that fits a specific appliance, compatibility must exist as a queryable relationship. If they need a gift delivered before Friday, delivery conditions cannot be buried in a support article. If a business customer needs a bulk pack, the minimum order quantity and pack size need to be part of the offer, not trapped inside a PDF.

The organizations that take this seriously will stop treating product data as back-office tidying. They will treat it as a revenue system.

That changes the questions a commerce leader asks. Do not ask whether the team has “AI-ready content.” Ask whether a machine can separate a product requirement from a marketing phrase. Do not ask whether every SKU is indexed. Ask whether the attributes that determine a purchase are indexed. And do not celebrate a chatbot answer until you know it survived the handoff to the store.

There is a useful divide here.

A catalog is ready for agents when the third column is true in the real questions shoppers ask. Not in a slide deck. In production.

Variant data is where the promise breaks

The most expensive catalog mistake is modeling the product at the wrong level of detail.

Buyers rarely want a generic item. They want the right version of it. Size, capacity, fit, color, material, voltage, handedness, country availability, compatible device, pack count, and delivery window are not decorative details. Often, they are the decision.

Yet many storefronts still hide this information behind selectors, merchandising logic, or page scripts. That is workable when a person has time to browse. It does not hold when an assistant needs to answer a constrained request in a few seconds.

That is why a broad “product search API” is not automatically a useful agent interface. When search returns a parent product and the buyer needs a qualifying variant, it leaves the agent to guess. Guessing is not a feature.

The remedy does not always require a replatform. Often it starts with agreement on the variant-level facts that determine purchase eligibility, followed by making those facts available in the discovery layer at the same freshness as the storefront. If the product team would hesitate to show an attribute in a checkout confirmation, an assistant should not use it as the basis for a recommendation.

The handoff is part of the recommendation

A correct answer can still create a poor experience.

Commerce teams often focus on discovery and treat the click-through as somebody else’s problem. That boundary no longer holds. If an agent says, “This is the one,” and then sends the customer to a generic category page, a broken product URL, or an unselected configuration, the shopper has to repeat the work. It feels like a bait and switch, even when nobody intended one.

The merchant should keep control of checkout, brand presentation, payment, policies, and the customer relationship. Agentic discovery does not require giving any of that away. It does require a dependable bridge from recommendation to a merchant-owned next step.

A strong handoff includes canonical product identity, a current route, and, where the platform permits it, enough state to resolve the recommended configuration. The customer should arrive at the answer, not at the start of another search session.

That is where agentic commerce stops being a novelty and starts becoming conversion infrastructure.

The catalog needs an owner, not another dashboard

It is tempting to hand this to an AI team. That would be a mistake.

No single group owns every truth required for a commerce recommendation. Merchandising shapes how products are grouped and explained. Operations owns inventory and fulfillment constraints. Data teams govern identifiers and feeds. Engineering owns interfaces and response time. Commerce leaders own the customer outcome and the revenue outcome.

An assistant exposes the gaps between those groups.

The practical response is not a committee that meets once a quarter. It is a shared definition of a live offer, clear ownership for each field, an agreed measure of freshness, and a response plan for recommendations that cannot be verified. The ambition is deliberately simple: reliable answers to high-intent buying questions.

Start with twenty of those questions. Use language that customers really use. Include the awkward requests: replacement parts, firm budgets, incompatible variants, delivery deadlines, regulated products, multi-pack orders, and out-of-stock substitutions. Run each question through the same path an assistant would use. Then follow every result through to the storefront.

The failures will be plain. Some answers will be too broad. Some rules will be stuck in copy. Some stock states will be out of date. Some URLs will send shoppers into a dead end. Each issue looks like a small catalog problem. Together, they are a revenue-system problem.

The brands that win will be easy for software to buy from

The next phase of commerce will not be won by the brand that announces an AI assistant first. It will be won by the brand whose offers are easiest for intelligent software to understand, verify, compare, and route into a transaction.

That demands more than searchable pages. It demands current product truth, explicit decision-level data, and feedback that shows where genuine buying intent runs into a weak answer.

Build that foundation and every future interface has something useful to work with: site search, a service agent, a marketplace integration, a shopping assistant, or an experience nobody has built yet.

So the first question is not, “Which AI assistant should we launch?”

It is, “Can our catalog give a correct answer when the buyer is specific?”

I’ve spent years watching revenue teams stare at dashboards. And honestly? It’s usually a frustrating experience.

You pull up a report, see a sudden 15% drop in conversions, and immediately ask the person next to you, “Why did that happen?” But the dashboard can’t answer that. It just sits there, flashing red numbers at you. So you start digging. You add filters, change date ranges, pull a second report, export it to Excel, and try to piece the story together yourself.

We realized we were forcing people to act like data scientists just to get basic answers about their own business.

That felt wrong. Revenue intelligence shouldn’t be a hunting expedition. It should feel like a conversation. That’s the exact problem we set out to solve with Max, the new AI analytics experience we just launched inside Convertmax.

We threw out the idea that you have to know which specific report holds the answer. With Max, you just ask. You type “Which campaigns generated the most attributed revenue last month?” or “Where exactly are people bailing out of the checkout funnel?” and Max hands you the answer. It pulls directly from your Convertmax data and gives you the chart, the ranked table, or the summary you actually need.

But getting that first answer is rarely the end of the story.

Usually, the first answer just makes you ask a better question. If Max tells you paid traffic revenue is down, your next thought is naturally going to be about which specific channels caused the drop. We built Max to remember what you were just talking about. You don’t have to start over and rebuild a query. You just say “break that down by channel” or “compare it to the previous period.” It keeps the context, highlights the supporting metrics, and lets you follow your intuition until you find the root cause.

Then we hit another realization during development. Sometimes, you’re so busy running the business that you don’t even know you should be asking a question in the first place.

That’s why we built Max Brief. It runs in the background for our Growth, Pro, and Enterprise users, watching for weird spikes in search interest, drops in campaign efficiency, or sudden shifts in revenue. When it sees something significant, it flags it, ranks it by importance, and suggests the exact follow-up question you should ask Max to start investigating. It’s like having an analyst tapping you on the shoulder before a small issue becomes a massive headache.

Dashboards aren’t going anywhere. If you know exactly what metric you need to check every Monday morning, a dashboard is great. But when something breaks, or when you’re trying to uncover a new opportunity, you don’t need a static chart. You need to ask questions and get immediate, accurate answers.

Max is available in Convertmax today. Go pick a property, ask it your hardest revenue question, and see what happens.

This disconnect happens because most teams try to measure revenue using behavioral tools like Google Analytics. GA4 is fantastic for understanding how people navigate your website, but it is terrible at telling you what happens after they leave. It measures clicks, sessions, and form fills rather than actual money.

Your CRM tracks the financial reality of your business. It follows a prospect from their initial entry into your pipeline all the way to a closed-won deal. The CRM is where the actual dollars are recorded. If you want to know which marketing channels are generating revenue, not just leads, you have to look at your CRM data.

The Problem with the Standard Approach

The fundamental issue is that GA4 and your CRM speak different languages. GA4 sees an anonymous user who clicked an ad and submitted a form, while your CRM sees a named contact attached to an opportunity with a specific dollar value.

When you try to bridge this gap using standard integrations, things tend to break. Native connectors often fail to pass critical tracking identifiers. No-code automations like Zapier are fragile and can break silently when APIs change. Furthermore, custom builds require massive engineering resources to maintain.

This leaves revenue teams in a terrible position. Marketing is optimizing ad spend based on top-of-funnel conversions that GA4 can see, while sales is working leads in the CRM. Finance is looking at closed deals. Everyone has a different number, and nobody knows which marketing channels are actually driving profitable growth.

Building a Unified Data Path

The solution is not to force your CRM data into GA4, nor is it to dump all your GA4 data into your CRM. The real solution is to build a unified data path that sits above individual platforms.

This is exactly why we built Convertmax. We realized that to truly measure marketing ROI, you need identity resolution that connects anonymous website behavior to known CRM pipeline stages. You need bidirectional data flow, where offline events like closed-won deals are sent back to your analytics and ad platforms. This allows your ad algorithms to optimize for actual revenue rather than just cheap clicks.

Most importantly, you need a CRM-agnostic revenue model. Your attribution should not be locked inside a single tool. By connecting touchpoints, platforms, and revenue events into a single Revenue Graph, you get a clear, cross-system view of what actually drives revenue.

If you are tired of arguing over which dashboard is right, it is time to stop relying on fragile syncs. Connect your analytics to your CRM the right way, and start optimizing for the only metric that matters: revenue.

After years of building software for growing businesses, we saw the same problem repeatedly. Companies invest heavily in CRM systems, advertising platforms, e-commerce tools, call tracking, and analytics, yet they still cannot clearly answer which activities actually generate revenue. The foundation of digital attribution was collapsing even before AI entered the picture, leaving growth teams flying blind in a fragmented ecosystem. Anonymous visits, sales calls, and CRM deals live in isolated silos, making it impossible to connect top-of-funnel activity to closed-won revenue. Meanwhile, ad platforms grade their own homework, allocating spend based on self-serving, inflated metrics. Add in the death of third-party cookies and strict privacy laws, and the ability to track users across the web is completely broken.

We believe the next generation of business software is built around connected data and intelligent agents. Commerce is being rewired by autonomous AI agents that research, negotiate, and execute purchases for consumers and businesses, a shift that breaks the entire attribution model built for human clicks and cookies. AI agents like ChatGPT, Copilot, Perplexity, and Gemini now sit between brands and buyers. They research and convert in ways that are entirely invisible to legacy analytics tools like Google Analytics 4. When buyers become machines, the company that can still prove what drove revenue wins.

Those agents require a trusted, complete understanding of customers, touchpoints, and revenue, not isolated data silos. Every autonomous transaction requires a robust, first-party measurement infrastructure. Convertmax was created to become that intelligence layer. We are building a CRM-agnostic Revenue Graph that connects every customer interaction, marketing touchpoint, sales activity, and revenue event into a single source of truth. We are building a first-party platform that captures customer journeys on your own domain, connects anonymous to known visitors, and attributes revenue without moving data to match.

Our approach is built on five connected layers: Revenue Intelligence, Customer Analytics, Multi-Touch Attribution, Product Analytics, and First-Party Analytics. Together, they connect campaigns, channels, and pipeline activity to the revenue they influence. You can see how anonymous visits and sales conversations connect before a deal closes, spot where leads stall, and understand which behaviors create better opportunities.

Crucially, we are pioneering the Unified Conversion Protocol (UCP). This infrastructure separates true bot and agent traffic from human conversion reporting. It keeps human behavior in normal tracking flows without disruption, while passing rich agentic metadata only when an autonomous agent is identified. This is our moat: Agentic Attribution that makes invisible traffic visible.

By giving both people and AI agents access to accurate revenue intelligence, we enable businesses to automate decisions, improve customer acquisition, and maximize growth. We believe this shift toward connected revenue intelligence will become the foundational infrastructure for the next generation of AI-powered and agentic commerce applications. Built for the post-cookie and post-human-click era, Convertmax is the definitive attribution layer for the agentic economy.

Speed has always mattered in e-commerce. For years, teams have measured page-load time, optimized images, and chipped away at every unnecessary second between a shopper arriving and completing checkout. Latency was an engineering concern with a visible conversion impact.

Agentic commerce changes the stakes. When an AI agent is comparing options, validating inventory, applying a promotion, and executing a purchase on a customer’s behalf, a slow or stale answer is not merely frustrating. It makes the merchant look unreliable at the exact moment a decision is being made.

That is the shift many commerce teams have yet to internalize. We are moving from a world optimized for human patience to one that must be optimized for machine certainty. If inventory, price, delivery promises, and permissions are not current when an agent asks, the merchant is less likely to be selected. In a market where agents can move quickly to an alternative, that is a direct revenue problem.

The Illusion of the Static Catalog

Imagine a consumer asks a shopping assistant for a specific piece of camping gear, available for delivery before a weekend trip and below a defined budget. The agent checks several retailers. One store has an excellent product page, clean structured data, and an agent-facing API. On paper, it is ready.

But its inventory only syncs from the warehouse every four hours. The item sold out two hours ago. The agent receives an answer that was correct at the last sync, but wrong at the moment of purchase. The checkout fails at final validation, or worse, the order is accepted and later cancelled.

A human shopper may forgive that once. An agent does not need to. Its workflow can immediately test another merchant, one with a current inventory position and a delivery promise it can verify. Whether that reliability signal is modeled directly or reflected through completed transactions, the economic effect is the same: the merchant with stale data loses eligibility for high-intent demand.

This is the latency tax. It is revenue lost not because the product is inferior, but because the system could not state a trustworthy commercial truth when it mattered.

A Catalog Is Not a Decision Layer

Many merchants now understand that product data must be structured and machine-readable. That is necessary, but it is only the starting point. A catalog tells an agent what is generally true about a product. A decision layer tells an agent what is true now, what can be promised, and what action may be taken.

Google’s Universal Commerce Protocol overview makes the requirement explicit: conversational commerce needs real-time inventory checks, dynamic pricing, and instant transactions in the customer’s current conversational context. IBM similarly describes agents comparing price, availability, and delivery details in real time, while merchant systems expose the APIs needed to validate those decisions and complete the transaction.

The useful distinction is simple: a catalog provides information; a real-time decision layer provides a reliable commitment.

That distinction becomes critical when an agent is acting across multiple systems. A price may depend on a customer’s eligibility, a promotion may have a budget cap, inventory may be shared across channels, and a delivery promise may depend on location, carrier capacity, or a cut-off time. None of these conditions can be handled safely by serving a snapshot that was accurate earlier in the day.

There are four parts of that commercial truth that matter most.

• Product truth is the foundation. The agent needs complete, normalized, machine-readable information about what the item is, what it does, and whether it fits the customer’s stated constraints.

• Commercial truth is the price and the offer at this moment. The system needs to determine whether a promotion, negotiated bundle, loyalty benefit, or other condition applies, then bind a valid quote to the current session.

• Fulfillment truth is the promise after the click. The agent needs to know whether an item can reach a specific location within a stated window, which means checking available-to-promise inventory, capacity, and cut-off rules in real time.

• Permission truth determines whether the transaction can proceed. The merchant must be able to verify the agent’s authority, the customer’s consent, relevant spending limits, and any delegated payment credentials.

Designing for Machine Certainty

This does not mean every request must make a direct call to every system of record. That would create a different kind of latency and a fragile dependency chain. Real-time commerce means that the answer presented to an agent is bounded by current, authoritative information and can be validated at the point of execution.

In practice, that calls for an event-driven architecture. Inventory changes, price updates, promotion rules, and fulfillment events should propagate quickly enough that the decision layer can return a current answer. When an agent sees an available item, the system should be able to reserve it briefly or otherwise protect the promise until the transaction is completed or expires.

The same discipline applies to failure paths. A generic error page may be adequate for a human who can retry later. It is inadequate for an agent trying to resolve a constrained request. If a product is unavailable, the system should provide a machine-readable reason and, where appropriate, alternatives that meet the same intent. That allows the agent to recover gracefully instead of abandoning the merchant.

Observability matters just as much. Teams need to know what the agent asked, what the system promised, which price or inventory rule applied, and why a transaction succeeded or failed. Without that audit trail, a merchant cannot distinguish a true demand problem from a reliability problem hiding inside the stack.

The New Brand Promise

For decades, brand trust was built through product quality, customer service, and the consistency of the experience. In the agentic era, data integrity belongs on that list.

The merchant that can return an accurate answer, honor a price, reserve a scarce item, and explain a failure clearly is building trust with both the consumer and the system acting on the consumer’s behalf. Google Cloud’s guidance for retailers arrives at the same conclusion: agentic commerce depends on a unified data foundation, strong back-end systems, APIs, and interoperable standards.

McKinsey estimates that agentic commerce could orchestrate $900 billion to $1 trillion of US B2C retail revenue by 2030, although the eventual scale will depend on adoption and merchant readiness. The number is useful less as a forecast than as a reminder of what is changing. The competitive layer is moving closer to the moment of intent.

Latency is no longer an item for an engineering backlog. It is a strategic vulnerability, a conversion problem, and a brand promise. The merchants that win in agentic commerce will not simply be easiest for machines to discover. They will be the easiest for machines to trust.

It might have been a marketing attribution report claiming a single ebook download drove a six-figure deal. It might have been a CRM pipeline showing a 40% close rate on leads that were never going to buy. Or perhaps it was a customer success spreadsheet showing high engagement metrics right before a catastrophic churn event.

We have spent billions of dollars on software designed to give us “a single source of truth.” We bought the CRM, the marketing automation platform, the data warehouse, and the business intelligence tools. We hired analysts to build the dashboards. And yet, when we ask a fundamental question like, “What actually caused this customer to buy, expand, and stay?” the answer is usually a shrug and a best guess.

The problem is not that we lack data. The problem is that we are using the wrong mental model to understand it. We are trying to measure a network using a funnel.

The Funnel Is Broken

The traditional view of revenue is linear. A stranger becomes a visitor, a visitor becomes a lead, a lead becomes an opportunity, and an opportunity becomes a customer. We track this progression through a series of isolated systems, handing the baton from marketing to sales to customer success.

This model made sense in 2010 when buying journeys were simpler and channels were fewer. Today, it is dangerously obsolete.

Modern B2B buying is not a straight line. It is a messy, looping, multi-threaded web of interactions. A prospect might listen to a podcast, visit your website, ignore three emails, talk to a peer in a Slack community, attend a webinar, and then book a demo. After they buy, they interact with your product, your support team, and your billing system.

When you force this complex reality into a linear funnel or an isolated table in a database, you lose the context. You lose the relationships between events. You lose the actual story of how revenue is created.

Enter the Revenue Graph

At Convertmax, we have been thinking deeply about how to solve this. Our conclusion is that we need to stop building better dashboards and start building a better underlying data structure. We need a Revenue Graph.

A Revenue Graph is a living, connected model of every customer, every interaction, and every revenue event across your entire business. Instead of storing data in isolated tables, it stores data as a network of relationships.

Think of it like a social network for your business data. In a social network, the value is not just in the profiles (the nodes), but in the connections between them (the edges). A Revenue Graph works the same way. Every person, company, session, opportunity, campaign, order, invoice, and support ticket is a node. The interactions between them are the edges.

This structural shift unlocks an entirely new level of intelligence.

Asking Better Questions

When your data is structured as a graph, you can stop asking basic, isolated questions and start asking complex, relational questions.

Instead of asking, “How many leads did this webinar generate?” you can ask, “Which specific sequence of touchpoints across marketing, sales, and product usage is most highly correlated with expansion revenue in our enterprise segment?”

Instead of asking, “What is our average sales cycle?” you can ask, “How does the involvement of a technical champion in the second week of a trial impact the likelihood of a closed-won deal, and which marketing channels are best at acquiring those champions?”

These are not just reporting questions. They are strategic business questions. And you cannot answer them if your data is trapped in silos.

The Foundation for AI

There is another, even more urgent reason why the Revenue Graph matters: Artificial Intelligence.

We are entering an era where AI agents will not just analyze data, but act on it. They will draft emails, negotiate contracts, and identify churn risks. But AI is only as smart as the context it is given. If you feed an LLM disconnected, fragmented data, it will give you disconnected, fragmented answers.

Large language models excel at navigating relationships and understanding context. When you point an AI at a Revenue Graph, it doesn’t have to guess how things are connected. The connections are explicitly defined in the data structure. This is the difference between an AI that can summarize a single CRM record and an AI that can diagnose why revenue is down in a specific region and recommend a course of action based on historical patterns.

A New Operating System

We are moving away from a world where the CRM is the center of the universe. Companies change CRMs, they acquire other businesses, and they use different tools for different departments. The CRM is just another node in the network.

The future of revenue intelligence is an agnostic, connected layer that sits above all your systems, continuously learning from every interaction. It is a shift from static reporting to dynamic understanding.

Revenue is not a transaction. It is a journey. It is time we started measuring it like one.

I am building the next generation of revenue intelligence at Convertmax. If you are interested in moving beyond the dashboard and understanding the true mechanics of your revenue engine, I would love to connect.

The e-commerce landscape is in constant flux, but few shifts have been as profound as the emergence of agentic commerce. This paradigm, where AI-powered agents act autonomously on behalf of consumers, is not merely an evolution of online shopping; it’s a fundamental re-architecture of the customer journey, signaling the potential demise of the traditional marketing and sales funnel.

For decades, businesses have meticulously crafted strategies around the linear progression of awareness, interest, desire, and action (AIDA). However, as intelligent agents increasingly mediate interactions between consumers and brands, this well-worn path is being rerouted, demanding a radical rethinking of how businesses engage, convert, and retain customers.

The Disruption of the Traditional Funnel

The traditional sales funnel relies on a series of touchpoints designed to guide a customer from initial discovery to final purchase. In this model, brands control the narrative, optimizing for clicks, page views, and time on site. Agentic commerce, however, introduces a powerful intermediary: the AI agent. These agents, whether embedded in search engines, voice assistants, or dedicated shopping platforms, can:

• Browse and discover products across multiple vendors without human intervention.

• Compare prices and features, often negotiating on the user’s behalf.

• Synthesize information from reviews, specifications, and external data sources.

• Execute transactions autonomously, from adding items to a cart to completing payment.

This shift compresses the customer journey, often reducing it to a

single conversational moment or an invisible background process .

The New Agent-Mediated Customer Journey

The agent-mediated customer journey fundamentally redefines how consumers interact with products and services. Instead of actively navigating websites and comparing options, consumers delegate these tasks to their AI agents. McKinsey identifies three key interaction models emerging in this new era :

1. Agent-to-Site: Here, an AI agent interacts directly with a merchant’s platform, much like a human would, but with greater speed and efficiency. For example, a travel agent AI might scan multiple hotel websites, identify options matching user preferences, and even book a room after human confirmation.

2. Agent-to-Agent: This model involves autonomous transactions between different AI agents. A personal shopping agent, for instance, could communicate with a retailer’s in-house AI commerce agent to negotiate a bundle discount across various products.

3. Brokered Agent-to-Site: In this scenario, intermediary systems facilitate interactions between multiple agents and platforms. A restaurant-booking agent, for example, might leverage a broker agent on a platform like OpenTable to find and reserve a table, applying loyalty discounts automatically.

This shift moves commerce from a vertical, destination-based activity (e.g., going to Amazon for shopping) to a more integrated, horizontal ecosystem where personal agents act as concierges, fulfilling diverse consumer needs from a single point of intent .

Implications for Businesses: Adapting to the Agentic Era

The rise of agentic commerce presents both challenges and immense opportunities for businesses. To thrive, brands must adapt their strategies to cater to both human consumers and their AI counterparts. Key areas of focus include:

1. Data Structure and Accessibility

Traditional e-commerce platforms were built for human browsing. AI agents, however, crave structured, accurate, and machine-readable data . This means:

• Structured Product Data: Ensuring key information (dimensions, ingredients, shipping, stock) is consistent and easily accessible. Schema markup becomes critical for discoverability by AI agents .

• Semantic Clarity: Avoiding vital information hidden behind visual elements like carousels or image-only formats, as AI tools may miss what a human would visually explore .

• Taxonomy & Tags: Implementing clear and consistent internal categorization and tagging to prevent confusion for automated agents .

2. Rethinking the Marketing Funnel and Engagement

With agents disintermediating the top of the funnel, traditional paid search and advertising models will become harder to attribute. Brands need new ways to get on agents’ lists and measure results . This includes:

• Influencing Third-Party Agents: Providing rich content feeds and structured data to ensure products are accurately surfaced by external AI platforms .

• Building Owned Agentic Capabilities: Developing proprietary AI assistants to enhance discovery and conversion within their own ecosystems, leveraging unique data and expertise . Amazon’s Rufus and Home Depot’s Magic Apron are examples of this .

• Strategic Partnerships: Collaborating with major AI platforms and participating in initiatives like Google’s Universal Commerce Protocol (UCP) to influence emerging rules of engagement and ensure visibility .

3. Modular Architectures and Experimentation

Composable, headless architectures make it easier to expose content to multiple surfaces, including AI agents . Businesses don’t need to rebuild from scratch but should focus on experimentation:

• Test AI-Optimized Experiences: Running controlled pilots for AI-optimized product detail pages (PDPs) or guided shopping assistants

• Agility: Continuously assessing where and how to partner with third-party agents and optimizing to assert control over the end-to-end shopper journey

For years, brands optimized their websites for human eyes—focusing on intuitive navigation, compelling hero images, and persuasive copywriting. But today, a growing segment of buyers aren’t human. They are AI agents operating on behalf of consumers, and they don’t care about your website’s aesthetic. They care about structured data, API accessibility, and standardized commerce protocols.

If your Shopify store isn’t built to communicate with these agents, you are rapidly becoming invisible to a massive, high-intent audience. Here is why every Shopify store needs an Agent API, and how the underlying infrastructure of commerce is changing.

The Rise of the AI Buyer

The concept of an AI shopping assistant has evolved from a novelty to a primary interface. Platforms like ChatGPT, Google’s Gemini, and Microsoft Copilot now feature embedded commerce capabilities that allow users to discover, compare, and purchase products without ever leaving the chat interface .

Consider the modern shopping journey. A consumer no longer opens five tabs to compare running shoes. Instead, they tell their AI agent: “Find me a lightweight, waterproof trail running shoe under $150, available in size 10, that has free returns and can be delivered by Friday.”

The agent instantly queries the web, but it doesn’t read marketing copy. It looks for machine-parsable product data . If your store’s data is trapped in JavaScript rendering logic or unstructured text, the agent simply skips you and buys from a competitor whose catalog is accessible via an API.

According to recent data, AI-originated orders on Shopify grew 15x between January 2025 and January 2026 . McKinsey projects that by 2030, the US B2C retail market could see up to $1 trillion in orchestrated revenue from agentic commerce . The brands capturing this revenue are the ones treating AI agents as first-class customers.

The Protocols Powering Agentic Commerce

To understand why an Agent API is necessary, you have to understand the infrastructure enabling this shift. The industry is rapidly standardizing around a set of protocols designed to facilitate seamless machine-to-machine commerce:

1. Universal Commerce Protocol (UCP)

Co-developed by Shopify and Google, UCP is an open standard that standardizes the entire shopping lifecycle for AI agents—from discovery to checkout . It allows an agent to understand a store’s capabilities (e.g., supported payment methods, return policies) by reading a simple manifest file. If your store supports UCP, any compliant AI agent can seamlessly interact with your catalog and execute a transaction.

2. Model Context Protocol (MCP)

Created by Anthropic, MCP standardizes how AI agents securely connect to external data sources . Shopify has built specific MCP servers for its merchants, allowing agents to query product catalogs, access store policies, and handle the checkout lifecycle autonomously .

3. Agentic Commerce Protocol (ACP)

Developed by OpenAI and Stripe, ACP focuses on secure, instant checkout within generative AI environments like ChatGPT . It utilizes a delegated payment model, allowing users to complete purchases instantly within the chat interface, drastically reducing friction.

Why Your Current Setup Isn’t Enough

Many merchants assume that because their store is indexed by Google, it is ready for AI agents. This is a dangerous misconception.

Search engines index content for human readability. AI agents require structured metadata. When an agent evaluates a product, it looks for specific, standardized attributes: exact dimensions, real-time inventory status, machine-readable shipping policies, and unique SKUs for every variant .

If your product variants (e.g., different colors of the same shirt) are listed as separate products without a unifying parent structure, an agent will struggle to understand the relationship . If your pricing and inventory data isn’t available in real-time via an API, an agent won’t risk recommending an out-of-stock item .

This is where the Agent API comes in. An Agent API (like Shopify’s Agentic Storefronts) bypasses the visual layer of your website and serves raw, structured commerce data directly to the AI models making purchasing decisions.

The Cost of Inaction

The shift to Agentic Commerce is happening faster than the transition to mobile commerce. Consumers are adopting AI discovery tools at an unprecedented rate because it fundamentally reduces the friction of shopping.

Brands that fail to optimize for agentic discovery face two immediate risks:

1.Loss of High-Intent Traffic: AI agents only surface products that match highly specific, high-intent queries. If your data isn’t structured to answer these queries, you forfeit this traffic entirely.

2.Erosion of Brand Control: If you don’t provide a structured Knowledge Base (FAQs, policies, brand voice guidelines) to AI agents, they will synthesize answers based on random web scraping . This leads to hallucinations, inaccurate product representations, and degraded customer trust.

How to Prepare Your Store

Preparing for Agentic Commerce requires a shift in engineering and operational priorities. Here are the immediate steps technical leaders and founders must take:

1.Audit Your Structured Data: Ensure every product has standardized attributes (Color, Size, Material), unique SKUs for all variants, and complete GTINs/UPCs .

2.Enable Agentic Storefronts: If you are on Shopify, utilize the Agentic Storefronts feature to syndicate your catalog directly to major AI platforms like ChatGPT and Copilot .

3.Establish a Machine-Readable Knowledge Base: Digitize your return policies, shipping timelines, and product FAQs into a structured format that AI agents can query to accurately represent your brand .

4.Prioritize Real-Time APIs: Ensure your inventory and pricing data is accessible via real-time API endpoints, rather than relying on periodic feed syncs .

Conclusion

We are entering an era where your most important customer might not be a human, but an algorithm executing human intent. The infrastructure behind commerce is evolving from visual storefronts to programmatic APIs.

Building an Agent API isn’t just a technical upgrade; it is a fundamental requirement for survival in the next decade of retail. The brands that win will be the ones that make themselves the easiest for machines to understand, evaluate, and buy from.