Quick answerHow does this interact with age-detection signals if the account structure is set up wrong, e.g. a teen using the parent's own profile? Age-detection signals should trigger a flag for review, not an automatic tier downgrade, since silently changing a profile's authority based on inferred signals rather than the account's own structure risks locking out the actual account owner. Does the permission-tier structure need to be visible to the customer, or can it stay internal? Make it visible. A teen who understands their own spending cap and approval flow in advance generates far fewer frustrated escalations than one who discovers the limit only when a purchase is unexpectedly blocked.
Quick answer
Build permission tiers as a persistent, structural property of the sub-profile itself, not a runtime judgment the agent makes about who it thinks it's talking to. Each sub-profile carries a fixed authority level, full purchasing and account-management authority for a parent profile, a capped or purchase-approval-required authority for a teen sub-profile, and the agent enforces the tier the same way it would enforce any other access-control rule: by checking which profile authenticated the session, not by inferring trust from conversational tone or context.
Why this is a different design problem than real-time speaker ambiguity
A related but distinct problem is figuring out, in the moment, who is currently speaking when several people share one conversation thread, a parent and a teen texting from the same device mid-conversation, for example. That is a live identity-tracking problem solved by watching for signals within a single session. Differentiated permission tiers are the opposite: a persistent, pre-set structural property established at profile creation, unrelated to who happens to be typing right now. A well-designed system needs both, but they are solved with different mechanisms, and conflating them leads to agents that try to infer purchasing authority from writing style instead of checking the authenticated profile's fixed tier.
Why this is also different from general minors-safety design
General behavioral safety design for minors, softer commercial language, faster human escalation, no persuasive dark patterns, is about how the agent behaves toward a likely-minor user regardless of account structure. Permission tiering is a narrower, mechanical question: what can this specific authenticated sub-profile actually do, independent of tone or behavior. A teen sub-profile needs both: the general safety behavior the age-detection and minors-safety work already covers, plus a hard, structural cap on purchasing and account-management authority that behavioral safety design alone does not provide.
What belongs in the tier definition
Define each tier along at least three axes: spending authority (a hard dollar cap per transaction and per period, or a parent-approval-required flow above a threshold), account-management authority (whether the sub-profile can change shipping addresses, payment methods, or other sub-profiles' settings, which a teen tier should never have), and data-visibility authority (whether the sub-profile can see the full account's order history or only its own activity). Keep the tier definition in the account's structural data, not in a prompt instruction the agent has to remember and re-derive every session.
Handling authority conflicts and escalation
When a teen sub-profile requests something above its tier, the agent's job is to explain the limit and offer the path to parent approval, not to silently deny or silently comply. Log every above-tier request the same way you would log any other access-control denial, since a pattern of repeated denied requests is itself a useful signal for a parent to see, and route genuinely ambiguous cases, a request that doesn't clearly map to an existing tier rule, to a human rather than making a judgment call that effectively creates a new, undocumented tier on the fly.