The Agentic Commerce Stack: Why Seven Layers Need One Foundation

AI agents are beginning to move from search and recommendation into authorization, negotiation, checkout, settlement, and post-purchase service. That shift changes the basic unit of digital commerce. The browser session is no longer the only transaction surface. The buyer may be a human, but the actor touching the merchant, payment network, identity layer, and compliance record may be software.

That is the promise and the risk of agentic commerce. It can compress discovery, decision-making, and checkout into a more useful buying experience. It can also create a trust crisis if the ecosystem cannot answer five simple questions: who is the agent, what is it allowed to do, how will it pay, who is accountable if it fails, and how can a merchant participate without rebuilding its entire stack?

The answer will not be one protocol. It will be a stack.

Key Takeaways

Agentic commerce is bigger than AI shopping or conversational checkout. It is a new transaction model where software agents discover, decide, authorize, pay, and report within bounded rules.

The category needs seven coordinated layers: agent identity, permission and intent, payment rails, protocol routing, reputation, compliance reporting, and merchant discovery.

The market still has five strategic gaps to close: identity, authorization, interoperability, accountability, and merchant readiness.

KYA, or Know Your Agent, should become the agentic commerce equivalent of KYC and KYB: a machine-verifiable trust layer for software actors.

Autheo can claim the Commerce OS category by positioning TheoID, DevHub, protocol routing, payment rails, reputation, mission compliance, merchant readiness, and Foundation grants as one coherent development roadmap.

Agentic commerce needs seven coordinated layers: agent identity, permission and intent, payment rails, protocol routing, reputation, compliance reporting, and merchant discovery. Each layer is already emerging in pieces. Google introduced Agent Payments Protocol, or AP2, as an open protocol for agent-led payments developed with more than 60 organizations, and positioned it as usable with Agent2Agent and Model Context Protocol, or MCP (Google Cloud). Google also introduced Agent2Agent, or A2A, as an open protocol that lets agents communicate and coordinate actions across different vendors and frameworks, with support from more than 50 technology partners and service providers (Google Developers Blog). Anthropic describes MCP as an open standard for connecting AI assistants to data sources, business tools, and development environments, replacing fragmented custom integrations with a single protocol pattern (Anthropic).

Those are important building blocks. They are not the foundation by themselves.

The missing foundation is the layer that binds identity, authority, payment, routing, reputation, auditability, and merchant readiness into one coherent operating model. That is where Autheo's thesis begins: agentic commerce will need a Commerce OS, not just more payment buttons.

The problem: commerce still assumes a human is clicking buy

Most digital commerce infrastructure was built around a simple assumption: a human browses, compares, clicks, authenticates, and pays. Fraud systems, user interfaces, cart flows, refund processes, loyalty systems, and merchant analytics all evolved around that pattern.

Agentic commerce breaks the pattern.

Google frames the core shift directly: existing payment systems generally assume a human is directly clicking "buy" on a trusted surface, but autonomous agents can initiate payments in ways that challenge that assumption (Google Cloud). AP2 responds with signed mandates that capture user intent, cart approval, and payment authorization, creating what Google calls a non-repudiable audit trail from intent to cart to payment (Google Cloud).

That is a major step forward. But payments are only one slice of the problem.

An agent that can buy also needs identity. An agent that can hold credentials needs a permissions model. An agent that can interact with many commerce protocols needs a router. An agent that can act repeatedly needs reputation. An agent that can trigger regulated transactions needs compliance reporting. A merchant that wants to be discovered by agents needs a machine-readable way to expose products, policies, capabilities, and constraints.

Without those layers, the market risks recreating the same fragmentation that slowed Web3 adoption: one identity flow over here, one payment rail over there, one compliance record in a different system, one merchant manifest format somewhere else, and a developer forced to glue it all together by hand.

Autheo has written often about this broader infrastructure challenge. Agentic payments need crypto rails, but rails alone are not enough. AI agents need identity, but identity alone is not enough. Onchain AI agents need a different architecture, but architecture alone is not enough unless merchants, payment providers, developers, and compliance teams can all read the same trust signals.

That same foundation is why Autheo treats agentic commerce as part of a larger Web3 infrastructure market shift. The next phase of adoption depends on stacks that connect identity, compute, storage, settlement, compliance, and developer tooling into something usable for real applications.

The stack has to be designed as a stack.

