AI Licensing Model: The User, the Agent, the Model

TL;DR An AI licensing model pairs a value metric with a grant. In a product with AI capability the grant has three parties to address: the person operating the software, the agent acting against it autonomously, and the model producing the output. Most agreements we read name only the user. The agent is the definition left open, and the deal desk meets it at renewal as a discount request. The agent grant is a definition question that identity infrastructure enforces and cannot settle. The model grant, in the agreements we see, is a product name and a service level; which model, supplied by whom, running where, stays the vendor’s business unless the customer supplies the model. Three questions at the end test an agreement for all three.

A software licensing model pairs a value metric with a grant, and that pairing holds for every software product. In a product with AI capability it breaks in a specific direction: the agreement was written for a person, and agents and models now act inside it without the agreement mentioning either. The licensing in question is the vendor’s: how a software product that carries AI capability is licensed to its customers. Licensing a model’s weights or training data is a separate subject.

When the grant names only one of the three, the other two go unaddressed, and at the deal desk that silence resolves as a dispute.

What an AI Licensing Model Grants

A licensing model is two decisions: the value metric and the grant. A software licensing model establishes both halves.

The two halves of an AI licensing model: the metric and the grant

The metric decides what is counted: seats, API calls, tokens, resolved conversations. The grant decides what holding the counted unit permits: who may access, where, under what identity, for how long. Grant dimensions include assignment, deployment, duration, and boundedness.

In an AI product the grant has three parties to address.

Grant 1: the user, the person operating the software

The first grantee is the human, and conventional SaaS agreements assume it without saying it. The grant reads: a user with a valid license may access the product under these conditions. Nothing in that sentence requires the user to be a person, because until recently nothing else could hold a login. The agreements that never named the human were the ones left exposed when something else started operating the software.

Grant 2: the agent, autonomous software acting against the product

The second grantee is an AI agent: autonomous software that invokes the product’s capabilities without a human initiating each action. For the definition of what an agent runtime involves, see what an agent harness is. Agent here means autonomous software. The per-agent licensing of contact-center products counts human agents and is a different construct. Most agreements never ask the agent’s grant question.

Grant 3: the model, and where it runs

The third party is the model itself: the generative AI system producing outputs inside the product. Three questions follow: which model, supplied by whom, running where. In the agreements we see, those questions are answered by a product name and a service level, with the model itself left to the vendor. Agreements written before generative capability shipped do not raise them at all.

The User Grant Decides Where Agent Activity Lands

What “user” means when a person is not the one clicking

The agreements we read split into two kinds, and the split decides where agent activity lands.

When the grant describes users as people, an agent does not fit the definition. The agent is software running against the product, and nothing in the grant says that software counts as a person, so its activity sits outside the grant. No vendor decided to exclude it. That vendor holds the definition: the customer is running something the agreement never licensed, and the resolution is an agent grant written for what the customer runs, opened as a licensing conversation.

When the grant says “user” and nothing more, the agent fits. Across our corpus this is the shape at established software companies whose agreements defined a user generically, with nothing in the grant that tied it to a person. Agents and other non-human callers ride under those licenses, and usage per license climbs. The renewal conversation then turns to a lower license count, because each licensed user is now doing the work of a person and a fleet. The generic definition is what makes the seat give-back request hard to refuse.

Why an AI licensing model keeps its per-user grant

The failure sits in the unspecified grant; the per-user grant itself holds up. Keeping the metric anchored to people is a legitimate architecture choice; per-seat licensing covers a range of assignment decisions, and each variation changes what the grant has to say.

We see the gap closed in two ways. In some cases the grant is rewritten to cover what the customer runs. In others the grant stays as written and the vendor asks the customer to move to an edition, a packaging answer to a licensing gap. The definition of a user and the license grant on that edition can differ entirely from the agreement they signed.

The Agent Grant: Work Nobody Signed For

What the agent grant has to answer

An agent grant answers a distinct set of questions. Whether an agent may exercise a unit at all. On whose behalf it acts. Under what identity it is recognized by the system. Whether agent activity is counted in the same unit as human activity, or a different one.

Identity infrastructure, license and entitlement management included, enforces whatever the grant says and settles nothing about what it should say. We have watched vendors ship agent identity management while the agreement still says ‘user’ and nothing more. The tooling records which agent did what. Whether the agent was entitled to do it was never settled, so the record has nothing to enforce against.

