Digital products now have two users. Most business cases count one.

Most business cases for digital products are still built around a person clicking through screens. Funnels, daily active users, conversion rates and time-in-app all assume someone is sitting at the other end.

That assumption weakens every quarter. A growing share of requests now arrives through APIs and MCP servers, sent by an AI agent working on the customer's behalf rather than by the customer directly.

Pricing pages haven't caught up. The UI comes with every plan, while API access is gated, either behind a higher tier or behind rate limits sized for the occasional integration a developer builds.

The human was the rate limit

The UI was never really free. It was cheap because the person using it acted as a built-in throttle. Nobody clicks, reads or decides faster than a few times a minute.

That ceiling was doing structural work in every business case, usually without anyone noticing. It capped infrastructure spend. It made engagement a reasonable proxy for value, since time in the product roughly tracked work done in it. It also made the seat a sensible commercial unit, because each licence implied a predictable load on the backend.

Agents take the ceiling away. They chain tool calls, retry on failure, poll for state changes and run at 3 a.m. A planning step a person would do once, an agent may run a dozen times before it settles on an answer. Every assumption that relied on human pace is now exposed.

Two users, two ledgers

It's tempting to declare human metrics dead. They aren't. People still log in to review, approve and make the calls that matter. What has changed is that the same product now serves two very different users, each with its own economics.

The human user is low-volume, high-intent and expensive to acquire. The agent user is high-volume, uneven in intent and almost free to onboard: one OAuth grant or MCP connection can generate thousands of requests a day. Put both into one set of numbers and the case can look healthy while the unit economics deteriorate underneath it.

Blended metrics mislead in three predictable ways:

• Engagement inflates. An agent polling an endpoint every minute shows up as your most active customer.
• Cost disappears into averages. Agent load gets spread across a seat base priced for people, so margin erodes without ever becoming a line item.
• Value gets counted twice. The agent completes a task, a person approves it, and both the API calls and the UI session are credited with the same result.

The answer is to run two ledgers. Model each user on its own drivers, then reconcile them at the outcome they jointly deliver.

The cost model breaks first

In my experience, revenue isn't the first part of the case to break. Cost is. Revenue erodes over several renewal cycles; cost assumptions can fail within weeks of agent traffic arriving.

A hypothetical, but not an unusual one: a customer on a $50-a-month seat connects an agent over a weekend to clear an invoice backlog. Every call runs the vendor's AI reconciliation feature behind the endpoint, so each request carries model inference, not just a database read. The agent pulls every open record, re-fetches account context at each step and retries every timeout. By Monday it has run up about $400 in backend cost against a plan that still bills $50. Plain reads would have cost a fraction of that. What scales is the work behind the endpoint.

Four traffic patterns account for most of the damage:

1. Loops. An agent working toward a goal hits the same endpoints repeatedly, refining a query a person would have run once.
2. Retries. A vague error makes a person pause. An agent treats it as a reason to try again, and without exponential backoff or idempotency keys, each retry can create duplicate work.
3. Polling. An agent waiting on a status change keeps asking until something tells it to stop.
4. Fan-out. A single request, such as "summarize every account with an overdue invoice", turns into hundreds of paginated calls behind the scenes.

Rate limits are usually the first symptom, and they cut both ways. Limits tuned for dashboard traffic were really tuned for human attention, and they are the reason runaway costs stay rare. But an agent that hits them gets HTTP 429 errors, its workflow fails, and to the customer the product looks broken. Vendors are left with a trade-off: keep limits tight and protect margin while frustrating agent users, or raise the ceiling at the API gateway and absorb the extra compute and database load. Most business cases price neither side of that choice.

Network traffic is only the visible layer. The costs that actually erode margin sit behind it:

