Seat or usage pricing? Compare contracts for agent workflows

Seat pricing comes under pressure when a substantial share of work no longer corresponds to a human account. That is a proposition to test, not a deadline for the model to disappear.

For a business buying software, the useful question is practical: what will the invoice look like after an automation changes the workload? Fewer active accounts, more API traffic and a new review process can pull costs in different directions.

When a seat still represents value

A seat is an authorised identity. In collaborative software, another person may need their own permissions, audit history and access to shared work. Charging for those identities can remain understandable and predictable.

The relationship becomes weaker when one integration processes a growing volume without adding people. It can also weaken in the other direction: an organisation may pay for several accounts that rarely participate. Neither case proves the provider is acting against the customer. It is a reason to compare the contract with actual use.

Before cancelling seats, identify who still needs to approve documents, handle exceptions, maintain the integration and take responsibility for decisions. A shared login is not a sound substitute for separate identities and permissions.

What an agent changes—and what needs proving

An agent may read data, prepare proposals or perform permitted actions through tools. Which of those it can do depends on the product, configuration and credentials. It is not safe to infer end-to-end autonomy from the presence of an API or MCP server.

Consider a hypothetical process that moves from five active human accounts to one supervisor and an agent. Reducing five equally priced seats to one would reduce that component of the invoice by 80%. It does not establish that the same work gets done, that the contract permits the change or that total cost falls by 80%.

The comparison also needs usage charges, failed attempts, supervision time and the cost of recovering from a mistake. Keep the quality requirement constant. Processing more documents is not an improvement if more of them need correction.

Compare the billing unit before the headline price

Seat, consumption and hybrid models distribute cost differently. A seat can make the monthly bill stable while activity varies. Consumption follows a measured unit, which makes both the definition of that unit and spending controls important. A hybrid combines a base charge with included or additional use. Stripe’s overview of pricing models describes these alternatives and their tradeoffs.

Outcome pricing adds a different question: what counts as an accepted result? An invoice draft, an approved invoice and a collected payment are different events. A contract needs to specify which one is charged and what happens when work is rejected or repeated.

A three-month simulation you can reproduce

These are invented tariffs to compare billing units. They are not Frihet prices or a provider quotation. Assume the plans meet the same access and feature requirements; taxes, discounts, support and human review costs are excluded.

• Plan A: 5 seats at €20 each per month.
• Plan B: €20 per month plus €0.10 per billable event, with no included events.
• Every event in the table is billable; do not assume an event is an accepted business outcome.

The two invented bills meet at 800 events: (100 − 20) / 0.10. Below that point Plan B costs less under these assumptions; above it Plan A does. This is a price comparison, not a recommendation to change products.

Now stress the unit definition. If 2,000 useful tasks produce 2,500 billable events because retries count too, Plan B costs €270. If the contract excludes retries, the result changes. The distinction belongs in the calculation before a purchasing decision.

Metering deserves its own acceptance test

A published unit price is only half of a usage contract. You also need to understand how activity becomes a bill. Stripe documents meters and usage events in its usage-based billing documentation. That is a mechanism reference, not evidence that a particular vendor has configured it correctly.

Use a small evaluation workload with a known number of requests. Include a retry, a rejected result and a cancelled job. Compare the activity log, the usage counter and the invoice preview. Record differences rather than assuming the largest number is the right one.

Ask what happens when a spending threshold is reached. An email warning and a hard spending cap have different effects. Establish who can change the limit, whether processing stops and how unfinished work is recovered. A cap that interrupts a critical workflow also needs an operational plan.

A free plan is one route to evaluation

A permanent free plan, a time-limited trial and an evaluation environment can each help a buyer test a product. Their usefulness depends on the workload, setup effort and boundaries of the offer. None removes the need for a person or organisation to authorise credentials, permissions and spending.

Frihet’s current offer and limits are on its pricing page. Its MCP server is a separate documented surface. Review the available tools and permissions for the intended workflow rather than treating access to the server as proof that a whole business process can run unattended.

A useful trial ends with an evidence sheet: required features, actual usage, exceptions, review effort, export results and the projected bill for a busy month. The smallest invoice is not necessarily the least expensive workflow.

What to request before changing the contract

Take three months from your own records: a quiet month, a typical month and a busy month. Keep seasonal peaks and failed attempts visible rather than averaging them away.

Ask the provider to calculate each month under the proposed terms. Request the unit definition, included allowance, overage calculation, agent identity policy and treatment of retries in writing. Confirm what happens to historical data and access if you reduce seats.

Finally, repeat the comparison after a small controlled rollout. Check the actual bill against your projection and compare review effort and accepted results. A model that looked suitable before automation may remain suitable; a different one may fit better. The decision should follow those observations, not a claim that one pricing model has reached its expiry date.

Sources checked on 17 September 2026. The scenarios are editorial examples, not measured customer results or a proposed change to Frihet’s plans.