The question of whether the $30 cost of a Copilot License is worth it feels very much like a thing of the past – businesses (and even consumers) are now paying way more than that across different AI tools and models and as we get closer to the end of 2026, whenever the conversation turns to the cost of AI agents, the first question is usually

How many tokens or Credits are we using to do x?

It is a fair question. Tokens, credits and API calls are visible, measurable and eventually appear on an invoice. Just last week, I consumed almost $200 in Copilot Credits testing out and building a new app using the new Cowork App Builder Experience (ooops).

But Tokens/Credits are only part of the cost.

As organisations move from Copilot-style personal assistance (writing emails, summarising meetings, refining Word, Excel and PowerPoint docs), towards building and using agents that retrieve information, update records, trigger workflows and act across business systems, the economics of agents become much broader.

We are no longer simply paying for an answer.

We are paying for a digital “employee” that needs an identity, data, infrastructure, security, permissions, monitoring and, most importantly, an accountable owner.

That changes the conversation completely.

Tokens Are the Easy Bit to See

Consumption is usually the most visible part of the bill and bit that gets scrutinised because it has a number in a report or bill!

The number of tokens or credits an agent consumes will vary according to the model being used, the information it needs to process, the number of steps it takes, how long it works for, the external services it calls and how often it has to retry or refine its work.

A simple retrieval agent might find and summarise a policy.

A more capable agent could read an email, inspect a customer record, check an order, apply a business rule, update a system and prepare a response.

Both may be described as AI agents. Their consumption profile will be very different.

This is why estimating agent costs from a few short prompts can be misleading. Multi-step agents may process far more information than a traditional chat interaction because they are planning, checking, calling tools and progressing work across several stages.

Depending on how you count and group them, there are typically seven aspects which make up the total cost and many of these often go un-measured.

• Core consumption (token/credits)
• Platforms and re-platforming
• Infrastructure
• Governance
• Human Workforce effort (effort to build, test, update)
• Failure and recovery
• Compliance.

Consumption matters of course as this is typically the bill we look to manage, control and optimise, but this alone does not tell you whether the agent did anything useful and whether the wider investments and effort are (or were) worth it.

The Platforms Around the Agent

Before an agent performs can undertake any meaningful work, it needs somewhere to run and something to work with.

• An AI model or model service (SaaS) or on your own infrastrcuture
• An agent creation or orchestration platform
• Cloud services and storage
• Line of Business applications
• APIs, MCPs and connectors
• Identity and access controls
• Monitoring, security and compliance services
• Development, test and production environments

Some of these costs will be fixed subscriptions (for example your M365 Copilot License), whilst others will be based on usage/consumption based (Cowork, Codex, Github Copilot etc). Some may already sit within your wider Microsoft Agreement, cloud, security or application agreements, making them difficult to attribute to a particular agent.

This creates a common problem. The agent looks inexpensive when viewed in isolation because many of its supporting costs are sitting elsewhere.

The organisation pays the full bill. It is just split across different budgets.

Infrastructure Matters More than Ever

AI agents may feel like software, but software still needs infrastructure and you will likely have more agents running around in the future than you do people!

An agent may need to navigate several data sources, traverse multi-cloud services, access line of business applications or communicate with other agents on different platforms. If an organisation uses or is training their own local models, private cloud services or on-premises data, the agent may also need to traverse corporate networks and data-centre connectivity to complete its task.

That makes network performance part of the user experience.

Wireless quality, latency, congestion, packet loss, internet connectivity and the route between applications and data can all affect how consistently an AI service performs. A slow response may not be caused by the model. The delay could sit somewhere between the agent, its tools and the information it needs.

The infrastructure cost might not be labelled “AI agent”. It may appear as additional cloud consumption, API traffic, database activity, integration services, network upgrades or security monitoring.

This is one reason AI cannot be treated as a isloated app or service.

In my recent work on building an enterprise AI practice, I described AI as a front door into wider transformation across data, cyber security, cloud, networking, workplace technology and managed services. AI conversations quickly expose whether the foundations underneath the idea are ready to support it.

A clever agent built on poor data, unreliable connectivity or weak integration is still a poor solution.

Identities, Owners & Reporting Lines

As agents begin to act for people and teams and work “on their own”, we need to manage them (and what they can do and access) with many of the same disciplines we apply to people.

