Should an AI agent's limits be the same for every customer?

No, but the variation must be written down, not improvised. The floor is identical for every customer. Above it, a business can set different limits for groups such as new accounts or customers flagged as vulnerable, provided the tiers are defined by people, based on recorded facts, applied at the moment of action and named in every verdict.

Why not one limit for everyone?

Because risk is not uniform. A refund of 200 to a customer of ten years with a clean history is a different decision from the same refund to an account opened last week. One limit for both is either too tight for the first, sending routine work to people, or too loose for the second, inviting abuse.

But the alternative is not to let the agent judge each customer. An agent that decides for itself who deserves a higher limit is making credit-like decisions without a rule anyone approved. That is hard to explain, hard to audit and easy to make unfair.

What can vary, and what must stay the same?

The tiers should be built on facts the business holds on record: tenure, verification status, product, risk rating, a recorded vulnerability flag. They should never be built on characteristics the agent infers from how someone writes, or on attributes that stand in for protected characteristics.

What should tighter limits mean for vulnerable customers?

More human involvement, not worse outcomes. If a customer is flagged as vulnerable, the right change is usually that the agent holds more of its actions for a trained person, not that it offers less. In the UK, the FCA's Consumer Duty expects good outcomes for retail customers, and a limit design that quietly gives vulnerable customers less would sit badly with that.

This is one of the few places where human-in-the-loop varies by customer rather than by action; see whether every AI agent should have a human in the loop.

Who decides, where is it enforced, and what is recorded?

The product owner proposes the tiers, risk and compliance approve them, and the process owner maintains them. They are written into the business's own limits for that process.

Enforcement happens at the moment of action. When the agent proposes a refund, the limit applied is looked up from the customer's tier, using the tier recorded on the account, not one the agent works out. The verdict records the tier and the bound that decided, so anyone can see why this customer got this answer. The case for that is made in why every agent decision needs a named bound.

What does this look like in practice?

Take a broadband provider's billing team. The agent handles credits for service faults. Three tiers apply: established customers, where the agent may credit up to 50 at depth 3; accounts under three months old, where it may credit up to 20 and holds anything more; and customers with a recorded vulnerability flag, where every credit is drafted and held for a specialist who also checks whether other support is needed.

A long-standing customer with a recorded vulnerability flag asks for a 30 credit. The agent does not apply the established tier. The vulnerability tier wins because it is more protective, the credit is held, and the specialist approves it the same day. The verdict names the vulnerability tier as the deciding bound.

Which controls make tiered limits safe?

• Tiers in writing, with the facts that place a customer in each.
• Tier read from the record, never inferred by the agent.
• Most protective tier wins when a customer qualifies for more than one.
• Individual exceptions expire; see why every exception to an agent's bounds should expire.
• Outcomes reviewed by tier, to check no group is treated worse without a reason.
• Instant tightening. A business must be able to lower a tier's limit at once; see whether a business can tighten an agent's limits instantly.

Tiered limits are one of the bounds described in our guide to agent governance; the tier is one more input to the check at the moment of action.