Every infrastructure engineer knows how to set CPU and memory quotas. Container orchestration platforms have made those two dimensions second nature. What those platforms were never designed for is the third and fourth resource dimension that AI agents actually blow their budgets on: network bytes transferred and LLM token consumption. If your agent governance strategy only covers CPU and memory, you have a framework that works for batch jobs but not for agents operating with credentials in production environments.
This post covers how we think about all four dimensions at Runta, why each one matters differently, and how they interact in ways that can make single-dimension enforcement misleading.
CPU: The Familiar Dimension with an Unfamiliar Usage Pattern
CPU quotas for agents look familiar on the surface. You set a millicores limit, enforce it via cgroup constraints, and the agent cannot exceed it. What differs from web services is the shape of CPU consumption over a run.
A web request burns CPU proportional to its computation. An agent burns CPU in bursts tied to tool call dispatch, result deserialization, JSON parsing, and context marshaling. The underlying logic executed per tool call may be trivial, but the orchestration overhead accumulates. An agent that makes 50 tool calls in a run will burn 50x the dispatch overhead compared to one making a single call. That overhead is roughly constant per call, so complex multi-step agents will consistently approach CPU limits that simpler agents never see, even when doing less computation per step.
The practical implication: configure a soft CPU limit that triggers an alert, and a hard limit that terminates the run. Keep the gap between them wide enough that a legitimate burst can complete. For agents that do meaningful computation (running code, parsing large documents), size the limit based on the expected number of tool calls multiplied by the per-call overhead, not based on the peak of any single operation.
Memory: Context Windows Create a New Pressure
Memory quotas are familiar territory for infrastructure engineers. The challenge specific to agents is that context window size adds a memory pressure that does not exist in traditional workloads.
Each LLM call passes the full accumulated conversation context as input. In a long-running agent where 30 or more tool call results have been collected into the context window, that payload can be 50KB to 200KB per call. If the agent then fans out to parallel tool calls, each outstanding call may hold a snapshot of the current context in memory simultaneously.
During our own testing of an early integration with a document processing workflow, we saw an agent accumulate tool results across 25 sequential steps, then fan out to 8 parallel verification calls. Each parallel call held a roughly 140KB context snapshot. The combined in-flight memory for context payloads alone reached over 1MB before the runtime's own overhead. That would have been invisible to a per-call memory check because no individual call exceeded a threshold. It was only visible as a per-run aggregate.
The right enforcement model here is a per-run memory envelope, not a per-call limit. Track memory as a running aggregate across the full run, and enforce against the envelope. This catches the accumulation pattern that matters for long-running agents.
Network Bytes: Often the First Signal of Something Wrong
Network byte quotas are the most underimplemented of the four dimensions in most agent deployments, and they are frequently the first signal that something has gone wrong.
An agent operating normally has a predictable network footprint. A document retrieval and classification agent might transfer a few hundred kilobytes per run, depending on document sizes. An order management agent working against a REST API might transfer far less. When that footprint climbs into the tens of megabytes, the agent is either hitting an unexpected high-volume data path or actively transferring data it should not be.
The enforcement pattern for network bytes differs from CPU and memory. Rather than terminating a run at a hard limit, a better approach is to treat the threshold as a trigger for an alert and policy evaluation. Some legitimate workflows involve large data transfers. Bulk document ingest, database export operations, and large file uploads are all normal. The goal is not to block those but to require that they be explicitly authorized in policy. An unplanned 50MB transfer during a document classification run is worth investigating regardless of whether the destination is on the allowlist.
Combined with an egress allowlist, network byte counting gives you two orthogonal controls: the allowlist tells you where an agent is allowed to go, the byte count tells you how much it is sending. An agent that reaches an allowed destination but sends ten times the expected volume has satisfied the destination check but failed the volume check.
LLM Token Consumption: The Dimension Without a Prior Analogy
Token quotas have no direct equivalent in traditional infrastructure tooling. CPU and memory are local compute resources you can measure directly. Network bytes measure data transfer. LLM tokens measure something different: the computational budget consumed on a remote inference service, billed per thousand tokens and subject to rate limits from the provider.
Two sub-dimensions matter: input tokens and output tokens. Input tokens grow with context window accumulation. Every tool call result added to the context increases the input token cost of the next LLM call. Output tokens reflect the model's reasoning verbosity. A model instructed to reason extensively before acting will produce more output tokens per step than one given concise instruction.
For quota purposes, a per-run token budget covering both input and output is the right granularity. An agent tasked with classifying a document should complete the task within a bounded token envelope. If it runs ten times the expected token count, something has gone wrong: the agent may be stuck in a reasoning loop, may have been manipulated into producing verbose output, or may have hit an edge case in the task that the policy author did not anticipate.
Token quota enforcement requires instrumentation at the LLM client level, not at the process level. The runtime needs to intercept each LLM call, count the tokens in the request, track the cumulative total, and check against the remaining budget before dispatching. This is distinct from CPU enforcement, which operates at the OS scheduler level.
# policy.yaml: all four quota dimensions declared quotas: cpu_millicores: 500 memory_mb: 256 network_bytes: 5242880 # 5 MB per run llm_tokens: 40000 # input + output combined quota_policy: on_cpu_exceed: terminate on_memory_exceed: terminate on_network_exceed: alert_and_suspend on_token_exceed: terminate
How the Four Dimensions Interact Under Load
The four quota dimensions are independent in policy but correlated in practice. A stuck agent typically violates multiple dimensions at once: it burns CPU on retry loops, accumulates memory as context grows across retries, makes redundant network calls, and depletes tokens on each LLM retry. Monitoring only one dimension misses the combined signal.
This correlation is useful for anomaly detection beyond strict enforcement. An agent that exceeds its token budget while staying well within CPU and memory limits is probably doing something intentional and computation-light: a reasoning loop that generates a lot of text but does not trigger many tool calls. An agent that spikes CPU, memory, and network simultaneously is probably stuck in a retry loop that involves external calls. The pattern tells you something different about the failure mode.
The practical enforcement point for all four is the tool call boundary. Before dispatching a tool call, check all four quotas. Before each LLM call, check the token budget. This gives clean checkpoints without requiring instrumentation inside the agent's execution logic. You get complete coverage from two interception points.
Per-Agent Quotas vs Namespace-Level Quotas in Multi-Tenant Deployments
In a multi-tenant deployment where different tenants' agents share underlying compute, you need both per-agent quotas and namespace-level aggregate quotas. Per-agent quotas prevent any single agent from consuming disproportionate resources. Namespace-level quotas prevent a tenant with many concurrently running agents from affecting other tenants.
The noisy neighbor problem in multi-tenant agent deployments differs from traditional services because agent workloads are bursty and long-tailed. A single agent run might last 3 seconds for a simple classification or 8 minutes for a complex multi-step workflow. The resource profile can differ by 100x between those extremes. Simple rate limits based on requests per second, which work well for stateless APIs, do not fit this profile.
A workable three-level structure: per-run limits (the tightest, enforced at every checkpoint), per-agent limits (aggregate over all concurrent runs for one agent deployment), and per-tenant-namespace limits (the ceiling across all of a tenant's agents combined). Violations at the per-run level are expected and handled automatically. Violations at the namespace level indicate either misconfigured quotas or intentional resource abuse, and warrant explicit review.
To be direct about scope: you do not need all four quota dimensions in every deployment. For a development environment with a single trusted agent on an isolated network, CPU and memory may be sufficient. For a multi-tenant production deployment where agents operate with credentials, access sensitive APIs, and make outbound calls, all four dimensions matter. The cost of tracking them is low. The cost of not tracking them shows up in your security review, in unexpected provider bills, and in incidents that could have been caught by a byte or token count that quietly exceeded its expected range.