Pricing and Packaging for Agent-Mediated Consumption

Per-seat pricing was designed for human users with chairs. When agents do the work, the seat metaphor collapses. The market hasn't settled on a replacement — but the question can't be deferred for long.

Why per-seat breaks

Per-seat pricing assumes a roughly fixed ratio between licensed users and product usage. One user clicks a UI; the volume of work that user produces is bounded by their working hours.

Agents break the assumption in two directions. Up: one customer's agent can fan out into thousands of API calls per hour, producing what would have been months of human work. Down: an entire customer organization may not need any human seats at all — agents specify, agents execute, humans review at the edges.

The result is that per-seat pricing either undercharges (one seat, thousands of calls) or blocks the customer (rate limits designed for human users). Either way, the agent surface is a tax on your product instead of a growth lever.

This is the live tension in the market. Cyclr asks "if a user interacts with your product entirely through an AI agent or an LLM, do they still need a seat?" The framing is vendor-promotional but the question is real, and no competitor has a clean answer yet.

Pay-as-you-go per outcome — the Customer.io pattern

The clearest market signal is Customer.io's Builder Plan. Pricing is $0.40 per 1,000 messages, flat across email, in-app, push, webhooks, and SMS. $10 minimum. No monthly fee. No per-seat.

The strategic choices embedded in this pricing:

Outcome over mechanism. The customer pays per message sent, regardless of whether a human clicked a button, an API call triggered it, or an agent specified it. The mechanism is invisible to billing.
Persona-bundled. Builder Plan is positioned for "AI-native builders working with LLMs, coding agents, and other tools who want messaging as infrastructure." The pricing is part of the persona — same model, same target customer, mutually reinforcing.
Agent surfaces included, not gated. CLI and MCP server access come with the plan. They are not a premium tier or a separate SKU.

This is the only pricing model among the early competitors that is designed for agent-mediated consumption rather than retrofitted around it. Braze, ActiveCampaign, and HubSpot give MCP access away with their existing per-seat or per-feature pricing and haven't yet been forced to confront the unit-economics question.

Three open questions the market hasn't resolved

1. Per-call vs. per-outcome

Should an agent calling your MCP tool 100 times to construct one outcome (say, one campaign) be billed for 100 calls or for one outcome?

Per-call is easy to meter and aligns billing to your infrastructure costs. It also creates an adversarial relationship — the customer's agent is incentivized to minimize calls, even when more calls would produce better results.
Per-outcome aligns billing to customer value but is harder to define (what counts as an outcome?) and harder to meter.

Customer.io chose per-outcome (per message). Stripe charges per API call. Both work. For your product, the choice depends on whether your unit of value is naturally discrete (messages, transactions, deployments) or continuous (compute, storage, time).

2. Loss-leader vs. premium tier

Right now, every B2B SaaS shipping an MCP server is giving it away. The bet: drive adoption while the market is forming; figure out monetization later.

This is a finite window. Two endpoints:

Loss-leader forever. Agent surfaces are part of the base offering. Revenue comes from the outcomes the agents drive, not from the access. Customer.io's model.
Premium tier eventually. Agent surfaces move into an enterprise SKU with audit, observability, governance, and SLAs gated behind a higher price point. Most enterprise software historically.

Mid-2027 is the likely inflection. Until then, free MCP access is competitive defense; after, the question becomes which surfaces ship inside the base offering and which ship inside the premium tier.

3. Tenant-bound vs. agent-bound metering

When billing, do you meter at the tenant level (this customer's entire usage) or at the agent level (this specific agent's usage)?

Tenant-bound is the existing pattern. The customer is the unit of billing. Agents are a usage modality, not a billing entity.
Agent-bound is novel. Each agent has its own metering, spend cap, and rate limit. The customer assigns budgets to agents the way they assign budgets to teams.

Agent-bound is more granular but vastly more complex. For most B2B SaaS, tenant-bound is the right starting point. Move to agent-bound when customer agent-fleet sizes grow past a small handful and customers ask for per-agent governance.

What this means in practice

Three concrete moves for product leaders deciding pricing today.

Audit your pricing model for agent-fragility. If a single customer's agent could 100× its API call volume next month, what happens to your unit economics? If the answer is "we'd lose money," you have an active liability.
Decouple agent surface access from seat count. Make MCP, CLI, and webhooks available regardless of seat tier. Either bundle into base pricing (Customer.io model) or move to a per-outcome SKU.
Instrument before you monetize. You need per-tool, per-tenant, per-agent usage data before you can set prices. The metering infrastructure is the prerequisite — and most products built before 2025 don't have it at the granularity required.

A pricing diagnostic

Is your pricing per seat, per outcome, per call, or per resource?
What happens to gross margin if your largest customer 50× their API call volume next month?
Is access to your agent surfaces (MCP, CLI, webhooks, agent sandbox) gated by tier, or available across tiers?
Do you have per-tool, per-tenant usage metering today?
If a customer's agent runs away (1,000 retries on a loop bug), who pays?

If question 5 doesn't have a clear answer, the bill is going to be a fight.

← Back to AI-Native Product Strategy · Where Agents Discover You