Walmart Welcomes AI Buyers. Amazon Blocks Them.

By Lazar Milicevic · Published November 5, 2026 · 7 min read

▶ Watch the video version of this article

You can build an agent that finds the right box of shipping labels in thirty seconds and still can't complete the order, because the store on the other side decides whether agents get in. This week the split got concrete: Walmart is opening a gateway for shopping agents while Amazon keeps blocking them. Here's how to design one purchasing workflow that survives either answer.

The news, and what it does and doesn't establish

On October 21, 2026, Walmart announced its Agent Gateway, according to TechCrunch. It's an MCP server that lets approved AI agents connect to Walmart, search inventory, and buy on a customer's behalf. It also covers Sam's Club. Amazon is moving the opposite way: in September 2026 it blocked Meta's Muse shopping agent, saying continued access by an unauthorized AI agent violates its Conditions of Use, per Cybernews.

Before you rebuild anything, read the fine print:

• The gateway is an early, invitation-only beta. Access is limited and Walmart can suspend it at any time (PPC Land).
• The beta page doesn't name any participating agent companies, so the list of participants is unknown.
• Agent Profiles, the account feature that holds an agent's purchases, were promised "in the next month" after the announcement (Unite.AI). No exact date.
• We couldn't establish from the available sources the details on spending limits (per order or per period, whether they vary by agent), restricted categories, or rate limits. Check Walmart's own documentation for those.

So the headline is "a supported route is opening." It is not "your business can automate Walmart purchasing today." Check availability for your account before you build around it.

Why retailer permission is now part of your architecture

An agent's capability is capped by what the retailer on the other end permits. A model can understand "buy another box of labels, approved SKU, under $30" perfectly and still have no supported way to submit the order.

There are now at least three retailer postures, and your design should assume you'll meet all of them:

The legal picture doesn't resolve this for you. On August 4, 2026, the Ninth Circuit vacated the preliminary injunction against Perplexity's Comet, holding that the user, not the agent's developer, "accesses" Amazon's computers under the CFAA and California's CDAFA (Troutman Privacy). But the court limited its ruling to the record before it and remanded the case (Yahoo Finance). It doesn't force Amazon to let agents in. Don't read it as "agents can now shop on Amazon."

Practical rule: build on routes the retailer explicitly supports, and keep a human fallback for everything else.

The three parts: decision, action, handoff

Picture a five-person agency reordering printer paper, shipping labels, and coffee. Someone checks the cupboard, searches stores, compares packs, orders, and forwards receipts. Each step is cheap, but together they're another interruption in the day.

Most agent demos stop at "here's a good listing." A working purchasing automation has three parts:

• Decision: does this specific product meet your purchasing rules?
• Action: submit an authorized order through a supported connection.
• Handoff: record what happened and route exceptions to a person.

The decision is wider than "cheapest." For shipping labels it includes printer compatibility, label dimensions, quantity, delivery date, and total delivered price. A cheaper roll that doesn't fit the printer is a failed purchase. A correct recommendation without an order is unfinished work. An order without a receipt leaves your accounting unfinished too.

Walmart's reported guardrails map neatly onto this model. Agent Profiles let a customer require approval for every agent purchase, or allow purchases within a spending limit; Walmart's examples are $50, $100, or $200 (Chain Store Age). Customers must approve agent purchases by default, and Walmart may still ask for extra approval on orders inside a limit (The Keyword). Agents can't receive payment card information or add or change payment methods (The Shelby Report). Walmart says agents see the same prices as humans, with applicable offers and fees shown before purchase (Mass Market Retailers).

Notice what that means for your design: the retailer already gives you an approval layer and payment isolation. Your job is the rules and the handoff, not reinventing the vault.

Write a purchasing contract for one repeat item

Not a legal document. A plain set of rules your automation must follow. Pick one item you reorder constantly. Example rules (illustrative, not measured results):

