The Agent Needs an Account of Its Own

Most businesses understand delegation perfectly well until the person receiving the instructions is software. An employee may place an order without being allowed to change the supplier’s bank details. A colleague can approve an expense up to a limit without acquiring permission to approve it every afternoon. Authority has a purpose, a scope and an expiry date. Commerce agents will need the same distinctions.

Walmart’s announcement on 21 October 2026 gives this rather ordinary management principle an interesting retail application. Its planned Agent Profiles would distinguish an agent’s purchases within a customer account. Customers could approve purchases individually or authorise spending within a limit, then withdraw that permission. An accompanying gateway would connect external agents. Access rules would restrict what those agents could see and change. [1]

The geography and timing matter. This concerns Walmart.com and Sam’s Club in a US retail setting. Gateway access is an early, invitation-only beta, with functionality that may change or differ between participants. The profiles are planned for November. The sources reviewed as of 26 October announce no rollout for Germany, Austria or Switzerland. [1][4]

For a retailer in those markets, Walmart’s proposed model is a reference point to examine. The announcements establish neither local availability of that particular service nor customer adoption or commercial performance. Those limits should not be mistaken for an account of what European retailers already offer through other integrations.

What makes Walmart’s proposed model worth considering is the distinction it preserves. The customer owns the relationship. The agent receives a defined part to play within it.

Giving software the customer’s login can blur that distinction. The system sees a valid session and makes the account’s functions available. Yet the customer may have authorised only one task. Permission to buy replacement coffee filters does not necessarily extend to reading every previous order, changing an address or starting a subscription. The login proves too little about the action that follows.

An account of its own is shorthand for a separately identifiable and revocable delegation. It need not mean another registration form or password. A profile, a bounded session or another access mechanism could serve the purpose. The retailer needs to distinguish the customer, the agent acting for them and the permission relevant to the transaction.

The Personal Agent Protocol draft, known as Poppy, takes up this question of delegated access. Published on 9 October, it describes agents identifying themselves, customers granting access and businesses setting the parameters for actions across their channels. It remains a protocol proposal. A list of design partners is not a list of live deployments, and says nothing by itself about availability to a particular European customer. [2]

My reading is that delegated authority is becoming a distinct part of commerce architecture. Identity establishes who is involved. Delegation establishes what one participant may do for another. The shopping function then executes an action within those boundaries.

Technical access is moving along a separate track. On 21 October, Commerce.com and Cloudflare described enabling WebMCP by default for eligible BigCommerce merchants. Browser agents can use structured shopping tools, while the customer still completes checkout in the described flow. Merchants can opt out. [3][5]

This also needs careful qualification. WebMCP remains experimental and requires compatible browsers or testing environments. The announcements provide no complete country list or blanket assurance for DACH merchants. Eligibility, store configuration and customer-side support all matter. Calling it a US-only service would be as misleading as treating it as a universal European rollout. [3][5]

The useful observation is that agent access can arrive through a platform release. A retailer does not have to commission its own shopping assistant before someone else’s software starts using its store.

That creates a decision for the business. The platform can expose a function and enforce technical controls. The retailer still needs to decide whether the function is appropriate for the mandate, the customer and the commercial situation. A default setting is a particularly economical way of making a decision. It is not always a good way of discovering who made it.

European retailers are already giving external assistants practical access. On 20 October 2026, OTTO described an MCP connection and a ChatGPT plugin for product advice. Customers move to OTTO to buy. Its announcement places agents initiating orders in the prospective capabilities, rather than the available customer journey. [10]

Carrefour’s French customers have been able to use its ChatGPT app since 26 March 2026 to find products, assemble a basket and select a delivery method. They finalise and pay on Carrefour.fr. Product selection can therefore happen outside the shop while the customer retains the final purchase decision. [11]

Germany also has a concrete basket-building example. Knuspr announced its ChatGPT integration on 4 July 2026. Customers assemble their shopping, then move to Knuspr to review and order it. Its MCP documentation describes account authentication and basket management. Access to the shopping service still depends on Knuspr’s delivery coverage. [12] [13]

dm’s published MCP tools cover product search, product details, stores and availability. Ordering is not among the listed functions. Opening a catalogue, changing a basket and executing a purchase are distinct capabilities. [14]

Real agent-assisted payments have also taken place in Europe. On 2 June, Worldline, ING and Mastercard described a ticket purchase in the Netherlands that the customer explicitly approved. [9]

European retailers already face a practical decision about which actions to expose. The documented OTTO, Carrefour and Knuspr journeys do not establish that an external agent may buy substitute products under a standing mandate without fresh approval. Connecting a customer account does not establish that authority either. A separately identifiable agent account is the design principle argued for here, rather than a feature claimed for every existing integration.

Substitution itself is familiar retail work. Carrefour’s Drive guidance, for example, describes customers accepting or refusing replacement products. External delegation adds another handover. May the customer’s agent make that decision, under which rules, and what evidence should the retailer receive? [15]

The limits of that authority become clearer when a familiar purchase changes.

Consider a customer asking an agent to buy the same running shoes again, with a budget of €140. The old model has gone. Its replacement costs €135, but is available immediately only in a different colour. The preferred colour will arrive in three weeks. A subscription offers a discount, should the customer happen to want their footwear procurement put on a recurring schedule.

The agent has several affordable options and no obvious authority to choose between them. A budget can settle the price question while leaving the actual decision unresolved. A successful payment would not settle the question of which shoes the customer meant.

Which substitutions are acceptable? Is delivery speed more important than colour? Can the agent enter a recurring commitment? Does the limit apply to one transaction or to all purchases under the instruction? A system that allows five separate orders below the ceiling may have respected the setting and thoroughly misunderstood the customer.

