Last reviewed: 10 July 2026
Short answer: Seat-based software prices individual access. Agent systems often behave more like shared operating capacity, so they should be evaluated through workload, reliability, controls, and total operating cost rather than login count alone.
Per-seat pricing is easy to understand. A person receives access to a product, and the organisation pays for that access.
An agent that performs work across a shared process has a different economic shape. It may prepare information for several people, run on a schedule, use tools without an interactive user, and retain workflow state that belongs to the organisation rather than one account.
That does not mean every agent product needs the same commercial model. It means seat count is an incomplete measure of what the system consumes and produces.
Access and capacity measure different things
A seat answers: how many people may use this product?
Capacity answers: how much work can this system process within the required limits?
For an agent system, those limits may include:
- model tokens and provider rate limits
- tool calls and third-party API quotas
- scheduled and concurrent runs
- compute, storage, and data transfer
- review and approval workload
- engineering, evaluation, and operational support
- the consequences of delay or failure
Two organisations with the same number of users can have very different capacity requirements. A ten-person team running a high-volume document workflow may consume more infrastructure and oversight than a hundred people occasionally using a research assistant.
Shared workflows make the distinction clearer
The largest operational gains rarely come from giving one person another blank interface. They come from improving how work moves across a process.
Consider a recurring review workflow. A scheduled run gathers data, applies business rules, drafts a recommendation, pauses uncertain cases, and records the reviewer’s decision. Several people may benefit from the result even if only one person opens the review screen.
The useful unit is not the login. It is the completed, correctly governed workflow.
Capacity has more than one constraint
Raw throughput is only part of the picture.
Compute capacity
How many runs, tokens, tool calls, files, or records can the system process in a given period?
Human review capacity
How many exceptions can reviewers examine without creating a queue that defeats the purpose of automation?
Reliability capacity
How much work can the system process while still meeting acceptable error, latency, and recovery targets?
Change capacity
How quickly can rules, integrations, prompts, and evaluations be updated when the organisation or an external dependency changes?
A system can have abundant model capacity and still be constrained by approvals, poor data quality, fragile integrations, or a lack of engineering ownership.
Organisational knowledge can remain with the workflow
A shared system can make instructions, rules, sources, approval paths, and earlier decisions explicit. That reduces dependence on context held only in one person’s inbox or memory.
The benefit is not automatic. Stored information must be current, permissioned, and tied to authoritative sources. Persistent but stale context can make a workflow less reliable rather than more capable.
When implemented carefully, however, the operating knowledge remains inspectable when people change roles or projects move between teams.
Measure outcomes without pretending people are interchangeable
Describing agents as capacity can become misleading if it treats human roles as a simple cost benchmark. People provide judgement, accountability, relationships, creative direction, and adaptation that a workload metric does not capture.
A better evaluation separates the work:
- Which steps are repetitive and well specified?
- Which decisions require accountable human judgement?
- Which exceptions should stop the workflow?
- What evidence does a reviewer need?
- What is the cost of an incorrect or delayed action?
- What new maintenance work does the system create?
The objective is not to convert a salary into a token budget. It is to design a process in which automation and people each handle the parts suited to them.
A practical cost model
For a shared agent workflow, estimate at least four groups of cost:
- Build and integration: workflow design, data work, interfaces, tests, and connections.
- Variable operation: models, compute, storage, external APIs, and data transfer.
- Governance and review: approvals, evaluation, security, audit, and incident handling.
- Ongoing change: dependency updates, new requirements, retraining, and maintenance.
Then compare those costs with the measurable process outcome: turnaround time, backlog, error rate, reviewer time, consistency, and service quality.
Seat count may still matter for access administration or a provider subscription. It should not be mistaken for the complete unit economics of an operating workflow.
Frequently asked questions
Are seats always the wrong model for AI products?
No. A per-user assistant may fit seat pricing well. The mismatch appears when the system runs shared or scheduled work whose consumption and value are weakly related to the number of logins.
Does usage-based pricing solve the problem?
Not by itself. Token or compute usage captures infrastructure consumption but not integration, review, reliability, or maintenance. Total operating cost remains the more useful measure.
What should teams track first?
Start with completed workflows, exception rate, reviewer time, latency, and cost per acceptable outcome. Those measures reveal more than either seat count or raw token usage alone.