Multi-tenancy introduces a class of resource contention problem that single-tenant deployments simply do not have. When one tenant's agent runs a workload that consumes disproportionate compute, the other tenants experience degraded performance or failed runs, and they never see the failure reason. The impact is invisible to them and opaque to you until SLA tickets start arriving.
AI agents make this worse in a specific way. Unlike a traditional service call with a known compute envelope, an LLM-based agent call has highly variable resource consumption based on input complexity, tool use depth, and how many inference steps the agent takes before completing. A simple query might use 800 tokens and return in 400ms. A complex multi-step research task from the same tenant might consume 40,000 tokens, spawn eight tool calls, and hold a CPU core pegged for six seconds. Both are "agent calls," but their resource profiles differ by two orders of magnitude.
The Four Resource Dimensions
Traditional multi-tenant quota systems typically cover compute (CPU time) and memory. For AI agents, those two dimensions are necessary but not sufficient. Token consumption and network egress bytes are where modern agent workloads actually blow their budgets and where noisy-neighbor effects are most pronounced.
CPU time governs how long the agent's non-LLM code runs: tool execution, data transformation, parsing, and postprocessing. This is the most straightforward to measure and enforce. It is also the most familiar to platform teams coming from microservice backgrounds. CPU quotas per run prevent a single tool-heavy agent from monopolizing a shared execution pool.
Memory includes working memory for context assembly, in-memory caching of tool results, and the memory footprint of the agent framework itself. Agents that accumulate large context windows between tool calls can consume significantly more memory than expected if the context window policy is not bounded. A 128K context window filled with repeated tool outputs can consume several hundred MB per agent instance in active execution.
LLM token budget is the resource dimension that varies most dramatically between tenants and between runs. A token quota per run prevents runaway agentic loops, limits the cost exposure from a single misbehaving agent, and provides a meaningful hard cap that maps directly to cost accounting. Without a per-run token quota, one tenant running an agent on malformed input that triggers a repetitive inference loop can consume tens of thousands of tokens before timing out.
Network egress bytes covers outbound data volume through the agent's allowed tool calls. In retrieval-heavy agents, a single run can move tens of megabytes of data through a RAG pipeline. In document processing agents, large attachments multiply this further. Network quotas set an upper bound on the blast radius of individual runs and prevent agents from consuming excessive bandwidth on shared egress infrastructure.
Hard Limits vs Soft Budgets
The distinction between a hard limit and a soft budget matters operationally. A hard limit terminates the run immediately when the threshold is reached. A soft budget generates an alert and potentially throttles execution but allows the run to complete. Which is appropriate depends on the resource dimension and the consequence of mid-run termination.
For token consumption, hard limits almost always make sense. Token consumption above a configured threshold is almost always runaway behavior, not legitimate use. A correctly designed agent on well-formed input should not approach its token cap in normal operation. If a run hits the cap, terminating it is the right outcome: it prevents cost runaway and returns a deterministic error to the caller instead of allowing the agent to continue burning tokens indefinitely.
For CPU time, the right choice depends on whether the agent is running latency-sensitive workloads or background batch processing. Batch processing can tolerate soft-budget throttling. Interactive agents should fail fast rather than produce a degraded half-result after unexpected compute usage.
For network egress, a soft budget with hard cap is often the most useful pattern: alert at 70% of the network quota to allow the run to complete, block at 100% to prevent unbounded data movement.
Per-Run vs Per-Period Quotas
Per-run quotas cap resource consumption for a single agent execution. Per-period quotas accumulate consumption across all runs in a rolling window (typically 1 hour or 24 hours) and enforce a ceiling on total tenant consumption regardless of individual run size.
Per-run quotas are the right primary control for CPU, memory, and token consumption. They are the mechanism that isolates one tenant's misbehaving agent from affecting others, because the isolation happens within the run boundary, not aggregated across runs.
Per-period quotas are the right control for cost accounting and billing protection. A tenant running many low-cost runs can still accumulate significant total consumption without any single run hitting a per-run cap. Period quotas catch this pattern and can trigger rate limiting before the period budget is exhausted.
In practice, a production multi-tenant deployment needs both. Per-run quotas provide the noisy-neighbor isolation. Per-period quotas provide the cost protection. The two controls operate independently and catch different failure modes.
Quota Assignment: Tier-Based vs Per-Tenant Configuration
The simplest quota model assigns the same limits to all tenants based on their tier. Free tier gets 2,000 tokens per run and 5 CPU seconds. Paid tier gets 20,000 tokens per run and 30 CPU seconds. This is operationally easy to maintain and provides predictable resource isolation.
The limitation is that tenant workloads are heterogeneous. A legal document review agent legitimately needs a larger token budget than a simple data extraction agent. Applying uniform tier quotas means either setting them high enough to accommodate the demanding workload (which provides poor isolation) or setting them tight enough to give good isolation (which breaks the demanding workload).
Per-tenant quota configuration, where each tenant has explicitly set limits based on their declared workload profile, provides better isolation at the cost of higher operational overhead. Tenants submit their expected workload parameters during onboarding, and the platform team sets quotas accordingly. Adjustments go through a review process.
A hybrid approach works well: start with tier defaults, but allow tenants to request overrides for specific quota dimensions with a documented justification. The override request creates a paper trail and ensures someone has evaluated whether the exception is appropriate. Most tenants never need overrides. The few that do are the ones whose workloads actually require the exception.
Enforcement at the Scheduler Level
Where quota enforcement happens in the execution stack matters. Application-layer enforcement, implemented inside the agent framework code, suffers from the same trust boundary problem as application-layer URL filtering: the enforcement logic runs inside the process it is supposed to constrain. A misbehaving agent can potentially exhaust resources before the framework's own accounting catches up, particularly for memory consumption and token accumulation in buffered contexts.
Runtime-level enforcement, implemented by the process scheduler and network layer, operates outside the agent's execution context. CPU quotas implemented as cgroups limits cannot be overrun by agent code regardless of what the agent does. Memory limits implemented at the namespace level kill the process when exceeded rather than relying on the agent to check its own consumption. Token budget enforcement implemented at the LLM API proxy layer intercepts requests before they reach the model endpoint, making it impossible for the agent to exceed the configured token budget by design.
The overhead of runtime-level enforcement is real: there is latency at the proxy layer and overhead from cgroups accounting. For interactive agents, that overhead needs to be characterized and budgeted. For batch agents, it is generally acceptable. The correctness benefit of enforcement outside the trust boundary outweighs the overhead cost for any deployment where the agent is processing untrusted input.
What to Log When a Quota Is Hit
When a run terminates due to a quota violation, the audit log entry needs to contain enough information for a postmortem. Minimally: the specific quota dimension that was exceeded, the configured limit, the actual consumption at termination time, the run ID, the tenant ID, and a timestamp. Without the consumed value at termination, it is impossible to distinguish "the quota is set too tight for this workload" from "the agent ran away and would have consumed much more if not stopped."
Repeated quota violations on the same tenant and the same quota dimension, with consumption values consistently close to the limit, suggest the limit is misconfigured for that tenant's actual workload. Repeated violations with consumption values far above the limit suggest genuine runaway behavior that the quota is correctly catching.
This distinction changes the remediation. In the first case, the limit should be raised. In the second, the agent's logic should be reviewed. Both cases look the same if all you log is "quota exceeded."