Subscriptions and Entitlements: Gating Features Without Hardcoding Plans
How SmartAgents decides what a tenant can and can't access -- a subscription and entitlement layer instead of if-statements scattered through the codebase.
The naive way to gate a feature by subscription plan is an `if ($tenant->plan === 'pro')` check wherever the feature is used. It works for one feature. It becomes unmanageable by the tenth, because now plan logic is scattered across dozens of files instead of living in one place.
SmartAgents uses a `Subscription` model tied to each tenant, checked through a dedicated `RequiresEntitlement` layer rather than inline plan comparisons. A feature declares what entitlement it requires; the entitlement system resolves whether the current tenant's subscription grants it. The feature code doesn't know or care what plan name grants that entitlement -- it just asks "is this allowed," which means plan definitions can change without touching feature code.
This matters most at the moments plans usually break things: when a tenant upgrades, downgrades, or a trial expires. Because the check lives in one layer, those transitions are consistent everywhere a gated feature appears, instead of needing a fix in every place someone remembered to hardcode a plan check.
It's an unglamorous piece of infrastructure -- nobody sees it directly -- but it's the difference between "adding a new plan tier" being a config change versus a multi-file refactor.