Imagine telling an AI agent, “Order the usual office supplies every Monday. Keep the total below ₹5,000. If anything costs more than 10% above the usual price, ask me first.” The interesting part is not that the agent understands the sentence. The interesting part is what happens next. It has to identify the correct products, check inventory, compare prices, interpret purchasing rules, verify that it is authorized to spend money, initiate payment, handle failures, record the transaction, and potentially reverse the purchase if something goes wrong. That is no longer a chatbot problem. It is a distributed systems problem with money attached to it.
Agentic commerce changes the relationship between people, software, merchants, and payment networks. Instead of a customer manually selecting an item and approving every transaction, an AI agent can interpret intent and execute a transaction on the customer's behalf. GeekyAnts' exploration of agentic commerce brings this shift into focus through concepts such as delegated authority, agent identity, mandates, payment infrastructure, and transaction recovery.
The difficult question is therefore not simply, “Can an AI agent buy something?” It is “Can an AI agent spend money without becoming an uncontrolled financial actor?”
The New Actor in the Commerce Stack
Traditional e-commerce generally looks like this:
Customer → Merchant → Payment Network → Bank
Agentic commerce adds another layer:
Customer → AI Agent → Merchant → Payment Infrastructure → Bank
That extra actor changes the security model. A human purchasing a laptop can recognize that a suspicious seller, incorrect specification, or unexpected shipping fee might require further consideration. An agent operates according to the information, tools, permissions, and policies exposed to it.
Consider a simple instruction: “Buy the cheapest compatible replacement.”
What does “compatible” mean? Should shipping be included in the price? Can the agent use an unfamiliar marketplace? Can it buy a different model if the original is unavailable? Can it spend ₹6,000 when the user's limit is ₹5,000? Can it complete the transaction without another approval?
These are authorization and policy questions, not prompting questions. Agentic commerce therefore needs a dedicated control layer around the model.
The Agent Should Not Own the Money
Giving an AI agent unrestricted access to a credit card would be similar to giving an employee a company card with no spending policy, transaction limit, or audit system. A safer architecture separates agency from financial authority:
User
↓
Intent + Policy
↓
AI Agent
↓
Scoped Authorization
↓
Payment Authorization Layer
↓
Merchant
↓
Payment Network
The agent should receive permission to perform a particular class of action rather than unrestricted access to the underlying financial credential.
This resembles principles already used in OAuth, IAM, API security, and temporary credentials. A payment authorization could effectively define:
{
"agent": "procurement-agent",
"principal": "company-123",
"maximum_transaction": 5000,
"daily_limit": 25000,
"currency": "INR",
"allowed_category": "office-supplies",
"approval_required_above": 3000
}
The agent proposes a transaction. The authorization layer determines whether the transaction is permitted. The payment infrastructure executes it. The model should never become the financial security boundary.
Identity Comes Before Authorization
Before asking whether an agent can purchase something, a payment system needs to know who the agent represents.
This becomes particularly important in enterprises where multiple agents operate for the same organization:
Organization
├── Procurement Agent
├── Travel Agent
├── Finance Agent
├── Customer Support Agent
└── Infrastructure Agent
A procurement agent may be allowed to purchase equipment. A travel agent may book flights. A finance agent may process invoices. An infrastructure agent may provision cloud resources. They should not automatically inherit the same permissions.
This creates a useful identity model:
Principal → Agent → Delegated Authority
The principal is the person or organization. The agent is the software acting on its behalf. Delegated authority defines what that agent is actually allowed to do.
The concept of identifying and authenticating an agent becomes increasingly important as autonomous systems move into regulated financial workflows. An agent should be identifiable, auditable, restrictable, and revocable just like other privileged software identities.
A Prompt Is Not a Security Boundary
One of the easiest mistakes is treating the system prompt as an authorization mechanism:
You can spend up to ₹5,000.
Do not purchase electronics.
Ask for approval above ₹3,000.
This may guide the model, but it should never be the final enforcement mechanism.
A production architecture should separate reasoning from authorization:
AI Agent
↓
Proposed Action
↓
Policy Engine
↙ ↓ ↘
Budget Merchant Category
↘ ↓ ↙
Authorization
↓
Payment Layer
The model can decide, “This is the product that best matches the user's request.”
The policy engine decides, “The agent is permitted to purchase this product for this amount.”
A deterministic policy engine can enforce rules such as:
agent_id = procurement-agent
transaction_limit <= ₹5,000
daily_limit <= ₹25,000
merchant_category = office-supplies
currency = INR
approval_required_if > ₹3,000
The model reasons. The policy engine governs. The payment system executes.
The Mandate Is the Agent's Financial Constitution
An agent needs more than an identity. It needs a mandate.
A mandate defines the authority delegated to the agent. It can specify transaction limits, categories, currencies, merchants, approval thresholds, geographic restrictions, expiration dates, and other constraints.
This starts looking less like chatbot configuration and more like an IAM policy.
The distinction is important because an agent may be continuously active. A human might make several purchases during a week. An autonomous agent could potentially initiate hundreds of transactions. A small authorization mistake can therefore become a large financial incident.
A mandate limits that blast radius.
Product Data Is Becoming a Security Input
There is another problem that is easy to overlook: agents make decisions based on data.
Consider a product API:
{
"product": "Filter X",
"price": 499,
"currency": "INR",
"stock": "available",
"compatibility": "Model-X"
}
A human may question suspicious information. An agent may simply consume it.
That makes product metadata part of the agent's decision-making environment. Incorrect pricing can lead to unexpected spending. Incorrect compatibility information can result in unsuitable purchases. Stale inventory can produce failed transactions. Manipulated descriptions could influence an agent's selection.
Agentic commerce therefore needs stronger controls around data provenance, schema validation, price freshness, inventory synchronization, merchant identity, product attributes, delivery information, and return policies.
The storefront is no longer simply presenting information to a person. It is feeding structured information into an autonomous decision-making system.
Checkout Is Becoming an API
Traditional commerce is centered around the checkout page. Agentic commerce changes that architecture:
Browser
↓
Product Page
↓
Cart
↓
Checkout
↓
Payment Form
can increasingly become:
Agent
↓
Product Discovery API
↓
Structured Offer
↓
Policy Evaluation
↓
Authorization
↓
Payment Token
↓
Merchant API
↓
Settlement
This represents a fundamental change. Websites were primarily designed for people to click. APIs are designed for software to act.
That does not mean graphical interfaces disappear. It means the underlying commerce capabilities need to become machine-readable.
Emerging agent and commerce protocols are moving in this direction by making product discovery, tool access, checkout, and other transaction capabilities easier for software agents to consume.
MCP Does Not Magically Give an Agent a Wallet
It is important to separate tool access from financial authorization.
A useful way to think about the stack is:
Reasoning
↓
Tool / Context Access
↓
Product Discovery
↓
Identity
↓
Mandate
↓
Policy
↓
Payment Authorization
↓
Settlement
↓
Observability
↓
Recovery
An agent might be allowed to search a product catalog without being allowed to purchase from it. It might be allowed to prepare an order without being allowed to submit payment. It might be allowed to purchase office supplies but not electronics.
Granular permissions reduce the blast radius of an agent failure.
The Most Important Feature Could Be “Undo”
Most software systems are designed around the happy path:
Request → Process → Success
Financial systems cannot stop there. They need:
Request
↓
Authorization
↓
Payment
↓
Settlement
↓
Reconciliation
↓
Refund / Reversal / Dispute
Imagine an agent purchases the wrong laptop because a merchant's compatibility data was incorrect.
Can the payment be reversed? Who initiates the refund? Can the agent request the refund? Does the user need to approve it? What happens if the merchant API is unavailable?
These questions need answers before the transaction happens.
A system that can autonomously purchase something but cannot reliably recover from an incorrect purchase is only half-built.
Undo is not merely a customer-support feature. It is part of the transaction architecture.
Distributed Systems Problems Follow the Agent
Agentic commerce also inherits classic distributed-systems problems.
Consider this sequence:
Agent → Payment Request
↓
Payment succeeds
↓
Network timeout
↓
Agent assumes failure
↓
Agent retries
Without idempotency, the retry could create a duplicate transaction.
The solution is not simply telling the model, “Don't retry.” The transaction layer needs semantics that make retries safe.
For example:
transaction_id = TXN-87421
idempotency_key = ORDER-2026-87421
The payment infrastructure can then distinguish a legitimate retry from a new transaction.
The same principles apply to timeouts, retries, circuit breakers, transaction state machines, reconciliation, event processing, duplicate requests, and eventual consistency.
The AI component may be new. The distributed-systems problems are familiar.
Observability Needs to Follow the Decision
Traditional payment logs might contain:
Transaction ID
Merchant
Amount
Payment Status
Authorization Status
Timestamp
Agentic commerce needs more context:
transaction_id
agent_id
principal_id
mandate_id
policy_version
tool_call_id
product_id
merchant_id
authorization_decision
payment_token_id
human_approval
timestamp
The objective is not necessarily to capture private model reasoning. It is to preserve enough structured evidence to answer:
Why was this transaction allowed?
A production incident should be traceable across:
User Intent
↓
Agent Action
↓
Tool Call
↓
Policy Evaluation
↓
Authorization
↓
Payment
↓
Merchant Execution
↓
Settlement
This becomes important for security investigations, compliance, fraud detection, debugging, dispute resolution, and regression testing.
A financial transaction that cannot be explained is difficult to govern.
India Could Have an Interesting Advantage
India already has a mature real-time digital payment ecosystem. UPI provides a foundation on which agentic payment experiences could potentially be built, while delegated payment concepts such as UPI Circle provide useful ideas around controlled financial delegation.
A possible architecture could look like:
AI Agent
↓
Identity
↓
Delegated Authority
↓
Policy Engine
↓
Payment Authorization
↓
UPI
↓
Merchant
The opportunity is not necessarily creating another payment rail. It is creating the identity, authorization, policy, and recovery layers that allow autonomous software to operate safely on existing payment infrastructure.
The important question becomes:
“Is this agent allowed to pay?”
and evolves into:
“Is this specific agent, acting for this specific principal, authorized to execute this specific transaction under these specific conditions?”
That is a much stronger security model.
B2B Procurement May Be the Bigger Opportunity
Consumer shopping is the easiest demonstration of agentic commerce.
Enterprise procurement may be where the technology becomes substantially more valuable.
Consider an infrastructure agent responsible for purchasing cloud resources. Its mandate could specify:
Approved providers only
Monthly budget: ₹10 lakh
Region: India
No annual commitment without approval
Approved instance families only
Autonomous purchases below ₹1 lakh
Approval required above ₹1 lakh
The agent can monitor requirements, compare approved providers, evaluate pricing, check existing commitments, execute authorized purchases, validate invoices, and escalate transactions that exceed its mandate.
That is not simply AI-powered shopping.
It is autonomous procurement governed by policy.
The same architecture could apply to travel booking, software procurement, cloud infrastructure, advertising, supply-chain purchasing, expense management, and vendor payments.
Trust Becomes the Product
The smartest model will not automatically create the most trusted commerce agent.
Trust requires infrastructure.
Identity: Who does the agent represent?
Authorization: What can it do?
Policy: Under which conditions can it act?
Security: What credentials can it access?
Observability: Can every transaction be traced?
Recovery: Can mistakes be reversed?
Governance: Who is accountable?
Data quality: Is the information driving the decision reliable?
The model is only one component of that system.
This is why agentic commerce should be approached as an engineering discipline rather than simply another application of generative AI.
A Practical Agentic Commerce Architecture
A production-ready architecture could look like this:
User / Organization
↓
Intent + Policy
↓
AI Agent
↓
Tool / Data Layer
↓
Identity + Agent Mandate
↓
Policy Engine
↓
Budget / Risk / Permission
↓
Payment Authorization
↓
Tokenized Payment
↓
Merchant / API
↓
Payment / Settlement
↓
Audit / Observability / Recovery
Notice what is missing from the center of the architecture:
Unrestricted access to the user's money.
That is intentional.
The goal is not to prevent agents from acting. The goal is to make their authority narrow, measurable, reversible, and auditable.
The Real Question Isn't Autonomy
The natural race in AI is toward greater autonomy.
But in commerce, autonomy without control is a liability.
The better question is:
How autonomous can an agent become while remaining governable?
That changes the engineering priorities.
Do not start with the model. Start with the mandate.
Do not give the agent unrestricted payment credentials. Give it scoped authority.
Do not treat prompts as security boundaries. Enforce policies outside the model.
Do not design only the successful transaction. Design the reversal path.
Do not treat product information as harmless metadata. Treat it as an input to an autonomous decision system.
And do not measure an agent only by whether it can complete a purchase.
Measure whether the entire transaction can be authorized, observed, explained, reconciled, and reversed.
That is the real foundation of agentic commerce.
The future checkout may contain fewer buttons. Behind those missing buttons, however, will be a much larger engineering stack.
Because the moment software gets the ability to spend money, trust stops being a feature and becomes part of the API.
Frequently Asked Questions
What is agentic commerce?
Agentic commerce is a model in which AI agents can discover products, evaluate options, and execute transactions on behalf of people or organizations within defined permissions and policies.
Should an AI agent have direct access to a credit card?
An agent should generally operate through controlled payment infrastructure rather than unrestricted access to the underlying credential. Scoped authorization and tokenization can reduce exposure and limit what the agent can do.
Can a prompt control an agent's spending limit?
A prompt can communicate a spending rule, but it should not be treated as the enforcement mechanism. Spending limits should be enforced through deterministic authorization and policy infrastructure.
Why does an agent need its own identity?
An agent needs an identifiable identity so systems can determine who it represents, what authority has been delegated to it, what actions it performed, and when its permissions should be revoked.
Why is idempotency important in agentic payments?
Agents can retry requests when they encounter network failures or timeouts. Idempotency prevents a retry from accidentally creating a second financial transaction.
Why is product data a security concern?
An autonomous agent may use product price, availability, compatibility, merchant information, and other metadata to make purchasing decisions. Incorrect or manipulated data can therefore directly influence financial actions.
Is MCP a payment protocol?
No. MCP can help agents interact with external tools and data. Payment authorization, financial permissions, tokenization, settlement, and transaction controls require additional infrastructure.
Why is transaction recovery important?
Autonomous systems can make incorrect decisions or encounter failures after a transaction has already been authorized. Refunds, reversals, reconciliation, and dispute mechanisms therefore need to be considered part of the original architecture.
Where could agentic commerce have the biggest impact?
Enterprise procurement is particularly interesting because it involves recurring purchases, budgets, supplier restrictions, approval thresholds, invoices, and large transaction volumes that can be governed through explicit policies.
What is the biggest technical challenge in agentic commerce?
The hardest problem is not making an agent capable of purchasing. It is creating a trustworthy control system around that capability so every transaction has appropriate identity, authorization, observability, accountability, and recovery mechanisms.
Top comments (0)