> ## Documentation Index
> Fetch the complete documentation index at: https://help.nops.io/llms.txt
> Use this file to discover all available pages before exploring further.
# AI seat automation
> How nOps earns the right to change Claude Enterprise seat limits on its own—the autonomy states, the graduation scorecard, how often the controller runs, and the safeguards that hold it back.
**AI seat automation** rebalances per-user Claude Enterprise spend limits against a shared budget pool, so seats that are running out of headroom get more and idle seats give some back.
Because this feature writes to your provider, the default posture is that it *cannot*. It has to earn write access against a published scorecard, and it loses that access the moment a write cannot be verified. This page documents exactly how that works, so you can decide whether to trust it before you turn it on.
AI seat automation builds on [AI seat tracking](/operate/budgets#ai-seat-tracking) and requires the **Operate** plan. Unattended limit changes are supported for **Claude Enterprise** only. Cursor seat limits are read-only in nOps today.
## Autonomy states
Autonomy is a **capability ceiling**—it defines the most the controller is allowed to do, regardless of any other setting.
| State | What the controller may do |
| ---------------- | ------------------------------------------------------------------------------------------------------------- |
| **Observe** | Compute recommendations and record them. It never writes to your provider. This is where every policy starts. |
| **Auto-protect** | Apply seat-limit changes to Claude Enterprise without waiting for a human. |
A policy moves from Observe to Auto-protect only by passing the graduation scorecard below. You can always stay in Observe indefinitely—there is no requirement to graduate, and nothing expires if you don't.
Underneath the ceiling, an **approval mode** controls the workflow: whether nOps opens seat requests for a human to review, or only records proposals for visibility.
## The graduation scorecard
The scorecard is visible in the product under **AI seat tracking → Rebalance**, so you can watch a policy accumulate evidence in real time. Every criterion must pass.
| Criterion | Requirement | Why it exists |
| ------------------------------- | ---------------------------------------------- | ------------------------------------------------------------------------------------------ |
| **Observation window** | 7 days by default | Enough calendar time to cover a full weekly spend cycle. |
| **Qualifying hours observed** | 50 distinct hours by default | Confirms the controller has seen this budget repeatedly over real elapsed time. |
| **Settled forecast samples** | At least 1 | Graduation cannot rest on forecasts that were never checked against reality. |
| **Forecast error** | Mean absolute percentage error at or below 25% | The controller must be able to predict this budget before acting on it. |
| **Simulated budget violations** | Exactly 0 | If any recommendation *would have* pushed allocations past the pool, that disqualifies it. |
| **Recommendation samples** | At least 5 recommendation transitions | Churn cannot be judged from an empty sample. |
| **Recommendation churn** | Below 10% | A controller that keeps reversing itself is unstable, whatever its average accuracy. |
The observation window and qualifying-hours floors are configurable per policy, but they cannot be lowered below **1 day** and **24 hours**—the floors exist so that no configuration can produce a same-day graduation.
### What counts as evidence
Only outcomes that reflect an actual decision count toward graduation. These outcomes are excluded:
* `run_failed`, `reconciliation_failed` — the run errored
* `budget_conflict`, `no_pool`, `no_managed_seats` — nothing to decide on
* `backoff`, `lease_blocked` — the run was suppressed before it decided anything
This matters: a policy cannot graduate because its runs kept failing or getting skipped. Failures and skips do not accumulate trust.
Evidence is also counted in **distinct hours**, not row count. Because the controller can run as often as every five minutes, counting rows would let a policy clear a 50-sample floor in a few hours of steady state. Bucketing by hour caps accrual at 24 per day at any speed, so the floor always implies real elapsed time.
## How often the controller runs
There is no single fixed interval, and the product does not claim one. The baseline is an hourly scheduled check; when a budget needs closer attention, the next check is pulled in.
| Cadence | Interval | When it applies |
| --------- | ---------- | ---------------------------------- |
| Scheduled | 60 minutes | Baseline for every tracked budget. |
| Watch | 15 minutes | A seat has entered the watch band. |
| Critical | 5 minutes | A seat is at risk or critical. |
Two limits keep this from becoming a hot loop:
* **Escalation requires an actionable outcome.** If a run changed nothing—because a seat request was already open, or a detection backoff suppressed it—the controller does not speed up. Risk alone is not enough; the faster cadence has to be able to change something.
* **Consecutive fast checks are capped.** After 6 back-to-back accelerated checks, the controller falls back to the scheduled cadence, bounding any runaway loop to roughly half an hour at the fastest rate.
## Safeguards
**Every write is verified.** After changing a seat limit, nOps re-reads that user's effective limit from Claude and confirms it matches the intended value within a cent. A write that cannot be verified—wrong value, unreadable, or the provider identity no longer matches—is recorded as a failure, not a success.
**Failed verification revokes autonomy.** A policy in Auto-protect that fails reconciliation is demoted to Observe. It stops writing immediately and has to earn write access back through the scorecard.
**One unattended writer per provider.** Only one policy per client can hold Auto-protect for a given provider. If a second policy would otherwise graduate, graduation is refused and the conflict is logged. Two controllers writing limits for the same roster would fight each other, and neither would be accountable for the result.
**Rate limits are respected.** Provider calls back off and retry on rate limiting rather than hammering your Anthropic organization's shared request budget.
## What it will never do
* Write to your provider while in Observe.
* Graduate itself without every scorecard criterion passing.
* Raise a seat's allocation past the budget pool.
* Change Cursor seat limits.
* Keep writing after a write failed to verify.
## FAQ
You can lower the observation window and qualifying-hours requirements on a policy, but not below 1 day and 24 hours. There is no setting that grants write access immediately.
Check which criterion is unmet on the scorecard. The two most common causes are **Qualifying hours observed** (runs that were skipped, backed off, or failed do not count, and multiple runs in the same hour count once) and **Recommendation samples** (a policy that has never changed its recommendation has no churn sample to judge).
It stays in Auto-protect. The scorecard governs graduation, not continued operation—but the reconciliation safeguard still applies, so a failed write demotes it to Observe and re-graduation is judged against the current rules.
Set the policy back to Observe. It stops writing on the next run.
## Related
* [Budgets](/operate/budgets) — set up the budget and enable AI seat tracking
* [Claude.ai (Enterprise)](/integrations/claude-enterprise) — required scopes, including `write:spend_limits`