Customize an agent product
What each customer changes for its own agent, what the builder changes for every customer, and the rule that keeps the two apart.
A customer narrows its own Agent; the builder changes the product for every customer. A customer's change never widens what the product allows.
What a customer changes
| The customer sets | Where | Bound by |
|---|---|---|
| What asks first, by action class and amount, as Approvals | Its Mandate for the agent, in the Portal | The product's Entitlements |
| Which of its accounts the agent uses | Its Integrations | The grants its admin approves |
| How much the agent does per period | The Mandate's Limit | The Offer's Limits |
| A rule for its own agent, such as "never offer more than one month free" | Tenant rules, status planned | The Role contract |
Mandate.authorize never widens a Permission past the authorizer's own. A customer can make its agent ask more often or do less; it cannot make it do more than the product sells. The approvals per customer page has the rules.
What the builder changes
The builder changes the product file, the Role, its eval cases and its Evaluators. Each change builds a new Version, and none ships worse than the last on the eval cases.
| To change | Edit | Reaches customers |
|---|---|---|
| What the agent may call | verbs in the product file | On their next Version |
| Its instructions, standards and default approvals | The Role file | On their next Version |
| What good work is | Its eval cases and Evaluators | Gates every Version |
| Its price | Its Offer file | New Customers; existing ones keep their terms |
Memory is not a setting
Each agent learns inside its own Tenant: a building's quiet hours, a manager's preferred sign-off. That Memory belongs to the Customer and never trains another Customer's agent.
Next
Operate covers running the agents once customers use them.