Plan gating and feature flags give you a single, centrally managed layer that controls which capabilities each organization can access, whether by subscription tier or by an explicit override. Every route, every UI element, and every API response that depends on a premium or restricted capability passes through this layer before anything reaches the user. Per-org overrides sit on top of the global flag state, making them the right primitive for controlled rollouts and early-access programs without shipping feature branches or touching deployment pipelines. For a step-by-step walkthrough of canary rollouts using overrides, see per-org feature overrides and canary rollouts.
Why Plan Gating Belongs in the Platform Layer
The instinct when a feature should be restricted to paying customers is to scatter the check throughout the codebase — a conditional here, a redirect there, a hidden button somewhere else. That approach works until the plan changes or you need to give one specific customer early access. Every scattered check becomes a maintenance surface, and you end up with inconsistencies between what the API allows and what the UI shows.
Centralizing plan gating in a dedicated service and enforcing it at every capability boundary eliminates that inconsistency. The capability definition lives in one place: a named feature with a minimum plan requirement. The check runs at the boundary, before any business logic executes, so there is no path through the system that lets a lower-tier organization reach a gated endpoint. The UI reads the organization's effective feature set at load time and renders conditionally, so users on restricted plans never see controls they cannot use.
This also separates two concerns that are often conflated: whether a feature is available to the organization and whether it is switched on globally. A global toggle lets you disable a capability for every tenant without a deployment. Per-org overrides let you enable it for specific tenants before the global toggle goes on. These two dimensions compose, which is what makes the system useful for real rollout workflows. For how subscription tiers determine which features a tenant can access, see Subscriptions, Invoices, and Contracts for AI Platforms.
How the Feature Enum and Plan Assignments Work
Each capability is represented as a named feature with a minimum plan requirement. When an entitlement check evaluates a request, it resolves the organization's current plan, looks up the feature definition, and compares the two. If the plan meets or exceeds the minimum, the request continues. If not, the platform returns an access-denied response with enough context for the client to show an upgrade prompt rather than a generic error.
The same lookup powers the endpoint that returns an organization's effective feature set. The frontend calls this endpoint at startup and caches the result, then renders the UI conditionally. A feature absent from the effective set simply does not appear — the upgrade path, not a disabled state, is what the user sees. This avoids the problem of presenting controls that always fail when used.
Global Toggles: Turning Capabilities On and Off Without a Deploy
Every feature in the registry has a global enabled state that a platform administrator can toggle at any time. Toggling a feature off globally disables it for every organization, regardless of plan or existing overrides. This is the mechanism for maintenance windows, for temporarily disabling a capability that is causing downstream problems, or for rolling back a feature that is misbehaving in production before a proper fix is ready. For a broader view of the operator controls available at the platform level, see the platform admin console.
The flag state is persisted and propagated across the platform. Changes take effect within a bounded interval rather than instantly — worth knowing when you need to disable something under pressure — but the window is short enough that toggling is a reliable operational control.
The admin interface surfaces all flags with aggregate statistics: how many organizations have overrides, the current global state, and which plan tier each feature requires. This gives operators a single view of the capability landscape without needing to inspect database records.
Per-Org Overrides: The Canary Primitive
Per-org overrides let you enable a feature for a specific organization independently of the global toggle and the organization's plan. They are the right tool for beta programs, for enterprise customers who need a capability before it reaches their tier, and for internal testing against real production tenants without changing the global state.
An override is a two-value record: the organization and the feature key, with an explicit enabled or disabled state. A disabled override can suppress a feature for one organization even if the global toggle is on and the plan would otherwise grant it — useful when one tenant's data or configuration is incompatible with a new feature and you need to exclude them while the issue is resolved.
Creating an override does not require a deployment or a configuration file change. An administrator opens the feature flag management interface, selects the feature, and adds the organization. The override takes effect on the next request from that organization, within a short bounded window. Removing the override reverts the organization to the default behavior — plan gating plus the global toggle — without any further action.
This composability is what makes per-org overrides a canary primitive. You ship the feature flag alongside the code, leave the global toggle off, enable the override for one organization, and observe behavior in production. When you are satisfied, you expand the override to more organizations, then eventually flip the global toggle and clean up the overrides. The rollout is fully reversible at every stage.
The Governance Mode Flag
Separate from the standard feature registry, a governance-mode flag controls whether agent governance rules are enforced, observed but not enforced, or switched off entirely. The three states are off, observe, and enforce. This is particularly useful when rolling out content guardrails for AI agents — observe mode lets you see what would be blocked before committing to enforcement.
In observe mode, governance rules are evaluated and logged but requests are not blocked. This lets you understand the impact of a policy before committing to enforcement — you see which requests would have been denied and whether the policy is calibrated correctly, without affecting live workloads. For a comparison of observe-mode guardrails with evaluation and monitoring approaches, see Guardrails vs Evals vs Monitoring.
In enforce mode, denials are real: a request that fails a governance rule is blocked and the calling party receives an error. Switching from observe to enforce is recorded in the audit trail with who made the change and when. The per-org override mechanism applies here too: you can run one organization in enforce mode while the rest of the platform remains in observe, giving you a staged rollout with the same reversibility as a standard feature flag.
What the UI Sees and How Conditional Rendering Works
From the frontend's perspective, the organization's effective feature set is a flat list of feature keys that are currently active. The frontend fetches this list at session start and makes it available throughout the application. Any component that depends on a gated feature checks for its key in this list before rendering.
The result is that the UI and the API are consistent by construction. If the feature key is absent from the effective list, the UI does not render the control. If someone bypasses the UI and calls the API directly, the entitlement check at the API layer rejects the request with a 403. There is no window between "the UI hides the button" and "the API refuses the request" where a direct API call would succeed.
This also makes the upgrade path explicit. When a user encounters a feature their organization does not have access to, the access-denied response carries enough context for the UI to surface a targeted message: an upgrade prompt, a contact-sales link, or an "access temporarily suspended" notice depending on which condition applies.
Praesidia's Implementation
Praesidia treats plan gating and feature flags as a core part of the platform rather than an afterthought. Every gated capability is evaluated against the organization's effective entitlements at request time, so access always reflects the current plan, trial state, and any per-org overrides — consistently across the entire product, with no gap where a gated feature is reachable without an entitlement check.
For teams running multi-tenant AI workloads, the ability to gate, observe, and roll out capabilities independently per tenant without touching the deployment pipeline is the practical foundation for safe iteration at scale. See also the platform admin console for how platform operators manage governance modes and override state across all tenants. For how feature access maps to subscription tiers and invoicing, see subscriptions, invoices, and contracts for AI platforms.
Common questions
Can I disable a feature for one organization even if their plan includes it?
Yes. A per-org override with an explicit disabled state suppresses the feature for that organization regardless of plan or global toggle. The override takes effect immediately (subject to the cache TTL) and can be removed at any time to restore normal plan-based behavior.
How quickly does a global toggle take effect across all replicas?
Flag state is propagated across the platform within a short, bounded interval after the toggle fires. For time-sensitive situations — disabling a feature that is causing errors — the propagation window is short enough that toggling is a reliable control, though not instantaneous across every in-flight request.
What is the difference between observe and enforce governance mode?
In observe mode, governance rules are evaluated and logged but do not block requests. You see what would have been denied without affecting live workloads, which lets you validate a new policy before committing to it. In enforce mode, denials are real: requests that fail a governance rule are blocked. Switching between modes is logged with a full audit trail and can be done per organization or globally.