The seven layers of agentic commerce

A useful agentic commerce architecture should separate concerns without fragmenting responsibility. Seven layers matter most.

The seven layers can be understood as a set of operating questions:

Agent identity: Who is this agent? Merchants and networks need to distinguish trusted agents from unknown or malicious actors.

Permission and intent: What is the agent allowed to do? Users need bounded delegation, not vague authorization.

Payment rails: How does the agent pay? Cards, bank rails, stablecoins, and future rails need a shared authorization model.

Protocol routing: Which protocol should handle this interaction? MCP, A2A, AP2, UCP, ACP, TAP, and other protocols will coexist.

Reputation: How has this agent behaved before? Repeated agent actions need history, scoring, and policy signals.

Compliance reporting: Can the mission be reconstructed later? Regulated teams need audit trails that show authorization, execution, and outcome.

Merchant discovery: How does a merchant become agent-readable? Long-tail merchants need a path into agentic commerce without custom integrations.

Agent identity

The first layer is identity. A merchant should not have to guess whether an inbound agent represents a verified wallet, a registered platform, an enterprise buyer, a personal shopping assistant, or a malicious bot.

The Web already has a strong credential pattern to build from. W3C describes Verifiable Credentials as a way to express credentials on the Web in a format that is cryptographically secure, privacy respecting, and machine-verifiable (W3C). A verifiable credential includes claims and metadata, plus mechanisms that cryptographically prove who issued it and that the data has not been tampered with (W3C).

For humans, the market already understands KYC. For businesses, it understands KYB. For agentic commerce, the missing category is KYA: Know Your Agent.

KYA should not mean surveillance of every action. It should mean machine-verifiable identity, issuer provenance, authority scope, expiration, revocation status, and policy boundaries. In Autheo's reference architecture, TheoID is positioned as the identity foundation in development for this agent-native trust layer.

Permission and intent

An agent should not be trusted because it says it is helpful. It should be trusted because it can prove what it was authorized to do.

AP2's mandate model is valuable because it separates user intent from cart selection and payment authorization. Google describes AP2 mandates as tamper-proof, cryptographically signed digital contracts that serve as verifiable proof of a user's instructions, signed by verifiable credentials and used as foundational evidence for a transaction (Google Cloud).

The broader stack needs that pattern beyond payments. Permission should include merchant category limits, spend limits, time windows, refund rules, data-sharing limits, delivery constraints, and human approval thresholds. A procurement agent buying office equipment has different authority than a travel agent booking flights or a treasury agent moving stablecoins.

This is where agentic commerce becomes more than checkout automation. It becomes delegated authority with cryptographic boundaries.

Payment rails

Payments are where theory becomes liability. If an agent makes a purchase, every participant needs to know whether the action was authorized, whether the amount matched the instruction, whether the merchant was within scope, and how disputes will be resolved.

Visa Intelligent Commerce describes agent-specific payment tokens, payment instructions, and commerce signals that can help validate requests against authenticated user instructions and resolve disputes (Visa Developer). Visa's developer overview also states that the product is in the process of development and deployment, and that depicted features may not be available in all markets (Visa Developer). That caveat is useful because it reflects the market's actual stage: the rails are emerging, but the operating model is still forming.

Mastercard's Agent Pay announcement focuses on tokenization, registered and verified agents, consumer control, and transaction transparency. Jorn Lambert, chief product officer at Mastercard, said: "The launch of Mastercard Agent Pay marks our initial steps in redefining commerce in the AI era, including new merchant interfaces to distinguish trusted agents from bad actors using agentic technology" (Mastercard).

The lesson is clear. Agentic payments will not be one rail. They will be a policy layer across rails.

That is why crypto rails matter. Stablecoins, smart contracts, account abstraction, programmable escrow, onchain proofs, and verifiable settlement can give agents new payment primitives that card rails were not originally designed to provide. But crypto rails also need identity, compliance, and reputation to be enterprise-ready. Stablecoins as a default settlement layer will only reach its full agentic-commerce potential if the surrounding trust stack matures with it.

Protocol routing

The agentic commerce market is not converging on a single protocol. It is creating a protocol field.

MCP connects agents to tools, APIs, databases, workflows, and context. A2A connects agents to other agents. AP2 provides a payment authorization pattern for agent-led transactions. UCP aims to standardize commerce capabilities such as product discovery, cart, checkout, and merchant capability publishing.