That does not mean pretending an agent is an employee (though we do hear the phrase digital employees banded about) It means recognising that anything acting inside the organisation needs an identity, a defined role, clear permissions and a reporting line.

• A named business owner
• A technical or operational owner
• A clearly defined purpose
• An approved identity
• Access based on least privilege and risk
• Defined limits on the actions it can take
• Human approval for higher-risk decisions
• Monitoring, logging and regular access reviews
• A route for escalation
• A reliable way to suspend or retire it (essentially to turn if “off”).

The reporting line matters because an agent cannot be accountable for itself, but a human or a team can!

If it accesses the wrong data, performs an incorrect action or behaves unexpectedly, somebody must be responsible for investigating what happened and deciding what comes next.

Agents should not become orphaned identities that continue to operate long after the person who created them has changed role, left the organisation or moved on to something else.

Accountability must remain with people, even when the work itself becomes automated.

Security must follow the Risk

Not all agents create the same risk.

An agent that retrieves public information is very different from one that can access employee records, approve financial transactions, change a customer account or trigger an operational process or operate hardware.

The controls should reflect that difference.

Agents need risk-based access policies that consider what they are attempting to do, which information they are accessing, the environment they are operating from and the potential impact of the action.

Their permissions should be grounded in the job they have been given, not in everything the creator happened to be able to access.

• Which data sources the agent can use
• Which records or information classifications it can access
• Which tools, MCPs, and APIs it can call
• Whether it has read or write access
• The financial or operational thresholds within which it can act
• Which actions always require human approval
• What should happen when the context or risk changes

The important question is not simply whether an agent can reach a system. It is whether it should be allowed to perform a particular action, in that context, without a person being involved.

As agents become more capable, organisations will need to bring together identity, conditional access, data protection, threat monitoring, audit and agent-level controls. Our recent Autonomous AI Agents: Building the Foundations for Success webinar highlighted the need for visible agent inventories, ownership, permissions, data controls, monitoring and a way to switch an agent off when it is no longer required.

This is not security being added after the agent is built. This is secure by design.

It is part of the design.

Governance Costs, but Weak Governance Costs More

Once an agent can act, somebody (or somebodies) needs to decide what it is allowed to do and this must be reviewed (think appraisal).

• Who created the agent?
• Who owns the business process?
• What information can it access?
• Which systems can it update?
• What can it do without approval?
• Where does a person need to step in?
• How is its activity recorded?
• What happens when something goes wrong?
• Who can suspend or retire it?

These controls require time, technology and people.

But treating governance as an optional overhead is a false saving.

An agent operating at machine speed can expose weak permissions, poor data and broken processes much faster than a person working through the same task. Autonomy therefore needs to be earned through testing, measurable value, security, governance and accountability.

This is not about slowing innovation down. We can still build prototypes at scale, try things out and innovate, but we need controlled environments and need to treat PoCs different to live pilots and production ready AI.

It is about giving useful agents a safe route into production.

People are part of AI Cost Too

AI and AI Agents can work with us, work for us and they will change how work is done. This is far more than just adding another button or a chat interface to an application.

Someone has to understand the current process, how and why it works (or doesn’t), decide what should change (and why), design and test the new approach, and help people work with it. It must also be documented.

There is lot of human work that goes into this. Yes AI can help us build apps, and flows and even agents, but for real transformation, humans will still be accountable for:

• Process discovery and redesign
• Training and communications
• New responsibilities for process owners
• Human approval and escalation routes
• Support for employees whose work is changing
• New skills across IT, security, legal, risk and operations
• Ongoing review as models and platforms change

This cost is frequently missed from early business cases I see (yes I was guilty of that too as we often see our time as given).

Organisations often calculate the cost of adopting and deploying AI, building an agent or transforming a workflow, but overlook the effort needed to put it into real work.

Once AI becomes part of day-to-day operations, it needs to be monitored, governed, secured, measured and continuously improved.

Deployment is not the finish line. It is not like a one off project or upgrade of your phone system or meeting room.

Who do you Call when the Agent Gets It Wrong?

This is often the least comfortable part of the calculation.

Like people, Agents can and will make mistakes. They can make decisions based on poor or out-of-date data, misunderstand an instruction, call the wrong tool or follow a badly designed process perfectly. They might stall unexpectedly and the agent or organisation may run out of credits or there might be an outage or “blip”.

