Hiring, Not Licensing: What AI Agents Mean for How You Buy Capability

For the last thirty years, buying software meant buying a thing. A product. Something you could install, configure, and use. The licence said: here is permission to run this tool. What you did with it was your problem.

AI agents break that model. You are not buying a tool anymore. You are buying work.

That sounds like a small distinction. It is not. When you shift from a product to a service that actually does things on your behalf, every assumption about the relationship changes. The contracts, the expectations, the liability, the accountability. All of it.

The product model was comfortable

A traditional software licence is clean. You pay for access. The vendor provides the software. If the software has a bug, there is a support process. If you use the software badly and it causes a problem, that is on you.

The vendor is not responsible for what you do with the tool. A spreadsheet company does not owe you anything if your formula is wrong. A CRM vendor does not apologise when a sales rep logs a deal incorrectly. The tool worked. What happened after that was a human decision.

That separation of responsibility is very convenient. And it is under growing pressure.

Agents do things. That changes everything.

An AI agent does not wait to be used. It acts. It drafts emails, processes applications, triages support tickets, flags anomalies, fills forms, makes decisions within a defined scope. You give it a remit, and it pursues that remit.

When something goes wrong, you can no longer point at the human who clicked the wrong button. The agent clicked the wrong button. Or rather, the agent made a judgement call that turned out to be wrong. And someone has to own that.

This is the core problem with applying the old licensing frame to AI agents. Licences are about access to a product. What you actually need, when you're deploying agents, is something much closer to a service agreement or an employment contract.

What "hiring" capability actually looks like

Think about what you agree on when you hire a person. You define the scope of work. You set expectations around quality. You agree on what "good" looks like. You build in accountability for when things go wrong. You have a notice period, a probation period, a way to exit the arrangement if it is not working.

None of that language exists in a standard software licence. But all of it applies when you are deploying an AI agent that is doing real work in your business.

Here is what the equivalent looks like for AI agents:

• Scope of work: What tasks is the agent authorised to carry out? What decisions can it make autonomously, and which need human sign-off?
• Service levels: How fast should it respond? What uptime do you need? What happens when it is unavailable?
• Quality thresholds: What does acceptable output look like? How do you measure it?
• Escalation paths: When does the agent hand off to a human? Who reviews edge cases?
• Liability and accountability: If the agent makes a mistake that costs you money or damages a customer relationship, where does responsibility sit?
• Exit terms: If the relationship is not working, how do you unwind it without operational chaos?

These are not exotic questions. They are the same questions any sensible business asks when it brings someone new on board. We just have not been trained to ask them when buying software.

The liability gap is real

Most AI vendors currently disclaim liability for outcomes as aggressively as possible. The terms of service for major AI platforms typically say something to the effect of: the model may produce inaccurate or incomplete outputs; you are responsible for verifying anything that matters.

That is a reasonable position for a general-purpose tool. It becomes a much harder position to sustain when the vendor is selling you a purpose-built agent that is supposed to handle a specific, high-stakes workflow.

Imagine an agent deployed to handle insurance claims triage. It processes a thousand claims a week. It makes a pattern of errors on a certain claim type. By the time anyone notices, the damage is done. Who owns that?

Right now, the honest answer is: it depends on what you signed, and the contract was probably written to protect the vendor, not you.

This will change. The direction of travel is clear: the EU has the AI Act, which has been in force since August 2024 and creates specific requirements for "high-risk" AI systems covering many agentic applications in areas like employment, credit, and essential services. However, the enforceable obligations for those high-risk systems are not yet live; the deadlines fall around 2026 and there are active proposals to extend them to 2028. The UK is in a different position: there is currently no binding AI-specific legislation, and UK regulators such as the ICO are still developing their approach. In both cases the legal framework is moving, but it has not yet caught up with where vendor contracts need to be.

What good contracts should cover

If you are buying agentic AI capability today, the things worth pushing on in any agreement are:

Audit trails. You need a record of what the agent did and why. Not just outcomes, but the reasoning (or at least the inputs and outputs at each decision point). Without that, you cannot diagnose errors or defend yourself if something goes wrong.

Human override guarantees. The contract should be explicit that a human can halt, override or roll back any agent action. This seems obvious, but it is worth spelling out, especially as agents become more autonomous.

Error rates and remediation. What performance do you expect, and what happens when the agent falls below it? A service credit clause that applies to software uptime is not the same as a remediation process for an agent that made a consequential mistake.

Data boundaries. What can the agent access? What does it retain? If it is processing customer data, you need clarity on whether that data is used to train future models and whether your customers' information is adequately protected.

Termination and portability. If you move away from the vendor, what happens to the workflows the agent was running? Can you export the configuration, the training data, the integration logic? Or are you locked in?

The pricing model will shift too

Traditional software pricing maps to access: per seat, per user, per month. That made sense when software was a passive tool. You were paying for the right to use it.

Agent pricing is starting to move toward outcomes and usage: per task completed, per transaction processed, per hour of work done. Some vendors are already experimenting with success-based fees where you only pay when the agent achieves a defined result.

That is genuinely interesting. It aligns incentives in a way per-seat licencing never did. But it also creates new risks. If the vendor is paid per outcome, it is worth scrutinising carefully how "success" is defined in the contract, because there is an incentive to define it narrowly. And if you are paying per task, you need to understand your volume carefully: per-task costs are harder to predict than a fixed subscription, though fixed subscriptions carry their own traps when usage assumptions shift.

The pricing model you choose shapes the relationship. Choose carefully.

A short history of how we have bought software capability (optional, click to expand)

Software began as something you bought outright. Shrink-wrapped boxes, perpetual licences, one-time payments. You owned the software. You were responsible for everything: installation, maintenance, upgrades, backups. The vendor's obligation ended at the point of sale.

SaaS changed that. Starting in the late 1990s with companies like Salesforce, the subscription model moved maintenance off your plate. You paid monthly, the vendor kept the software running and updated. The relationship became ongoing. But the tool was still passive. You still operated it.

Managed services took another step. Instead of just providing software, vendors started providing people to operate it. Managed security operations centres, managed IT support, managed cloud infrastructure. You were now buying a combination of software and human labour. The accountability relationship got more complex, and contracts got thicker.

AI agents are the next step on that same trajectory. The "human labour" part of the managed service is increasingly the agent. The software and the doing are merging into one thing you buy. The result is a relationship that looks less like a product purchase and more like a staffing arrangement, but one where the legal and contractual frameworks are still catching up with the reality of what is being sold.

What this means in practice

If you are evaluating AI agents for your business right now, the most useful mindset shift is this: stop asking "what does this software do?" and start asking "what work am I delegating, and what happens when it goes wrong?"

That question forces you to think about scope, about oversight, about fallback processes, and about how the vendor relationship works when things are not going smoothly. Those are the same questions you would ask before hiring a contractor or outsourcing a function. They are also exactly the questions that most AI procurement conversations skip.

You do not need to be adversarial about it. A good vendor will welcome the clarity. If they do not, that tells you something.

The shift from tool to workforce is happening whether the contracts reflect it or not. The businesses that get ahead of it will have cleaner integrations, fewer nasty surprises, and a much better sense of what they are actually buying.

How AI with Ash can support you

Whether you are trying to figure out which agents are worth deploying, or you are already in procurement conversations and want a clearer picture of what to look for in an agreement, it helps to talk it through with someone who has been inside both the technical and commercial sides of these decisions.

Book a call and we can work out what the workforce licensing shift actually means for your business and what you should be doing about it now.