Your store's next integration could be with AI: what changes for online sellers

Anyone selling online is used to thinking in channels: Mercado Livre, Shopee, their own store, social media. Each has its rules, its product forms, and its particular way of turning a simple piece of information into another task to deal with after coffee.

Now a new question is starting to emerge: what happens when the shopper arrives with an AI assistant?

They might describe what they need in a conversation. They might ask for a comparison and only open the store to pay. Or the purchase might happen through an interface that brings together offers from several businesses. For developers, this adds a requirement: the product needs to make sense outside the screen where it was listed.

I work on integrations at Oombe, involving Mercado Livre and Shopee, listing creation and transfers, and other e-commerce workflows. When I look at this development, I think about the data that needs to reach the assistant correctly. Experience with catalogs gives you a healthy skepticism about demonstrations where everything works on the first try.

Two recent announcements help explain the change

On October 15, 2026, Google launched Universal Cart in the United States, bringing together products from different stores and offering ways to complete a purchase. The announcement covers the US market; it does not confirm availability in Brazil. [1]

On October 9, Shopify announced that it was sharing compare-at prices with agents through Shopify Catalog. Previously, they received only the current price. This change applies to Shopify's ecosystem. [2]

These are concrete examples of shopping interfaces consuming structured information. My interpretation is that integration work gains another layer: we need to consider how another application understands what the store sells.

A description can seem excellent to someone who knows the product while still leaving fundamental questions unanswered. When the other party is a system, relying on unstated context becomes even less comfortable.

The shopper asks for a solution, and the listing needs answers

Imagine this illustrative scenario. Someone writes:

“I need a backpack for my 16-inch laptop that can handle rain and arrive by Friday. My budget is R$300, including shipping.”

The store has a listing called “Premium Executive Super Reinforced Backpack.” The title is certainly enthusiastic. The information needed to make a decision is less impressive.

What are the internal dimensions of the laptop compartment? Does the manufacturer describe the material as waterproof or merely splash-resistant? Which postal code does the delivery estimate cover? Does the price depend on a particular payment method?

AI can help organize these questions. To answer them reliably, I would require verifiable data. A persuasive sentence about the backpack cannot make its compartment bigger or its fabric waterproof.

In this example, the quality of the recommendation depends on two separate things: understanding the request and checking whether the offer meets it. The first involves language. The second requires a catalog, commercial rules, and current information.

This distinction is useful even for someone who has no plans to add AI to their operation. It reveals how much product knowledge is documented and how much remains stored in someone's head.

What integrating Mercado Livre and Shopee teaches you

When working on the transfer of information between Mercado Livre and Shopee, I have to consider categories, attributes, and variations. The business objective may be the same, but the meaning of the fields needs to survive the journey.

Copying a field name does not automatically establish that correspondence. Information grouped together at the source may need a different structure at the destination. A detail that is optional at one stage may be essential for understanding the product at the next.

It is translation between systems, except that a translation error can become an incorrect listing, a support request, and more work.

That is why I see continuity between marketplace integrations and integrations with AI interfaces. In both cases, someone needs to ensure that the information being transmitted represents the correct product and commercial terms.

The new channel can change the conversation with the shopper. The work behind it still requires specific decisions about identity, data, updates, and responsibility. Anyone who has spent time reconciling these things has useful experience to contribute.

I would start with a clearly defined central catalog

If I were designing an integration for this scenario, I would start with an internal representation of the product, independent of how each channel displays it. Developers often call this a canonical model: a shared reference that is then adapted for each destination.

For a possible evolution of systems such as Oombe, I would evaluate this approach before choosing an AI model.

Within that reference, I would separate:

• Product: brand, model, materials, dimensions, and verified characteristics.
• Variant: size, color, finish, or another difference that changes the item delivered.
• Offer: seller, price, payment terms, and validity.
• Availability: sellable quantity, source, and update time.
• Delivery: destination checked, cost, and the corresponding estimate.
• Relationships: accessories, components, and documented compatibility.

This separation avoids putting different concepts into a single block of text and then asking each integration to work out what it means.

It also comes at a cost. Fields need to be defined, mappings maintained, and discrepancies resolved. A small catalog may only need a simple structure. An operation with many channels may benefit from a more rigorous central catalog. I would choose the complexity according to the actual problem, without building an ocean liner to cross a puddle.

Identity matters more than a convincing title

A black T-shirt in medium and a black T-shirt in large may share a description and photos. When it comes to delivery, the difference is very real.

I would maintain a stable internal identifier for each sellable item and record its corresponding identity in each channel. The commercial name can change to improve presentation; the item's identity needs to remain recognizable.

The same reasoning applies to bundles. An offer containing three units should not be confused with a single unit just because the titles look similar. Components, quantities, and terms need to be represented explicitly.

I would take similar care with compatibility: an association should carry its source and its scope. A recommendation based on similarity can be useful for research, but it should not silently turn into a compatibility guarantee.

This is where an integrator can contribute a great deal. They can build the mappings that let the system recognize the same product across channels while preserving the differences that affect the purchase.