This requires a process/back up – which can be hard to cost in sometimes. Either way, if this runs a business process it may need:

• A person reviewing and correcting the work
• Ability to re-running the process or re-test it
• Reversing an incorrect transaction
• Manually handling a customer complaint
• Investigating what happened
• Flagging or Fixing data or permissions
• Legal or regulatory review

A failed answer in a chat can be inconvenient.

A failed action in a live business system can be expensive, cause reputational damage or worse.

The more authority an agent has, the more important it becomes to define boundaries, approval points and recovery processes.

As we expand what agents can do, guardrails are needed, cyber protection must be in place (to protect our agents like we do our network, devices and identity), human oversight included, and predefined boundaries and controls for stopping unexpected behaviour has to be part of our AI strategy.

Human involvement should not be added randomly at the end. It should be placed at the points where judgement, consequence or accountability matters.

Compliance Keeps on Going

AI regulation, internal policy review and industrial and regulatory requirements continue to develop.

Even where a specific agent appears low risk, the organisation may still need to retain records, explain how decisions were made, demonstrate appropriate oversight and prove that access is controlled. We have new AI acts such as EU AI Act, and more coming as global and local governments continue to adapt and keep up with the rapid developments in AI technology and the risks associated with those developments.

Those requirements create ongoing work across legal, compliance, security, audit and data governance.

Again, these costs may not appear on the “agent’s invoice”. But they are part of operating it.

The mistake is not spending money on compliance.

The mistake is discovering the requirement after the agent has already become embedded in a process.

The Bigger Question: Is the Agent Worth Running?

This might sound really obvious but sometimes the answer is no or I don’t know.

The right comparison is not simply:

How much does this agent cost?

It is:

What outcome does it deliver, and is that outcome worth more than the total cost and risk of running it?

That requires a broader view of value and must also be evaluated periodically.

Does the agent reduce handling time? Improve accuracy? Increase throughput? Remove avoidable administration? Improve customer service? Reduce risk? Help people spend more time on work that needs their judgement?

If its a scheduled task, does it ad value, does anyone do anything with the output or things that it does and if we stopped it, would it matter?

In a recent AI Cost Optimisation webinar I co-hosted, I framed this around fixed licensing, token consumption, infrastructure, security and governance, alongside the need to monitor usage before costs run away.

Cost without context tells us very little.

This is where AI FinOps needs to grow beyond cloud cost reporting.

It needs to connect consumption to a named agent, a business process, an owner and an outcome.

❌ A cheap agent that nobody uses is a waste of money.

✔️ An expensive agent that safely removes a major operational bottleneck may be excellent value.

Cost without context tells us very little.

Where to (re)Start

This is not about throwing in the towel or stopping, but as we set out on looking at where and how AI can (or cannot) help elevate, improve, change or evolve our business, we should avoid trying to calculate the cost of an entire future agent estate before they have evidence.

As we evolve beyond say Copilot in M365, and look more towards business process innovation with AI, start with one defined process.

1. Understand how it works today.
2. Measure the time, cost, delays, errors and hand-offs.
3. Decide which parts require human judgement, and which could be automated.

Then build the simplest agent that can prove the outcome. Measure impact, cost and value (and cost to build)….

Remember as we move from PoC to Pilot and beyond that an Agent/AI process needs:

1. A named business and operational owner
2. A clear purpose and reporting line
3. Its own managed identity
4. Least-privilege access to approved data and systems
5. Risk-based controls over what it can do
6. Human approval at important decision points
7. A consumption budget
8. Monitoring, activity logs and regular reviews
9. A support and recovery process
10. An off switch

Our recent Cisilion agent webinar recommended building and testing agents outside production, setting budget caps and continually evaluating agents rather than treating them as one-off builds.

That is far more useful than starting with a broad instruction to “build lots of agents”.

Don’t Stop Me Now…

This is not about stopping or restarting, it is about understanding (and helping the business or AI agent maker) understand that the true cost of an AI agent is not the token bill.

It is the combined cost of the model, platform, infrastructure, connectivity, integration, identity, security, governance, people, change, monitoring, failure and ongoing operation.

But that should not put us off.

It should help us make better decisions.

The winners will not be the organisations with the most agents. They will be the ones that know which agents they have, who those agents report to, what they can access, what they are allowed to do, what they cost and whether they are producing measurable value.

Building an agent is becoming easier | Operating one properly is the real work.