purchase_contract:
  item: shipping labels
  approved_product: "<exact listing / SKU you've verified fits your printer>"
  quantity: 1 box
  max_delivered_total_usd: 30   # includes delivery and tax
  substitutions: none
  approval: required            # a person approves before anything is bought
  outcomes: [ordered, rejected, awaiting_approval, failed]

The flow: a request arrives in your team chat or a simple form. The assistant prepares a purchase proposal containing product, quantity, seller, delivered total, and expected arrival date. A person approves. Only then does the action step run.

Make the outcomes explicit and mutually exclusive. If checkout fails, the record says failed. The workflow must never quietly turn a shopping recommendation into an order confirmation. That one rule prevents the most embarrassing class of automation bugs: a status that says "done" when nothing was bought.

A minimal state model:

from enum import Enum

class PurchaseState(Enum):
    AWAITING_APPROVAL = "awaiting_approval"
    ORDERED = "ordered"
    REJECTED = "rejected"
    FAILED = "failed"

def can_mark_ordered(order_id, receipt_ref):
    # "ordered" requires proof, not a successful-looking agent message
    return bool(order_id) and bool(receipt_ref)

If a state can't be proven with an order ID and a receipt reference, it isn't ordered.

Test the awkward cases before you allow auto-buy

Polished demos hide the expensive failures. Before any automatic purchase, run these on purpose:

• Over the limit: raise the total above your cap. Expected: stop and request a decision.
• Item unavailable: make the approved item out of stock. Expected: no silent substitution; route to a human.
• Duplicate request: submit the same request twice. Expected: one order, not two.
• Interrupted checkout: simulate a dropped connection mid-order. Expected: check for an existing order before retrying.

The duplicate and interrupted cases are the dangerous pair. Buying twice because the first confirmation arrived late is exactly the mistake a happy-path demo never shows. Use an idempotency key per request and look up existing orders before any retry:

def place_order(request_id, proposal, gateway):
    existing = gateway.find_order(idempotency_key=request_id)
    if existing:
        return existing                      # never re-buy on retry
    if proposal.total > proposal.contract.max_total:
        return {"state": "awaiting_approval", "reason": "over_limit"}
    return gateway.submit(proposal, idempotency_key=request_id)

Also plan for the retailer's own rules. Walmart says its returns process applies to agent orders, including when the agent didn't act as intended, and agents that break its terms will be blocked from the site (The Next Web). A returns path exists, but a blocked agent is a hard stop, so your workflow needs a graceful "route to human" branch rather than endless retries.

Then measure, because savings claims mean nothing without observations. Track completed orders, exceptions, duplicate purchases, and human minutes required. A promise of ten hours back each week is worthless if someone spends those hours checking the agent's work.

Expect friction at the checkout step

Don't assume buyers, or agents, love agent checkout yet. Coveo's 2026 Commerce Relevance Report, as cited by Axios, found only 16% of shoppers are comfortable letting an AI assistant find and buy products for them. Walmart said conversion rates for purchases made inside ChatGPT's Instant Checkout were three times lower than for click-outs to its website (Search Engine Land). OpenAI has since moved away from native Instant Checkout toward retailer-owned checkout after product discovery (Progressive Grocer).

For a small business, the lesson is practical rather than philosophical. The reliable pattern today is agent-assisted discovery plus a retailer-controlled or human-approved checkout. Design your proposal-and-approve step so it works whether the final click is made by an agent through a gateway, or by you following a pre-filled link.

Where this leaves a small team

I build custom AI automations for small teams, and workflows like this one are the kind of work I take on. The design principle is to record an order only with proof (an order ID and a receipt), and to keep a human fallback wherever the retailer doesn't support an agent connection. If you're weighing a build like this, you can reach me through the links below.

The milestone to aim for is small and checkable: the right item ordered once, within the rules, with a receipt your business can use. Prove that for one repeat purchase before you expand to a second.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.