On August 18, AWS announced that Amazon Bedrock AgentCore Payments is officially available, which means that AWS is beginning to allow AI Agents to make payments on their own while performing tasks.
Over the past year, AWS has continuously introduced Runtime, Long-Term Memory, Identity, Gateway, Policy, and Observability around Agents. These components address how Agents operate, how to retain memories, what identity to use to access external services, which tools can be called, and how the entire execution process is limited and tracked. Now, Payments completes the payment aspect.
In 2025, AWS mentioned in a public sharing at a summit in New York:
Making AWS the best place to build the world’s most useful AI agents.
That is, to build the most useful AI Agents on AWS.
AWS does not aim to create the smartest Agent but rather a foundational platform that can accommodate different models, frameworks, and Agents. Agents need runtime, memory, identity, tools, and they also require payment capabilities. What AWS is doing is layering these capabilities outside the models.
Therefore, we can look at what AgentCore Payments is doing with this goal in mind.
AgentCore Payments: Enabling Payments for AI Agents
In simple terms, it enables payments as a capability that can be invoked when an Agent executes a task.
For example, a research Agent is helping a company conduct market research. It finds a paid dataset or a pay-per-use API. In the past, this is where the task would usually break: a human would need to register an account, bind a payment method, purchase a plan, and then assign the API key to the Agent. Now, this payment can happen directly within the Agent’s task process.
Developers first set a payment session for the Agent, specifying how long it can make payments, the maximum amount per transaction, the total budget, and connect a wallet provided by Coinbase or Stripe Privy.
When the Agent calls a paid service, the service responds with pricing and payment requirements. AgentCore Payments first checks if the expenditure complies with pre-defined permissions and budget, then calls the external wallet to complete the payment. Once the payment is successful, the Agent requests the service again with the proof of payment, and the service delivers data or results after verification.
Thus, AgentCore Payments does not provide the Agent with a card to swipe at will. The money remains in the external wallet, and the budget and permissions are still set by humans or enterprises. What AgentCore Payments does is integrate payment decisions, wallet calls, and payment records into the Agent’s execution process.
*Image source: AWS AgentCore Payments GA Announcement*
This diagram can be viewed from top to bottom.
At the top are the Agents and the paid APIs, content, and data they need to access. Agents can find these services through the AgentCore Gateway or Browser, but as soon as the service requires payment, the original task process will have an additional payment decision to make.
The middle section, Payment Manager, is responsible for handling this payment. The left side, Payment orchestration, connects to wallets and processes payments, while the right side, Payment guardrail, checks authorization and spending limits. This means the Agent can request payments but can’t unilaterally decide the budget or bypass pre-set limits.
Further down are the wallets that actually provide funds and the protocols that execute payments. Currently, it supports wallets from Coinbase and Stripe Privy, as well as two machine payment protocols: x402 and MPP. The wallets are responsible for signing and disbursing funds, and the protocols ensure that the Agent exchanges prices, payment requirements, and payment proofs with the paid services in machine-readable formats.
At the bottom, Identity and Observability handle identity and recording. Identity stores the credentials needed for wallet connections, which the Agent cannot see; Observability records if payments are successful, how much was spent, which Agent and payment session initiated it, facilitating enterprise audits later.
The current product primarily serves paid APIs, MCP tools, and digital content. Travel bookings, physical product purchases, refunds, fraud, and dispute resolutions are much more complex, and AWS has not demonstrated that these scenarios have reached any scale. The formal availability of the product does not indicate that Agent Commerce is now mature.
AWS Aims to Create the Foundational Platform Behind Agents
Why would a cloud company want to enable Agent payments?
Creating an Agent demo today is no longer difficult. Pick a model, write a system prompt, connect several tools, add a loop, and the Agent can search, reason, and perform tasks.
The real challenges usually arise after the demo: Where does the Agent run? How to save state and memory? What identity is used to access external services? Which tools can be called? What actions must be denied? How to recover after a failure? How are decisions tracked each time?
These questions do not determine whether the Agent is smart in the demo but do determine whether enterprises are willing to let it act in reality.
AWS’s understanding of Agents is shifting from “models plus tools” to a complete production workload.
In traditional cloud computing, a workload has never just been a piece of application code. It also includes computing, storage, networking, databases, identity, permissions, monitoring, security, and billing. Enterprises can replace the upper applications, but once these runtime relationships settle into the cloud platform, migration becomes difficult.
The same applies to Agents.
Models are responsible for reasoning but do not automatically resolve issues of isolation, state, identity, tool access, policy execution, auditing, and payment. The more autonomous the Agent is, the more critical these capabilities beyond the models become.
The product matrix of AgentCore may appear complex, but it is all centered around these production issues: Runtime is responsible for running and isolating, Memory saves state and memories, Identity manages identity and credentials, Gateway connects tools, Policy restricts what the Agent can do, and Observability records what it has done. Now, Payments also incorporates budgeting and payment.
AgentCore Harness brings these capabilities together. Developers define models, tools, and instructions while AWS provides memory, identity, isolated environments, and operational monitoring. When more customization is needed, teams can still write their own orchestration logic, but the underlying capabilities used are still the same set from AgentCore.
This is exactly the product approach that AWS is most familiar with: abstracting out the infrastructure that development teams repeatedly build into callable, composable, pay-as-you-go cloud services.
Twenty years ago, AWS did not invent servers, databases, or storage needs; it merely reorganized these capabilities into the cloud.
Today, it is attempting to do the same for Agents.
Models Can Change, But the System Behind Agents Will Remain
In this strategy, AWS does not require developers to only use its own models and frameworks.
AgentCore supports various open-source frameworks and allows developers to use models outside of Amazon Bedrock. AWS is also integrating open protocols such as MCP, A2A, and x402 rather than requiring all components to use AWS's private interfaces.
This appears quite open. However, for AWS, the easier it is for models and frameworks to change, the more reason it has to shift its competitive position lower.
The leading models today may not remain so in six months, and the Agent frameworks can also iterate quickly. If the platform bets all its value on a single model or framework, it must continuously bear the risk of changes in upper-level technologies.
However, the identities, networks, tool directories, permissions policies, operation logs, purchasing relationships, and billing of enterprises do not change at the same speed. Once these capabilities are built around AgentCore, they become harder to migrate than models.
Thus, while AWS remains open to models and frameworks, it does not mean it lacks platform ambitions. Open interfaces allow for more models, tools, and Agents to enter AWS; identities, permissions, tools, logs, and billing ensure that enterprises' operational relationships gradually settle within AWS.
Models can change, but the systems behind Agents will not change easily.
From Developer Entry to Enterprise Budget and Agent Payments
If there were only AgentCore, AWS would still just be an infrastructure provider. Now, it is weaving together development, operation, distribution, procurement, and specific applications into a more complete commercial pathway.
Strands serve as a developer entry, lowering the development barrier for Agents through an open-source SDK. Harness and Runtime handle production operations, allowing both simple and complex Agents to use the same underlying capabilities.
The Marketplace connects third-party Agents, tools, MCP services, and professional services with enterprise procurement. Enterprises can purchase through their existing AWS accounts, managing licenses, payments, and user access in a unified manner; some products can even run directly on AgentCore Runtime or be invoked by Agents through Gateway.
The importance of this step goes beyond just adding an "Agent app store."
The resistance to enterprises adopting Agents has never just been technical. Who signs the contracts, whether the software can fit into the existing budget, how legal and security reviews are conducted, how licenses are allocated, and how costs are settled will all determine whether a product can truly be sold.
AWS Marketplace already possesses this procurement network. AgentCore integrates the procured tools into the operational environment and permission system.
Thus, a pathway is gradually forming:
Strands attract developers, Harness and Runtime manage production, AgentCore handles identity, tools, and permissions, and Marketplace connects third-party supply with enterprise procurement.
AWS is not just providing servers for Agents. It is starting to organize the supply, operational environments, distribution, and enterprise budgets for Agents.
Payments have further advanced this pathway. In the past, AgentCore managed where Agents run, what they remember, and under whose identity they call which tools. Now, AWS is also starting to manage whether an Agent can spend money, how much it can spend at a time, and what records are left after payments.
From the perspective of Agentic Payment, payment has never been just the final financial settlement. The more difficult questions are: How can the Agent spend money? Who can it pay? Who is responsible if something goes wrong? Can the entire transaction be explained and audited?
AWS is turning these questions into cloud platform capabilities.
If in the future APIs, models, data, and digital services increasingly adopt pay-per-use, what AWS manages will not only include the computational and tool flows of Agents but also part of the cash flow.
AWS has already produced a usable product, but whether the market will adopt it on a large scale, whether enterprises will grant payment permissions to Agents, and how refund and responsibility issues will be handled remain unanswered.
"Openness" and "Lock-in" Can Happen Simultaneously
The completeness of AWS's product matrix does not guarantee that the developer experience is always leading. Whether enterprises adopt AgentCore also depends on debugging experience, cost transparency, and the difficulty of integration with existing systems. While Payments is already officially usable, it does not mean that enterprises will immediately grant large-scale payment permissions to Agents.
On the other hand, while AWS opens up models, frameworks, and protocols, it simultaneously allows identities, permissions, memory, tool directories, logs, procurement, and payments to gradually settle on its platform. Openness lowers the barriers to entry; the more complete the systems built on AWS are, the higher the migration costs will be.
This is why openness and lock-in can occur simultaneously.
In the era of cloud computing, AWS did not decide what software enterprises would ultimately run but became the underlying computing, storage, networking, identity, and security infrastructure for numerous software.
In the Agent era, it is attempting to replicate the same position: not demanding to possess the strongest models or requiring all Agents to be developed by AWS, but hoping that more and more Agents run on AWS, connecting tools through AWS, managing identity, permissions, and billing via AWS, and completing transactions within budget.
Thus, what AWS is truly betting on is not a single Agent product.
It is betting on:
The more autonomous the Agent, the more important the underlying systems of operation, permissions, costs, and responsibilities will become.
If this judgment holds true, the significant winners of Agentic AI may not only be companies with the smartest models but could also include the cloud platform that enables different models, frameworks, and Agents to operate, invoke tools, be procured by enterprises, and complete transactions within authorized limits.
AWS aims to occupy this position.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