Google's UCP article describes Universal Commerce Protocol as an open-source standard for agentic commerce that supports multiple transports, including A2A, MCP, and APIs, and allows businesses to publish capabilities through a standard JSON manifest at `/.well-known/ucp` (Google Developers Blog). That matters because merchant readiness cannot depend on every agent builder hard-coding every merchant integration.

The practical conclusion is that developers need a protocol router.

In Autheo's reference architecture, DevHub is positioned to abstract ACP, UCP, MCP, AP2, TAP, and related commerce protocols into one developer experience. The goal is not to pick one winner too early. The goal is to let builders declare intent, required guarantees, payment method, data access, trust level, and merchant capability, then route to the right protocol path.

Without a router, agentic commerce becomes another integration maze. With a router, developers can build agentic experiences without becoming experts in every protocol's lifecycle, schema, security model, and transport.

Reputation

Identity tells a merchant who an agent claims to be. Reputation tells the merchant how that agent has behaved.

Reputation is not a vanity score. It should be a structured signal set: successful mission history, dispute rate, policy violations, expired credential attempts, revocation events, payment failures, merchant feedback, user overrides, compliance flags, and recovery behavior after errors.

This is especially important because agents will not be static apps. They will improve, degrade, change policies, operate under different principals, and act across contexts. A travel agent may be excellent at booking hotels but unreliable at handling refunds. A procurement agent may be trusted for low-value office supplies but not for regulated hardware. A treasury agent may have strong settlement history but require stricter human approval thresholds.

Agent reputation should be contextual, portable, and privacy-aware.

Autheo's agent reputation management concept is still in development, but the need is immediate. When AI agents hold keys, their behavior becomes part of the security boundary. Reputation gives merchants, users, and networks a way to treat agent behavior as a measurable operational signal instead of an invisible risk.

Compliance reporting

The most important question in agentic commerce may come after the transaction: what exactly happened?

A compliance report for an agent mission should reconstruct the mission from all relevant sides. It should show the user instruction, agent identity, credential status, permission scope, protocol route, merchant interaction, payment authorization, settlement record, fulfillment result, disputes or exceptions, and any human approvals.

That is not only for regulators. It is for enterprises, marketplaces, merchants, payment networks, developers, users, and auditors. When agentic commerce works, it will feel simple to the buyer. Behind the scenes, however, the system needs a clear, machine-readable evidence trail.

AP2's mandate sequence points in this direction. Google says the sequence from intent to cart to payment creates a non-repudiable audit trail that answers authorization and authenticity questions and provides a foundation for accountability (Google Cloud). The broader stack should extend that concept to the full mission, not only the payment.

Autheo's mission compliance reporting concept is designed around that broader idea: push-button reporting for agent missions and transactions. The goal is not to overburden developers with compliance theater. The goal is to make the evidence trail native to the transaction architecture.

This fits a pattern Autheo has covered before. AI agents are reshaping blockchain compliance because compliance itself is becoming programmable. In agentic commerce, that programmability needs to start at the architecture layer.

Merchant discovery

The final layer may be the most overlooked: merchant discovery.

Big platforms will integrate first. Long-tail merchants will lag unless the market gives them a simple way to become agent-readable. That means product data, policies, payment capabilities, inventory signals, shipping rules, return terms, service constraints, supported agent protocols, and trust requirements need to be exposed in machine-readable formats.

UCP's `/.well-known/ucp` model points toward this future by allowing agents to discover business capabilities and payment configurations through a standard manifest (Google Developers Blog). But the market should not assume every merchant will adopt every protocol on day one.

The long-tail merchant problem needs tooling. A merchant should be able to create an agent-readable manifest, validate it, expose it, and update it without rebuilding its commerce platform. They should not need a protocol team to tell an agent what products are available, what checkout rules apply, or what payment methods are accepted.

This is where Autheo Foundation grants can matter. Ecosystem contributors can help build validators, manifests, adapters, documentation, and extensions that let merchants become discoverable without waiting for every platform to standardize.

The five gaps the market still has to close

The seven-layer stack exists because five gaps remain unresolved.

The identity gap

Agents need identities that are verifiable, scoped, revocable, and distinguishable from human users, enterprise accounts, bots, wallets, and merchant services. KYA should become a core agentic commerce primitive.

The authorization gap

