Multi-Agent Capability Routing: Capacity Admission, Backpressure, and Load Shedding

“Send coding tasks to the coding Agent and research tasks to the research Agent” only works in demos. Production tasks may also require access to a specific repository, a particular browser version, a certain model context, region, data classification, tool schema, and security policy. Even a functionally compatible worker may already have exhausted its model concurrency or downstream connections. Routing only by role name leaves tasks waiting in the wrong queue until they time out, after which retries create even more pressure.

Agent Concurrency and Scheduling covers pools, rate limits, and priorities, while Tenant Quota Isolation for AI Platforms constrains shared inference resources. This article focuses on how a coordinator simultaneously determines whether a pool can perform a task, whether it should accept the task now, and what to shed first under pressure, while ensuring that switching pools neither expands permissions nor changes the result contract.

capability-descriptor.v1 Defines Verifiable Facts

A trusted control plane publishes a descriptor for each execution pool containing poolId, descriptorEpoch, runtimeDigest, supported task/result schema ranges, tool versions, data classifications and tenant-isolation profiles, regions, model limits, sandbox details, policy generation, health evidence, and expiration time. Worker heartbeats may report only dynamic utilization; they cannot claim elevated privileges.

A task submits TaskRequirements.v1, including capabilities, input classifications, result schema, estimated token/tool-slot/duration requirements, deadline, trusted tenant, priority source, and allowed degradation options. Matching uses versions, labels, and isolation policies rather than embeddings. Unknown fields, expired descriptors, incompatible tenants, or stale epochs or generations all cause admission to be denied.

eligible = schemaCompatible
  && requiredTools subsetOf allowedTools
  && classificationPolicy.allows(inputLabels, poolLabels)
  && tenantIsolationCompatible
  && region in allowedRegions
  && descriptorEpoch == activeDescriptorEpoch
  && policyGeneration == activeGeneration

admit = eligible && activate(admissionId, requirementDigest, grants)

The descriptor states which capabilities a pool possesses; a short-lived capability lease authorizes which resource a specific attempt may actually call. Routing to a “privileged pool” must not expose the entire pool's credentials to the task. Even after the task is claimed, the system must issue a narrower invocation lease. Budgets in Agent Delegation Contracts must also shrink as they move downstream.

One Admission Must Reserve the Entire Critical Resource Chain

ReservationLedger stores PREPARING/ACTIVE/RELEASED/EXPIRED, the descriptor epoch, resource grants, TTL, and fence under the stable key admissionId + requirementDigest. Reusing the same ID with a different digest causes an immediate conflict. Model slots, tool permits, sandboxes, and tenant budgets controlled by the platform are reserved through conditional counters in one transaction; only one of two competing schedulers can win the CAS.

When external resources cannot participate in the ledger transaction, the coordinator remains in PREPARING and idempotently requests short-TTL provisional grants, keyed by the admission ID, in a globally fixed order. These grants cannot yet be consumed. If any request fails, the coordinator compensates by releasing the acquired grants. Partial grants may briefly occupy capacity, but they cannot start a task or wait indefinitely. Once every grant is available, the coordinator performs a CAS to ACTIVE and issues an AdmissionGrant containing the admission, pool, descriptor epoch, fence, and grant IDs. Task claims, pool dispatch, and every resource-consumption point must revalidate these fields and the TTL. Expiration cleanup uses a higher fence, preventing a stale holder from consuming or releasing a newer grant. Relationships that genuinely require hold-and-wait during execution belong in the Multi-Agent Wait Graph.

Capacity estimates come from actual service-time and token distributions. Execution settles resources by phase and atomically moves grants that are no longer required to RELEASED. A phase transition requires fresh admission and cannot inherit implicit permissions. Queues are fairly tiered by tenant and service class; tasks predicted to miss their deadline are rejected or degraded. The Kubernetes Scheduling Framework's filter/score/reserve/permit stages provide a useful model, but the business layer must implement the ledger's linearization point.

Backpressure Must Reach Producers

When a pool enters a pressure state, first stop low-priority fan-out and speculative branches, then pause deferrable batch work, tighten per-run concurrency, and finally reject new interactive requests. Do not continue accepting requests only to queue them silently inside the system. Responses include a reason code, a safe retry time, the accepted admission ID, and permitted degradation options. SDKs use jittered backoff and honor the deadline.

Shed load according to cost and recoverability: speculative tasks that have not started, rebuildable caches, and best-effort batch work go first. Tasks with external side effects of unknown outcome, human approval, or proximity to a canonical commit must not be evicted casually. Envoy Overload Manager demonstrates how resource pressure can trigger actions, while Google SRE's overload-handling guidance emphasizes rejecting work early to preserve healthy capacity. For Agents, overload fallback must also be prevented from becoming a security downgrade, such as switching from a controlled private pool to a public model.

A backup pool must appear in the task descriptor's explicit allowedFallbacks, and its output schema, region, data classification, and tool semantics must be compatible. Degradation may reduce retrieval fan-out, reduce noncritical review passes, or return partial results, but it must mark missing evidence. It must never silently switch to an Agent with broader permissions or quality that has not passed its gates. Multi-Model Fallback handles provider failover; routing here still defines the admission boundary for the entire multi-Agent execution pool.

Stress Testing, Metrics, and Safe Rollback

Tests cover spoofed capabilities, expired descriptors, the same admission ID with different payloads, failure after acquiring only some external grants, two competing schedulers, cancellation before ACTIVE, TTL cleanup racing with release by a stale holder, single-tenant bursts, and cross-region fallback. Stair-step and pulse load tests assert that ledger counts remain conserved, bounded queues never exceed capacity, low-priority fan-out stops first, retries include jitter, and fallback never expands permissions.

Observability includes the number of eligible pools per capability, match-failure reasons, reservation utilization, estimated-to-actual cost ratios, queue age, deadline misses, per-tenant fairness skew, the trigger time of each shedding stage, fallback rate, and resource-release latency after cancellation. Overall success rate alone can conceal critical traffic being crowded out by batch work, so metrics must be sliced by service class and capability.

Begin with shadow routing, then enable the ledger for low-risk read-only tasks. To roll back, first stop new admissions and advance activeDescriptorEpoch; release reservations that have not reached ACTIVE. An already claimed attempt may continue consuming its original grants under its pinned epoch only while it remains on an explicit draining allowlist. Every new phase must be readmitted under the current epoch. For a security revocation, remove the allowlist entry and cancel the attempt. Old binaries that do not recognize epochs must not be returned to service. Resume routing only after confirming zero duplicate reservations, cross-region fallbacks, and leaked permits. Scoring can be rolled back, but hard capacity limits and security matching cannot be disabled.