When does agent usage already sit inside a consumption metric?

A consumption metric contains agentic usage only when the metric captures the agentic work and the inference cost underneath it. If the agents never trigger the counted event, the vendor still pays to run them and still bills nothing for it. Swapping from a per-seat metric to a usage-shaped metric that agents happen to bypass moves the number without resolving the grant.

For the question of who absorbs the cost when an agent burns compute and returns something unusable, that argument belongs to when the agent is wrong.

The difference between an agent grant and an agent seat

An agent seat is a unit. An agent grant is what holding that unit permits. Choosing a per-agent seat count commits to a metric before anyone has observed what the agents do and which event carries the value. The grant question comes first. The unit question follows once the definition is stable.

The Model Grant: Which Model, Supplied by Whom, Running Where

Where the model runs is its own grant question

Where the software runs and where the model runs are two separate grant questions. Software license deployment rights already covers the first question.

The agreements we see typically specify where the software is deployed and say nothing about where the model runs inference. When the vendor’s model runs in a different cloud region than the customer’s data, or when the model is third-party infrastructure the vendor passes through, the agreement’s deployment clause does not resolve the question.

What changes when the customer supplies the model

When the customer supplies the model, a cost the vendor was carrying comes out of what it delivers. A unit priced to include model access charges a different amount than a unit that assumes the customer brings the model. The bring-your-own-model case owns this argument in full; the relevant point here is that the grant has to say which assumption it is operating on.

Selling in its own units while buying in a supplier’s metered units leaves the vendor pricing a component it buys from someone else, the question pass-through or recast addresses directly.

Model substitution: what the agreement names

Which model sits behind the product, and when the vendor swaps it, is the vendor’s own business, and vendors treat it as their IP.

Part of what a customer buys from an application vendor is a single party answerable for the output, whatever is running underneath. The model swap stays inside the vendor’s walls, and the customer’s recourse when output quality shifts runs through the SLA.

The open question in the agreements we read is whether the service level is written in terms the output can be tested against.

What Breaks When One Grant Carries All Three

A single user grant leaves agent activity and the model unaddressed, and both reach the deal desk at renewal inside one undifferentiated number.

The deal desk sees a pricing dispute because the customer’s bill is higher than their headcount justifies. The underlying problem is that the agreement counted users it assumed were people while the product ran agents, and the service level never said what the output had to meet. Neither fact is visible in the renewal invoice.

The pattern we see most often: the vendor’s renewal team cuts the seat count to match the customer’s headcount and absorbs the agentic consumption in the margin. Nobody writes the grant language for next year. The gap carries forward.

Settling the Definition Before Choosing the Metric

Settle what a user is before committing to a value metric. Observe what customer agents do before choosing the metric that counts them.

Build the capability to iterate against live accounts. Not every agent run looks the same. An agent that executes one tool call and terminates is a different usage event than an agent that runs for minutes, calls external APIs, and writes to the customer’s database. A metric chosen before that distribution is observed may capture one type and miss the other.

The full commercial response sequence, including how to handle seat compression, how to watch before repricing, and how to approach existing accounts, belongs to AI agents and seat count repricing.

Three Questions to Ask of Your Own Agreement

These are the questions that reveal whether the three grants are present, absent, or deferred.

First: What does your agreement say a user is, and would that definition survive a customer whose agents do most of the clicking? If the definition names people without addressing automated processes, the agent grant is missing.

Second: Does your value metric capture the agentic work and the inference cost underneath it? Whether the metric is consumption-shaped is a different question. If agents operate on a pathway the metric does not touch, the metric relabels the exposure without containing it.

Third: What does the agreement name on the model side? Where the customer supplies the model, that assumption has to appear in the grant because it changes what the unit includes. Where the vendor supplies it, the service level is the only instrument the customer holds when the output changes.

If any of the three questions returns a gap, the gap is in the grant. The commercial response starts there, before any price moves.

If you are working through these questions on live agreements, talk to a pricing expert who has seen the pattern before.

These three questions also test any new agreement. The agreements we read that answer all three have addressed their three parties.

The rest of the licensing hub sits in the licensing category archive.

FAQs