What is agentic commerce?
Agentic commerce begins when software does more than recommend: it takes bounded actions in a purchasing journey on behalf of a person or business.The short definition
Agentic commerce is a purchasing journey in which an AI agent can discover options, make selections, and initiate or complete defined actions for a buyer. The buyer may be an individual or a company. The important change is not conversational shopping; it is delegated action. Once an agent can act, the system needs identity, authenticated intent, spending boundaries, risk controls, approval paths, and durable evidence.
One journey from request to decision
Imagine a small company gives a procurement agent the task: “Renew our Notion workspace if the monthly charge remains under $120.” A controlled journey looks like this:
- 1A person defines intent.The operator names the purpose, budget, categories, limits, and conditions requiring review.
- 2The agent finds an option.It identifies Notion, the $96 amount, the software category, and the merchant country.
- 3The agent requests authority.It submits structured transaction facts using its own scoped credential. It does not submit a verdict.
- 4Policy evaluates the request.Deterministic code checks identity, agent status, remaining budget, limits, merchant and category rules, geography, and expiration.
- 5Risk can escalate.A new merchant, unusual amount, velocity spike, or geography mismatch can require human review, but risk cannot erase a hard decline.
- 6A decision and evidence return.The response is APPROVED, APPROVAL_REQUIRED, or DECLINED, with the exact checks and risk factors recorded.
In Mandate’s current MVP, the flow ends with a simulated authorization decision. No payment is sent and no card or bank credential is involved.
The systems have different jobs
| System | Its job | What it must not assume |
|---|---|---|
| Person or business | Define intent and remain accountable | That a vague prompt is a complete financial policy |
| AI agent | Discover, compare, select, and request | That completing a task means it may authorize itself |
| Authorization layer | Apply identity, policy, budget, and review rules | That model confidence is financial permission |
| Merchant or commerce protocol | Describe products, carts, checkout, and order state | That an agent request proves buyer authorization |
| Payment provider | Move money using protected payment infrastructure | That payment acceptance replaces upstream intent controls |
Why mandates are becoming important
Industry protocols increasingly separate the commercial action from proof of authority. Google’s developer guidance describes the Agent Payments Protocol as a layer of typed mandates and configurable guardrails, while the Universal Commerce Protocol focuses on the commerce journey between buyer surfaces, businesses, and payment providers. Visa’s official Intelligent Commerce overview describes agentic commerce as discovery, decision, and transaction activity performed with user permission and clear controls. Stripe’s current documentation similarly emphasizes scoped payment credentials for agent-initiated purchases.
These references show a shared architectural direction, not a Mandate integration claim. Mandate currently simulates the authorization-control layer and is not connected to AP2, UCP, Visa, Stripe, or any real payment network.
Where Mandate is relevant
Commerce protocols can help an agent communicate with a merchant, and payment providers can protect credentials and execute a charge. A business still needs to answer an internal question before either step: is this specific agent allowed to make this specific purchase, under the authority we granted?
Mandate models that decision point. It gives each agent a narrow identity, a versioned policy, a budget envelope, scoped credentials, risk escalation, human review, and an audit trail. That makes it suitable as an authorization gateway placed between an agent’s proposed action and a future downstream commerce or payment adapter.
What a production design should preserve
- Authenticate the person, organization, and requesting agent separately.
- Represent financial permissions as structured, versioned rules.
- Keep the authorization decision deterministic and independently testable.
- Require explicit human review for ambiguity or elevated risk.
- Bind every decision to the policy version and facts evaluated at that moment.
- Use idempotency and budget reservations to prevent duplicate or concurrent overspend.
- Keep payment credentials outside the agent and authorization model whenever possible.
Continue with the Mandate knowledge base for the product vocabulary or review the frequently asked questions.