A good price is one that stays correct through confirmation

Back to the backpack, this time with fictional prices. One offer costs R$219 with R$35 shipping. Another costs R$239 with no additional delivery charge for that address.

The smallest number on the price tag does not necessarily represent the lowest total. Delivery dates, installment terms, and the availability of the selected variant may also differ.

When designing this integration, I would treat price as information accompanied by conditions. Which currency? Which payment method? What quantity? What validity period? Which buyer or region, where restrictions apply?

That helps prevent an expired promotion from being mixed into a current search, or an exclusive condition from being presented as a general offer.

Before confirming the purchase, I would revalidate the elements that can change. If the total has increased or the delivery date no longer meets the request, the person needs to see the new terms and decide.

A system that clearly explains a change may lose a sale at that moment. A system that hides the change creates a bigger problem to resolve later.

Inventory information ages

Still in our example, imagine the search found two backpacks available. While the shopper compares options, a sale happens through another channel and one unit is set aside for an earlier order.

The response received a few minutes before no longer describes the same situation.

I would design the workflow to account for the passage of time. Availability information should indicate when it was obtained and where it came from. The confirmation stage would need to follow the operation's rules for reserving and selling stock.

I would also define how the system behaves when a query fails. Repeating old information as if it were current is a risky choice. It may be better to show availability as pending confirmation and allow another attempt.

There is a balance between speed and freshness. Checking every source at every small interaction can make the experience slow and expensive. Reusing data for too long can compromise the decision. The appropriate interval depends on the information and the pace of the operation.

This is an engineering decision that needs to be part of the product design, even if nobody wants to hear about it during the demonstration.

The AI needs to know how far it can go

There is an important difference between finding products, preparing a suggestion, and authorizing a purchase.

In an implementation of mine, these capabilities would have separate permissions. Reading a catalog would not automatically grant access to change prices, move stock, or execute payments.

I would also record the link between the person's request and the action prepared by the system. Which product was selected? Which variant? Which seller? What total? Which address? What was authorized?

That helps both with confirmation before the action and with investigation afterward. If something goes wrong, we need to reconstruct the sequence without depending on someone's memory of a conversation.

Another consideration is preventing a retry from creating a duplicate purchase. If a response was delayed, the system needs to check the operation's state before repeating an action that moves money.

These are requirements I would include from the beginning. A useful assistant needs to know how to look things up, explain, request a decision when necessary, and recognize when it still lacks enough information.

An opportunity for developers and sellers

For a merchant, my initial recommendation would be to review catalog quality. Dimensions, materials, components, and usage restrictions help answer actual purchase questions, regardless of the interface involved.

For developers, I would look at clearly bounded problems. For example: identifying missing attributes, finding discrepancies between channels, or showing an operator which information needs confirmation.

These proposals make it possible to evaluate usefulness without starting by giving an agent control of the entire operation.

A tool that flags a hundred inconsistencies but mixes important problems with irrelevant details also creates work. I would measure quality by what was safely corrected, how long review took, and how much human intervention was required.

Business knowledge matters in that evaluation. People who work with listings, compatibility, payments, and support know that some information has a much greater impact than other information. That experience helps determine where to automate first and where to retain careful review.

How I would begin in practice

I would choose a small product family and describe three or four plausible shopper requests. Then I would check whether the available data allows an answer without guessing.

Next, I would define which system is the reference for each piece of information. Price might come from one source, inventory from another, and specifications from a third. The integration needs to know how to resolve conflicts among them.

The third step would be to build a query that returns answers with context: what was found, when it was checked, and what still needs confirmation. That explanation is as useful to a human operator as it is to a conversational interface.

Finally, I would test awkward situations: an unavailable product, a missing variant, shipping that exceeds the budget, a changed delivery date, and an interrupted response. In this proposed approach, the goal would be to observe how the workflow behaves when conditions stop being ideal.

I would only expand the scope after understanding the errors in that small set. Starting with assisted queries makes it easier to observe behavior before adding actions with commercial consequences.

Another interface, several familiar responsibilities

I do not see a basis in these announcements for declaring the end of marketplaces. A new discovery interface can coexist with existing channels, stores, and operations. The combination that makes sense will depend on access, commercial terms, and shopper behavior.

I would not treat an AI integration as a guarantee of traffic or sales either. Being available to an application and being chosen by a shopper are different outcomes.

What interests me as a developer is the opportunity to make information and processes more reliable. My experience with Oombe provides a starting point: turning platform requirements into workflows that make sense for sellers.

If some purchases move into AI conversations, that experience will remain useful. Someone will need to check that the recommended product exists, that the variant is correct, that the terms are still valid, and that the action was authorized.

The conversation may become more natural. I would still pay close attention to what happens between “I like that one” and “order confirmed.”

Sources

[1] Google — An intelligent new shopping cart. Published October 15, 2026. Universal Cart announcement for the United States.

[2] Shopify Changelog — Compare-at prices now shared to agentic channels. Published October 9, 2026. A change specific to Shopify Catalog.