The ecosystem needs more than "the agent clicked buy." It needs explicit user intent, delegated authority, constraints, approvals, and proof that the final action matched the authorized instruction.

The interoperability gap

MCP, A2A, AP2, UCP, ACP, TAP, and other protocols will coexist. Developers and merchants need routing, translation, and abstraction so protocol diversity does not become adoption friction.

The accountability gap

When a transaction goes wrong, someone has to answer what happened. Agentic commerce needs mission-level audit trails, not just payment receipts.

The merchant readiness gap

If only the largest merchants can participate, agentic commerce becomes another platform-controlled channel. The long tail needs machine-readable discovery, lightweight tooling, and grant-supported open infrastructure.

These gaps are not theoretical. They are the difference between a useful agentic commerce market and a fragmented set of demos.

Why seven layers need one foundation

The market can solve each layer separately. In fact, it already is.

Payment networks are building agent payment programs. AI labs are building tool protocols. Search and commerce companies are building discovery protocols. Identity communities are advancing verifiable credential standards. Crypto networks are building programmable settlement, wallets, and account abstraction. Merchants are experimenting with structured product feeds and AI-readable content.

The risk is that each layer solves its own problem in isolation.

If identity does not bind to payment authority, fraud increases. If payment does not bind to user intent, disputes increase. If protocols do not route cleanly, developers slow down. If reputation does not follow agents across contexts, merchants have no memory. If compliance reporting is bolted on later, enterprise adoption suffers. If merchant discovery only works for large platforms, the long tail gets excluded.

One foundation does not mean one company controls every layer. It means the architecture is coherent enough that each layer can reinforce the others.

For Autheo, the opportunity is to define that foundation around a developer-accessible Commerce OS:

TheoID for agent identity and KYA credentials.

DevHub for SDKs, protocol routing, developer workflows, and machine-readable docs.

Agent payment rails for stablecoin, card, bank, and protocol-aware settlement paths.

Agent reputation management for behavior history and trust signals.

Mission compliance reporting for transaction reconstruction and auditability.

Merchant readiness tooling for manifests, capability discovery, and long-tail adoption.

Autheo Foundation grants for open components, extensions, validators, and ecosystem tooling.

This framing also keeps the language honest. These components are in development. The goal is to publish the architecture, invite builders, shape the category, and give the ecosystem a clearer map of what needs to exist.

What developers should build next

The first generation of agentic commerce infrastructure should not try to boil the ocean. It should make the seven layers practical.

Developers can start with focused components:

KYA credential schemas that define agent identity, issuer, scope, expiration, revocation, and authority limits.

Merchant manifest generators that help businesses expose agent-readable products, policies, and payment capabilities.

Protocol route planners that map agent missions to MCP, A2A, AP2, UCP, APIs, and other protocol paths.

Mission compliance report templates that turn intent, authorization, route, payment, settlement, and outcome into an auditable record.

Reputation signal models that separate identity from behavior and give merchants policy-ready trust inputs.

These are exactly the kinds of ecosystem components that can mature through Foundation-backed grants. Autheo Foundation can invite developers to apply for grants to build open extensions, validators, sample implementations, merchant tools, and protocol adapters that advance the broader agentic commerce stack.

The right posture is collaborative. No single team will define agentic commerce alone. But category leadership starts with a clear architecture and a willingness to build the missing connective tissue.

The category claim

Agentic commerce is not just AI shopping. It is not just conversational checkout. It is not just autonomous payments.

Agentic commerce is a new transaction model where software agents discover, decide, negotiate, authorize, pay, and report on behalf of people, businesses, and other systems within bounded rules.

That model needs a stack.

It needs identity so agents can be recognized. It needs permission so delegation is bounded. It needs payment rails so value can move. It needs protocol routing so agents can interact across ecosystems. It needs reputation so trust can accumulate. It needs compliance reporting so transactions can be reconstructed. It needs merchant discovery so every business, not only platform giants, can participate.

Seven layers. Five gaps. One foundation.

That is the Commerce OS category Autheo should claim.

Autheo is developing the foundation for agentic commerce through TheoID, DevHub, protocol routing, agent payment rails, reputation management, mission compliance reporting, merchant readiness tooling, and Foundation-supported ecosystem development. Builders who want to help shape that future can explore Autheo's agentic commerce architecture and apply for grants through Autheo Foundation.