• State reconstruction. Agents rarely hold state between sessions, so each run re-queries the records a person would have had open on screen. Behind an MCP server, that often means expensive joins and search queries on every call.
• Inference behind your endpoints. If your product runs its own AI features, such as summaries, classification or retrieval over customer documents, each agent call can trigger model inference you pay for. Uncached retrieval steps and bloated context windows multiply that bill fast.
• Audit and observability. Every agent action needs a record of who authorized it, which tool was called and what changed. In regulated sectors that trail is mandatory, and its storage and monitoring costs scale with call volume, not headcount.

Part of the fix is architectural. Webhooks and event subscriptions push state changes to the agent instead of waiting to be asked, which removes most polling. Batch endpoints, compact responses, cached context and error codes an agent can act on cut down loops, retries and repeated lookups. None of this is free, and not every workload fits an event-driven pattern. That makes architecture a commercial decision as much as a technical one, and it belongs in the business case, not just the engineering backlog.

A two-ledger scorecard

Every case should answer three questions for each ledger. What does it cost to get the work done? What is that work worth? How reliably does it get done? I'd structure the scorecard like this.

Three principles keep it honest:

• Credit each outcome once. Outcomes are counted only in the reconciled view. Sessions and API calls are inputs, not results.
• Track ratios, not just totals. Rising calls per outcome or retries per task are leading indicators that cost is outrunning value.
• Treat hand-offs as both a cost and a signal. When an agent escalates to a person, you pay for the failed attempt and for the human's time. Hand-offs also show where accountability really sits in the workflow.

Hand-offs are also where attribution gets messy. If an agent does 90% of a workflow and a person clicks Approve, which ledger gets the credit? The practical answer is to credit the outcome once, to the workflow, and split its cost by what each user consumed:

$$\text{Cost per outcome} = (\text{agent cost per attempt} \times \text{attempts per outcome}) + (\text{escalation rate} \times \text{human minutes per escalation} \times \text{cost per minute})$$

Retention and expansion then follow the outcome, not the channel. A customer who renews because invoices get reconciled is renewing on the workflow, whoever did most of the work inside it.

This is where the two ledgers meet. Agents handle the volume. People step in when someone has to review, sign off or stand behind a decision, and that is where the human ledger justifies itself.

What goes on the pricing page

Adding a usage meter is the easy part. Deciding how it sits alongside seats is harder. Three structures work for products that serve both people and agents:

Whichever model you pick, one rule should hold: customers pay for completed work, not for your retries. If an agent retries because your endpoint timed out, that cost belongs on your ledger, not on their invoice.

Rebuilding the case

Moving an existing case onto two ledgers is more a reframing exercise than a rebuild. Five steps get most organizations there:

1. Define the outcomes. List the jobs customers hire the product to do: a report delivered, an invoice reconciled, a ticket closed. If an outcome can't be named, it can't be priced.
2. Segment today's traffic. Tag requests as human or agent at the gateway using request metadata: client IDs, OAuth scopes, User-Agent headers and MCP client identifiers. Most teams find automation already accounts for more traffic than they assumed.
3. Model agent load explicitly. Estimate calls per outcome, retry rates, polling frequency and, where your product runs AI features, inference cost per call, then put a cost on each. Keep agent load out of the per-seat average.
4. Choose the meter. Give every channel the same access. Customers reading their own data is part of that access. Compute, write actions and high-frequency calls are the work, priced through one of the models above.
5. Fund the architecture. Budget for event-driven interfaces, sensible defaults and machine-readable errors. These are cost controls with a payback period, not engineering polish.

Count both users

The API pricing debate is a symptom. Charging a premium for API access and giving it away both answer the wrong question: which channel is the customer using? The better question is who, or what, is doing the work, and what that work costs and earns.

Getting there is less a pricing change than an operating-model change. Finance, product and platform teams need a shared view of cost per outcome, and today most of them are reading from different dashboards.

A case that only counts people will misprice the product, misread its health and miss where cost is building up. Run two ledgers, reconcile them at the outcome, and put people where the accountability sits.