A delegated purchase therefore needs a usable definition of the mandate. It should cover the task, its duration, the permitted variations and the point at which the customer must be brought back into the decision. Those boundaries need to be enforced by the systems accepting the order or change. A well-written instruction to the model is useful, but it cannot carry that responsibility alone.

An external personal agent adds another party to this arrangement. Its provider shapes how the customer gives instructions and how those instructions become conditions the software can use. A conversation, saved preferences and a confirmation screen may all contribute. The retailer’s required fields serve a different purpose. They establish what a particular action needs. A complete order can still be an incomplete account of what the customer wanted.

A retailer’s own assistant adds a further distinction. On 28 September, Carrefour expanded Hopla with healthier alternatives and basket analysis. Its recommendations follow a deliberately designed objective. [16] My reading is that a retailer’s preferred selection criteria and a customer’s permission to buy something else must remain separate. Where suggestions serve commercial aims, a customer’s agent still has to test them against its instructions. An attractive recommendation is not an amendment to the brief.

Protocols provide mechanisms for making the resulting authority verifiable. The AP2 v0.2 specification separates Checkout and Payment Mandates. Its authorisation framework supports open mandates carrying constraints and mandates bound to a specific transaction. UCP also documents an AP2 extension for exchanging signed authorisation evidence. These are specifications, not proof of availability in an individual retailer’s stack. [6][7][8]

AP2 assigns the assembly of mandate content to the shopping agent once it has established the user’s task. The specification explicitly leaves that translation process outside its scope. A retailer may therefore receive an authorisation without seeing the conversation behind it. Only the mandate information needed for verification should be disclosed. [6][7]

Under that framework, constraints must be checked, and an unknown constraint cannot simply be ignored. AP2 requires the prescribed validation to run in deterministic code. The model’s assurance that everything looks reasonable is not the prescribed test. [6][7]

My concern is the business meaning captured before that test runs. A customer could approve an explicit list of substitute products. Deciding that a redesigned shoe offers the familiar fit is a different proposition. It needs an agreed rule, dependable product information and a route back to the customer where equivalence cannot be established. A valid signature can preserve the permission faithfully while the original instruction has been misunderstood. This is where mandate design still requires commercial judgement, even when the mechanism carrying it is standardised.

This creates a practical responsibility at the boundary between the agent provider and the retailer. They need to establish which conditions both systems can interpret and verify, how missing information is detected and when the customer must be consulted again. Part of that work sits outside the retailer’s own CX and ERP environment. A retailer operating its own assistant may fulfil several of these roles, but still needs to distinguish their responsibilities.

Where a decision returns to the customer, approval needs to be specific. A customer should be approving a recognisable purchase, with an identifiable basket, total price and material conditions. If any of these change before execution, the system needs a rule for what remains authorised. Recording a click labelled “Confirm” is of limited help if nobody can establish which version of the order it confirmed.

The history must also survive the handover to customer service. Did the agent retry because it received no response? Was the substitute approved? Had the mandate expired? These are operational questions with immediate consequences for refunds, duplicate orders and customer trust.

A useful record would connect the task, the acting agent, the permission in force, any customer approval and the resulting action. That does not require retaining the customer’s entire private conversation or the model’s internal reasoning. It requires enough evidence to explain the transaction and put it right where necessary.

Revocation deserves equal attention. Removing an agent’s permission should stop further actions. It does not make an order already placed disappear. Cancellation, returns and refunds remain separate processes. Customers need to understand that distinction when they disconnect an agent, rather than discover it through an unexpected delivery.

There is a commercial balance to strike here. Ask for confirmation at every step and the supposed convenience becomes a sequence of small interruptions. The customer has hired an assistant and acquired a supervisor’s job. Allow too much discretion and convenience can turn into unwanted purchases, avoidable returns and expensive explanations.

The practical answer is graduated authority. An unchanged repeat order to a familiar address might proceed within an agreed mandate. A different product, a new delivery address or a recurring obligation could require fresh approval. The thresholds should follow the significance of the decision, rather than treating every click as equally harmless or equally dangerous.

This calls for a named business owner who can bring the relevant decisions together. Commerce defines the offer and its commercial boundaries. Technology and security make those boundaries enforceable. Customer service handles exceptions. Privacy and legal specialists assess the requirements that apply. That owner must also govern the handovers to external agent providers and resolve disagreements about what each side can verify. Where customer conditions cannot be checked reliably across the systems involved, the use case may need to remain disabled.

For a mid-market retailer in Germany, Austria or Switzerland, agent access is already an operational question. The starting point is what its market, subscription and store configuration actually support. Search and basket preparation may be useful today, while broader delegation requires additional mandate checks, payment support and routes back to the customer. A US beta creates no European implementation deadline. Equally, a European retailer’s integration does not mean every DACH merchant can buy the same capabilities off the shelf.

A sensible pilot might begin by preparing a basket for the customer to approve. If it later graduates to replenishing a familiar consumable on its own, the permitted decisions, exceptions and supporting evidence need to be defined first. The systems must then demonstrate that they can enforce those boundaries. Missing capabilities are a reason to withhold the extra autonomy. They need not prevent useful assistance in the meantime.

A live pilot, once feasible, should measure the attention it saves as well as the orders it completes. Unnecessary confirmations, duplicate purchases, incorrect substitutions and service effort belong beside conversion and revenue. An order that takes longer to explain than to fulfil is not an unqualified success.

The account is ultimately a way of making a relationship legible. The customer can see what has been delegated. The retailer can see what is authorised. Both have a practical way to limit or end the arrangement.

The agent needs an account of its own because acting for a customer and being the customer are different things. A retailer that preserves that distinction can offer useful autonomy with boundaries people can understand.