What will AI agents cost your company?
Microsoft has named its price. Salesforce, AWS and OpenAI have named different ones. The build-versus-buy decision is no longer just about today's bill.

Microsoft has just named its price. Other vendors have named different ones. For a typical SME, this is a decision to make before your team starts building.
Microsoft has put a price on running AI agents inside your business systems. It is $15 / £12 per agent per user per month, generally available from 1 May, bundled into Microsoft 365 E7 as part of what it calls the "Frontier Suite". In that model, Agent 365 becomes the control layer and agents are managed much like users, with identity, permissions and audit handled through the same admin centre your IT team probably already uses.
Context: an agent is software that sits inside your business and performs a job continuously. A support agent that reads inbound tickets, drafts replies and escalates edge cases. A sales operations agent that updates CRM records and writes follow-ups after calls. A finance agent that processes invoices and flags exceptions. That is the class of system Microsoft, Salesforce, Amazon Web Services and OpenAI are now pricing, and they are not aligned on how it will be charged.
Microsoft has this offering. Salesforce offers credits, per-conversation pricing, or per-user licensing. AWS charges on consumption, so cost scales with usage. OpenAI charges on usage as well. Four serious vendors, four different answers, and no settled view yet on what you will be paying when you deploy an agent.
For a typical UK SME, that is not a theoretical point. It shapes a build-versus-buy decision you are likely to face sooner rather than later.
Take the support agent as a simple example. You want something that reads inbound tickets, drafts replies and escalates the exceptions. There are two ways to approach it. You can have your team build it directly on top of APIs, using models from, say, OpenAI, Claude or AWS, paying by usage and retaining control over how the workflow is assembled. If the economics change in eighteen months, or a better model becomes available, you switch provider and absorb some integration work inside the engineering team.
The alternative is to build the same workflow inside Microsoft's agent layer. It integrates with your identity system, your permissions, your audit trail, and the tools your team already uses such as Teams, Outlook and SharePoint. Delivery is faster because much of the infrastructure is already there. The trade-off is that the workflow now sits inside Microsoft's operating model and is billed per agent per user per month alongside the rest of your estate.
Most teams default to "ship first, optimise pricing later". That approach made sense for the SaaS tools you already run. You could commit, scale, renegotiate at renewal, and if the numbers stopped working you could move. Switching typically meant a data migration and some retraining.
The Microsoft model changes that for the second path. Once the agent is tied into identity, permissions and the admin layer, you are no longer dealing with a component you can swap out over, say, a quarter. You are choosing where the workflow lives. If it sits inside Microsoft's estate, then moving away later means rebuilding the workflow, redefining permissions, reworking integrations and retraining the team. That is a project with cost and lead time, not a contractual adjustment.
There is a reasonable counter-argument, which is that pricing will move, the market will consolidate, and trying to anticipate that too early risks slowing the team down. For the API-led approach, that still holds because consumption pricing keeps switching relatively straightforward. For the Microsoft path, it holds less strongly because the pricing model is tied to how the system is operated, not just how it is called.
The practical implication is narrower than "wait and see". If you are considering an agent that will sit inside your Microsoft environment and depend on its identity and governance model, it is worth modelling the longer-term cost and constraints before you commission the build. The question is not simply what it costs to run, but what it might cost to move.
It will be interesting to revisit in eighteen months to see which of these pricing models has held and which have shifted.