Why we price by builder, not by seat

Most software charges for everyone who logs in. We charge for the people who build agents, and nobody else. Approvers, viewers and the people who only ever see an agent's work in Slack are free on every plan, including Free.

We get asked about this often enough, by customers and by investors, that it's worth writing down why.

Who uses an agent

When we looked at the first hundred workspaces, the people in them fell into three groups.

1. Builders. They describe the job, connect the tools, run replays and change the agent when it's wrong. Usually one to three people per team.
2. Approvers. They say yes or no to the steps that wait for a person. Often a whole team: every support agent, every account manager.
3. Viewers. They read runs, mostly when something went wrong or a customer asked a question. Finance, legal, a manager, the person on call.

In a typical 40-person support team, there were two builders, twelve approvers and a long tail of viewers. Per-seat pricing would have charged that team for 40 people to get value from two.

What per-seat pricing would do

Pricing changes behaviour. That's the point of it, so it's worth asking what behaviour you're buying.

If approvers cost money, teams approve less. They route every approval to one person who has a seat, that person becomes a bottleneck, and the obvious fix is to raise the limit or remove the approval. We'd be charging teams to keep the step that makes agents safe to run, and rewarding them for removing it.

If viewers cost money, fewer people read runs. The trace stays an engineering tool. When a customer asks why they got a refund, someone has to ask the one person with access. We spent months making traces readable by anyone; we weren't going to put a price on reading one.

What we charge for

So we charge for two things that actually track the value a team gets.

Builders, because building and changing agents is where the work is, and where most of our product is. Team is $29 per builder per month, or $24 on yearly billing. Business is $79, or $64 yearly.

Runs, because a run is the agent doing a job. Team includes 5,000 runs a month and Business 25,000. Past that, runs come in packs of 10,000 for $40. A replay case costs the same as a run but never counts against the monthly allowance, because we don't want testing to feel expensive.

A team that runs one agent heavily pays for runs. A team that builds many small agents pays for builders. Both feel fair to the people paying, which is the test we care about.

The case where it costs us

There's one shape of customer where this model loses money: a large company with one builder and thousands of approvers, running a high-volume agent that asks for approval on almost every run.

Each approval is a message sent, a notification, an escalation timer, an audit entry. At enough volume that's real infrastructure cost, and the customer pays for one seat.

We decided to accept it. It's rare: fewer than 2% of workspaces look like this. When it happens, it usually means the approval rule is too broad, and the replay data shows it. We'd rather help that team narrow the rule than add a line item that makes every other team think twice before inviting an approver.

Our finance team asked how many seats we'd need. The answer was two. They didn't believe it until the invoice came.

What would make us change it

If approvers ever started doing builder work (editing agents, running replays, changing rules), we'd have to look again, because that's where the cost of supporting a team really sits. For now the line is clear in the product: only builders can change an agent, and only builders are seats.

Pricing is the one part of a product every customer reads closely. We'd rather it said what we believe.

Sample post. Replace the files in content/blog with your own.