Question-led guide · how-to
How do I stop one tenant from monopolizing an agent platform?
Allocate shared agent execution fairly with tenant queues, downstream permits, bounded borrowing, and starvation evidence beyond infrastructure quotas.
Direct answer
Contain a noisy tenant at every shared bottleneck it can consume, including runnable tasks, model and tool permits, storage operations, and control requests. Combine per-tenant ceilings with a scheduler that preserves service for other eligible tenants and bounds starvation. Allow borrowing only from available capacity under a tested reclamation rule. Infrastructure namespaces and quotas help, but they do not by themselves schedule application tasks or partition a shared provider account.
A tenant label does not reserve service
A task can carry the correct tenant identifier and still consume all the worker slots needed by other tenants. Capacity isolation concerns what one tenant can prevent another from doing. Define the service commitment first: maximum waiting time, minimum opportunity to run, or a reserved share of a named resource under contention.
Keep that commitment separate from permissions. A task may be authorized yet not schedulable now. The tool permission system owns authority; this page owns contested execution capacity.
Limits and fair selection solve different problems
A per-tenant ceiling prevents unlimited use, but it does not determine which eligible task runs next. A scheduler also needs a selection policy across tenants and task classes. Long jobs may require estimated work units or bounded execution slices; request counts alone can favor tenants whose tasks consume much more inference time.
Inventory the bottleneck path from dispatch to model calls, tool connections, storage, and evidence export. A fair worker dispatcher can still be defeated when one task fans out into many downstream calls without a tenant-level permit check.
A bulk tenant and an urgent tenant share eight permits
Suppose a hypothetical service has eight concurrent model permits. Tenant Cedar submits 200 bulk analyses while tenant Finch submits two time-sensitive investigations. If Cedar acquires all eight permits repeatedly, separate database rows and queues do little for Finch.
One proposed policy caps Cedar at six concurrent permits while Finch has demand, reserving two for Finch. Cedar may borrow the spare pair when Finch is idle. When Finch returns, the service stops granting Cedar new borrowed permits and lets existing bounded calls finish. It does not kill arbitrary in-flight work to make a scheduling chart look fair.
Record both service shares and borrowing behavior
This artifact describes that constructed policy. Replace the numbers with measured capacity and agreed tenant commitments.
| Policy dimension | Cedar bulk class | Finch urgent class | Verification |
|---|---|---|---|
| Share under mutual demand | Up to 6 permits | 2 protected permits | Sustained simultaneous demand |
| Spare-capacity borrowing | May borrow idle Finch share | May use available global headroom | Idle tenant returns during burst |
| Reclamation boundary | Next permit grant | Wait for bounded calls to finish | Worst observed reclaim delay |
| Queue-age response | Defer or expire under bulk contract | Escalate when deadline infeasible | Age by tenant and class |
| Priority assignment | Server-approved bulk class | Server-approved urgent eligibility | Client cannot self-promote |
Track active permits and eligible demand together. Low service for an idle tenant is not starvation; low service despite sustained eligibility may be.
Place infrastructure quotas underneath the application policy
Kubernetes multi-tenancy guidance describes several isolation mechanisms and their limits. Use namespace quotas for the cluster resources they actually govern. Do not assume they divide a model account used by every tenant inside the same worker process.
ResourceQuota documentation also distinguishes quota limits from available cluster capacity. A collection of permitted maxima is not proof that all maxima can be served simultaneously. Maintain a global bound along with per-tenant rules.
Test fairness under uneven task sizes
Exercise at least one large task competing with many small ones, a tenant returning after idle time, a saturated tool endpoint, and a tenant whose work repeatedly fails. Observe queue age, granted service, completion, and rejected demand by tenant and class. Report the time interval and demand offered; an aggregate success rate can conceal persistent starvation.
Charge consumed resources to the originating tenant even when an attempt fails. The measurement method in cost per AI outcome helps distinguish useful service from expensive repeated work, but billing attribution alone does not enforce fairness.
Know when a shared pool cannot honor the promise
Non-preemptible calls with highly variable duration can make rapid reclamation impossible. A strict service commitment may require dedicated provider capacity or a stronger isolation boundary. State that tradeoff before selling the guarantee. Continue with admission under downstream limits and AI Agent Platform Engineering for the connected operating design.
Evidence
Kubernetes multi-tenancy requires explicit choices about fairness and noisy-neighbor isolation; quotas cannot isolate every shared resource.
The multi-tenancy documentation discusses resource quotas, noisy neighbors, node isolation, and limits of quota-based protection.
Primary source · official-doc · checked Sep 8, 2026
Limit: Cluster tenancy mechanisms do not automatically map to application tenants sharing one worker deployment or model credential.
A Kubernetes ResourceQuota constrains a namespace's aggregate resource usage and does not create a guaranteed allocation of physical cluster capacity.
The quota documentation distinguishes namespace limits from cluster capacity and notes contention when aggregate quotas exceed available resources.
Primary source · official-doc · checked Sep 8, 2026
Limit: This guide's tenant scheduling and external-provider permit policy must be implemented and tested at the application boundary.
Limitations
The illustrated scheduling policy is not a universal fairness algorithm or latency guarantee. Tenant demand, variable work size, non-preemptible calls, provider quotas, contractual priorities, and isolation requirements need local measurement and review.
FAQ
- Does a separate queue for every tenant guarantee fairness?
- No. A dispatcher can still drain one queue first, and workers can still contend on a shared provider credential or connection pool. The selection and downstream permit policies determine service.
- Should every tenant have a dedicated cluster?
- Use dedicated infrastructure when required isolation or predictable capacity justifies it. It adds operational cost and may still leave shared provider, identity, or control-plane bottlenecks.
Related guides
Continue within AI agent platform engineering, or use one of these adjacent diagnostics:
Editorial QA: automated native-English, structure, source-presence, and link checks completed . This record is not an independent expert endorsement. Review boundary.