Skip to main content
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 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. 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. 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. 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.