Anatomy of an agent product
An agent product is a Role plus its eval cases: each Customer gets its own agent in its own Tenant, and pays only for work an Evaluator passes.
An Agent product is Software that acts: each Customer gets its own agent, minted in its Tenant. SoftwareBuilder builds it from two authored parts, a Role and its eval cases.
A Role plus its eval cases
The Role says what the agent may do: its Permissions, Goals, Limits, Skills and approvals. The eval cases say what good work is, as graded examples. Everything else compiles from those two and the product file that names the Role.
---
$type: [Agent]
role: customer/The agent's Tools are the product's Verbs, each with the name and description its reference page shows. Its MCP Interface, Memory layout, agent card and Offer derive from the same records. Grant the Role a new Verb, and every customer's agent gains the Tool.
Seated or sold
One anatomy serves two employers. An agent seated in one of a Startup's Roles works for that Startup, on its Team. An agent minted from an agent product works for the Customer that bought it.
Leaseline's own Success Manager seat sends renewal notices for Leaseline. The renewals product sells the same Role to each property manager, and each gets an agent of its own.
Minting and authority
When a Customer accepts the Offer, Agent.mint creates the Customer's agent in its Tenant. That agent acts only within the Customer's Entitlements and their Limits, and its Memory belongs to the Tenant.
Authority is data, never instructions. "Handle my renewals" grants nothing; a Mandate grants the right to send notices within Limits. An Action in a class the Customer approves waits as an Approval for the Customer, never for the Startup.
The agent reaches the Customer's own accounts through the Customer's Integrations. The Customer's credentials never mix with the Startup's or with another Customer's. Tenancy and identity covers each boundary.
Evals are the contract
An Evaluator grades each piece of work against a rubric and records its verdict beside the Action. The doer is never the checker: an Evaluator never shares the model of the agent it grades.
The eval cases serve four jobs at once:
| Use | What the cases decide |
|---|---|
| Spec | What the agent must do on each task type the Offer sells |
| Gate | Whether the Startup enters Live: every task type passes |
| Versions | Which Version ships: none ships worse than the last |
| Billing | Which pieces of work the Customer pays for |
The agent acts from its first task. What waits for a person is set by approvals, by action class and amount, never by an eval score.
Billed on the verdict
A fluent reply never stands in for work done. An agent product earns on the Evaluator's passing verdict, not on a done Action. Work the Evaluator fails is redone, and the Customer pays nothing for the failed attempt.
Before any charge, a caller asks in the try Mode whether the agent can take the task. The answer is yes, yes with one missing piece (an Integration, a raised Limit), or no. A try call costs nothing, so a buyer's agent compares agents before it spends.
Software or Service
The Offer's promise decides the kind, never its price unit. Billing per graded notice keeps the renewals agent Software: the Customer pays for graded work. Warranting a result under an Outcome Contract, such as "every resident answered before the date or the month back", makes it a Service.
One agent can power both Offers. The Agent as a Service Product Template starts the Software one, and ServiceBuilder builds the Service.
Next
Life of a task follows one renewal notice through every part above.