Pricing, entitlements and credits

Today an org either has AgencyCore or it does not: there is no switch to turn on the CRM but not the agents, no meter on how much AI work it runs, and no cap on how many people it seats. Selling tiers means adding all three, and the model keeps them as three independent mechanisms so each stays simple. An entitlement is a per-org on/off switch for one module - can this org use the CRM at all? A credit is the single currency every AI and agent action spends, drawn from a balance that refills each billing period. A numeric limit is a plain plan-set quota, such as the seat count or the daily email volume. Keeping them separate is what lets a plan mix and match modules, a credit stay one currency, and a limit stay a plain number. This page covers the mechanism, not the final price list.

Twelve decisions settle the shape of the model. Grouped into three themes below, each one states the call that was made and why; the sections that follow expand the reasoning, and the linked Linear document holds the full detail.

Some of this already exists. A first billing integration shipped recently: during onboarding the org's card is captured, and an admin triggers the first charge by hand, since there is no self-serve checkout. That work also added a catalogue of plans and a subscription state machine to the database. What it does not do is gate any module or meter usage, and that is what this initiative adds. Four facts from the codebase set the starting line.

Gating is built from three pieces. An entitlement key is a neutral slug for one module (crm, sonar, envoy, and so on); it deliberately does not say whether that module is an app, an agent, or a core feature, so a module can move between runtimes without touching any plan. A plan template is the set of keys a plan turns on. A grant is a per-org exception row that adds a key the plan lacks, removes one it has, or trials one with an expiry date. A resolver service combines the plan template with the org's grants into a single resolved snapshot of which modules the org can use, caches it in Redis, and rebuilds it whenever a plan or grant changes.

That snapshot has to be checked everywhere a change can be written, not only at the API routes, because background jobs and the workflow engine write data without going through a route. Enforcement therefore lives at the four points below, all in the API and frontend layers; pushing entitlement checks down into database row-level security is deliberately left out of the first version.

Try it below. Pick a base plan, then click the entitlement chips to add modules as grants, or pick one module to trial. The resolved snapshot on the right shows exactly which modules the org ends up with and where each one came from. Cross-module actions - an action in one module that reaches into another, such as adding a person to the CRM from an agent app - check the target module's key, so the list of what is allowed flips live as you add and remove access.

A credit is the single balance an org spends on AI and agent work, and it refills each billing period. Work is priced per metered action - a named user action with a fixed credit price, such as running Sonar once or enriching one company - not per underlying API call, so the price does not swing with how many calls a feature happens to make. The list of metered actions is a registry in code, so a typo cannot quietly meter nothing, and the prices sit in a table an admin can tune without a deploy. Each action checks the balance before it runs: at roughly 80 percent used the org gets a warning through the notification system, at 100 percent credit-spending actions stop, viewing data the org already has is never blocked, and an admin can sell a top-up pack to add more. Spend some credits below.

Three more rules sit beside the module switches, all read from the same resolved snapshot. Numeric limits cap how much an org can do, trials open a module for a fixed window, and lapse - what happens when a plan stops being paid for or is downgraded - decides what an org can still do once its access is pulled.

No existing customer loses anything at launch. A one-time migration puts every current org on the Everything plan at the price it already pays - the grandfathering step - and any repricing is a later sales conversation. Enforcement then switches on in the deliberate order below: it ships dark first, meaning the resolver runs and works out what each org should have but blocks nothing, so it can be checked against reality before it can lock anyone out. The build splits into two tickets because the halves are independent. One builds the gating layer - plans, grants, the resolver, and enforcement. The other builds the usage and credits layer - metering, the ledger, and email caps - and its metering phase does not depend on the first ticket, so it can start in parallel.

This page exists to drive a planning conversation. Everything below is still open - a decision to make, not a design already settled. Each item is a question with enough context to take a side; come with a position on each.