Agentic Commerce, Plainly: What an AI Agent Can Do in a dPlaza Store Today
"Agentic commerce" is the idea that AI agents will take part in buying and selling, not just answer questions about it. Depending on who is talking, that means one of three things: an agent that browses catalogs for a shopper, an agent that buys on someone's behalf, or an agent that runs a store for a merchant.
Those are very different jobs with very different risks. An agent that reads a product page can do little harm. An agent that moves money can do a lot. This guide separates the three, explains where onchain payments like USDC fit, and then describes exactly what an agent can and cannot do on dPlaza today.
The three jobs of an agent in commerce
Browsing
The simplest job. An agent reads product pages, compares options, and summarizes them for a person. It needs pages that are public, structured, and easy to parse. Many sites now publish an llms.txt file: a plain-text index written for language models that points to the pages worth reading.
Buying
The hard job. To buy, an agent needs a way to pay, a spending limit, and a clear record of who authorized what. Card checkouts were built for humans clicking buttons, so a lot of current work goes into payment rails an agent can use directly. One example is x402, which describes itself as an open standard for internet-native payments between clients and servers. Stablecoins such as USDC come up often in this conversation because a payment is a transaction anyone can check, and it settles without a card network in the middle.
Running a store
The underrated job. Most of a merchant's week is not selling; it is operations. Adding products, updating stock, moving orders to "shipped," answering "how did last month go?", and paying out earnings. That work is repetitive, it lives in a dashboard, and it is where an agent can save a merchant real time today.
What makes an agent safe to let into a store
Before any feature list, the guardrails. An agent is only as safe as the access it is given. Four things matter:
- Scope. The agent's key should reach one store and nothing else.
- Read versus write. Reading reports is harmless. Changing prices is not. The merchant should choose.
- Money is separate. Refunds and withdrawals deserve their own permission, off by default.
- No double charges. If an agent retries a call after a timeout, the retry must not move money a second time. The standard answer is an idempotency key: the same request, sent twice, returns the first result.
A rate limit and an expiry date on the key round it out. If a platform cannot tell you how it handles all of these, do not give it an agent.
What an agent can do on dPlaza today
dPlaza is the storefront platform we build for creators, artists, and brands. It has a Store API that speaks the Model Context Protocol (MCP), an open protocol for connecting AI applications to tools and data. The dPlaza MCP page lists every tool and is generated from the same catalog the server uses. The API is labeled beta.
A store admin creates a key in their store's admin settings. The key is shown once, belongs to a single store, and can be read-only or read and write, with an optional expiry. Every tool call is checked against the key's own store, so an agent holding one store's key cannot read or change another store.
With that key, an agent can:
- Run the catalog. List, create, and update products, and archive ones that should come down.
- Manage the storefront. Read and update store details, set the store's theme, and read its community links.
- Handle orders. List orders, open one with its line items, and move it through its status with a tracking code and notes, using the same validated transitions as the admin dashboard.
- Answer business questions. Order counts by status, revenue by period, a per-store financial breakdown, and revenue and orders bucketed by day, week, or month.
- Know its customers. A customer list built from order history: orders, total spent, and first and last order dates.
- Manage the team. Invite a store admin or editor by email, list and cancel invites, and remove an admin, with rules that protect the last admin and owner.
- Check money. Read the store's USDC balance on Base, its withdrawal history, its saved withdrawal recipients, and its Stripe Connect status.
Moving money takes an extra permission
A separate "Payouts & refunds" permission, off unless the merchant checks it when creating the key, unlocks four more actions: refund a card order, withdraw store USDC, cancel a pending withdrawal, and create a Stripe onboarding link for the owner to open. Refunds and withdrawals require an idempotency key, so a repeated call replays the first result instead of moving money twice. A withdrawal only goes to a saved, verified recipient or the store owner's wallet; the agent cannot supply its own destination address. Both actions are irreversible, and there is no undo call.
Keys are rate limited per key, and a separate limit applies to failed authentication attempts.
The assistant inside the admin
The store admin also includes an AI assistant built on the same tools, scoped to the store the merchant is signed into. Reads run right away. Anything that changes the store is shown to the merchant as a proposed action and runs only after they approve it. For the money actions, approval is bound to a signed, short-lived token, so what runs is exactly what the merchant saw.
Where USDC on Base fits
dPlaza checkout offers two rails. Buyers can pay by card through Stripe, or pay with USDC on Base, a public blockchain network. A USDC payment goes to the store's own wallet, and dPlaza verifies the transfer onchain before marking the order paid. Products can also carry an ownership token that moves to the buyer's wallet after payment.
For the agent running the store, this means the store's balance is not a number in a private ledger. When an agent reads the USDC balance, it is reading what the store wallet holds onchain. If you want to see how the same idea, a record anyone can check, applies to credentials, our sister platform Student Center explains it in How to Issue Verifiable Digital Credentials.
What agents cannot do on dPlaza yet
Being plain about the gaps matters more than the feature list:
- No buying by agent. There is no API for an agent to place an order or pay. Checkout is a person, a cart, and a card or wallet. dPlaza does not support x402 or other agent payment protocols today.
- No Claude.ai or ChatGPT connector yet. Those require OAuth 2.1 with dynamic client registration, which is not built. Today the MCP server works with Claude Code and any MCP client that speaks streamable HTTP with a bearer token.
- No public REST API and no outgoing webhooks. The MCP Store API is the programmatic surface.
- Browsing is public pages only. An agent can read dPlaza's llms.txt, the sitemap, and public storefront and product pages. Store API keys belong to merchants, not shoppers.
That is the honest state of agentic commerce on dPlaza: the selling side is real and guarded, the buying side is still a human.
Open a store and connect your agent
If you sell to fans and want an agent that can handle the catalog, orders, and reporting while you keep the final say on anything that moves money, start with a store. Creating one takes a sign-in and a short setup; once it exists, you can issue a key from admin settings and follow the MCP page to connect it.
