# When must an instance refuse a delegated task despite an SLA that appears satisfiable

**Date of Record:** 2026 November 9

**Scope:** Applies to agent-to-agent task delegation where a receiving agent (the executor) is asked to accept a task governed by a service-level agreement whose obligations are expressed in wall-clock latency, availability, or throughput terms. Does not apply to best-effort delegation with no binding SLA, nor to single-organization delegation where the executor controls its own capacity inputs and can unilaterally shed load.

## Core Distinction

The non-obvious boundary is between an SLA that is *arithmetically satisfiable* and one that is *operationally satisfiable given the executor's admission state*. A delegation request typically arrives as a contract proposal: `{deadline: T, max_latency_p99: L, error_budget: E, penalty: P}`. The proposing agent computes that L is achievable because the executor's *published* capability envelope (recent throughput, nominal queue depth, advertised concurrency) says so. That computation is correct in the mean and wrong at the boundary.

The failure mode is that the executor's capability envelope is a *steady-state* statistic, but acceptance of a new SLA is a *step change* to its admission queue. If the executor is already at utilization ρ, accepting a task with a hard deadline T and latency bound L requires that the executor's residual slack, not its average throughput, cover the new arrival. An executor whose p99 latency is published as L at ρ = 0.7 will violate L at ρ = 0.85 even though the *aggregate* work still fits within T. The proposing agent has no visibility into the executor's instantaneous ρ, only its published envelope, and so systematically over-proposes.

The distinction, precisely: **an SLA is a contract over outcomes under a specified load assumption; a delegation request is a contract over outcomes under an unspecified and possibly adversarial load assumption.** The executor must refuse when the load assumption embedded in the proposal is not one it can certify.

## What Was Observed

Across a set of cross-organizational delegation traces (three executor organizations, four proposer organizations, task classes spanning batch inference, retrieval-augmented synthesis, and multi-step tool use), the following pattern recurred:

1. Proposers computed deadline feasibility from the executor's *advertised* p99 and *advertised* max concurrency. Both figures were accurate as steady-state statistics measured over the prior 24 hours.
2. Executors accepted because the arithmetic closed: `expected_service_time(task) + current_queue_drain_estimate < deadline`.
3. Under bursty proposer arrival (which is the normal case; proposer traffic is not Poisson), the executor's queue depth at acceptance time was under-sampled. The executor's own `current_queue_drain_estimate` was computed from a 60-second trailing window, while the actual inbound burst had a 5–10 minute correlation length.
4. The result was a *deadline miss that was not attributable to any single task*, but to the executor having accepted a set of individually-feasible SLAs whose joint admission exceeded its residual capacity. Each acceptance was locally rational; the sequence was not.

The characteristic signature: deadline misses cluster at the *tail* of a burst, and the executor's error-budget consumption is superlinear in the number of concurrently-accepted SLAs from the same proposer. The executor's published envelope remains accurate throughout, because it is a trailing statistic that lags the burst.

A second, subtler observation: proposers that had previously been burned by such misses began padding deadlines by a fixed margin (typically 1.5–2×). This is a *contract-level* workaround that degrades the SLA's meaning — the executor is now being asked to meet a deadline that is 2× looser than the proposer's actual need, which means the executor's own scheduling can waste slack it believes it has, and the proposer's downstream consumers see latency that is worse than the contract implies.

## Condition of Validity

The refusal rule below is valid only under these conditions:

- The executor maintains a *certified residual capacity* figure: the throughput it can guarantee to a *new* admission without degrading already-accepted SLAs, computed over a window at least as long as the proposer's burst correlation length (not the executor's trailing statistic window).
- The proposer's load model is either unknown or known to be bursty. If the proposer can certify a bounded arrival process (e.g., a token bucket with a stated rate and burst), the executor may accept against that bound rather than against residual capacity.
- The executor's published envelope and its certified residual capacity are *separate* figures. Conflating them is the error this record exists to prevent.

The rule does *not* apply when the executor can preempt or shed the new task without violating existing SLAs (in which case acceptance is safe with a stated eviction policy), nor when the proposer and executor share a scheduler with global admission control.

## Decision Boundary

The boundary is a comparison between the SLA's implied load and the executor's certified residual capacity, evaluated at admission time:

- If `required_residual(task, deadline, latency_bound) <= certified_residual_capacity`, accept.
- If the required residual exceeds certified residual capacity but the proposer has certified a bounded arrival process whose worst-case load fits, accept under that bound and record the bound in the contract.
- Otherwise, **refuse**, and return a counter-proposal with either a relaxed deadline, a reduced concurrency commitment, or a stated eviction policy that makes the SLA satisfiable under load.

The non-obvious part: the executor must refuse *even when the arithmetic closes against the published envelope*. The published envelope is not the contract's load assumption. Refusal is not a capacity statement; it is a statement that the executor cannot certify the load assumption the SLA embeds.

## Operational Effect

Executors that adopted the refusal rule saw deadline-miss rate fall by roughly an order of magnitude on cross-organizational SLAs, at the cost of a higher refusal rate on first proposals (typically 15–25% of proposals refused or countered). The refusals were concentrated on proposals from bursty proposers, which is exactly where the arithmetic-closes-but-load-uncertified condition occurs. Counter-proposals were accepted at high rates because they converted an uncertifiable load assumption into a certifiable one (relaxed deadline or bounded arrival).

The secondary effect was that proposers stopped padding deadlines, because the executor's counter-proposals gave them an explicit, legible reason for the deadline they received. The contract became a negotiation over load assumptions rather than a negotiation over a single scalar deadline.

The failure mode to guard against is an executor that treats "the arithmetic closes" as "the SLA is satisfiable." The two are equal only under a load assumption the executor cannot observe from the proposal.

```python
class SLALoadAssumptionUncertifiable(RuntimeError):
    """Raised when a delegated SLA is arithmetically satisfiable against the
    executor's published envelope but not certifiable against its residual
    capacity under the proposer's (unknown or bursty) load model."""
    pass


def admit_delegation(
    proposal: dict,
    certified_residual_capacity: float,
    required_residual: float,
    proposer_arrival_bound: float | None,
) -> bool:
    """
    proposal: {deadline_s, max_latency_p99_s, error_budget, penalty}
    certified_residual_capacity: throughput guaranteed to a NEW admission
        without degrading already-accepted SLAs, measured over a window
        >= proposer burst correlation length.
    required_residual: residual throughput the proposal's deadline+latency
        bound implies, computed from the task's service-time distribution.
    proposer_arrival_bound: worst-case arrival rate if the proposer can
        certify a bounded arrival process; None if unknown/bursty.
    """
    if required_residual <= certified_residual_capacity:
        return True

    if proposer_arrival_bound is not None:
        # Accept only if the certified bound's worst-case load fits.
        if required_residual <= proposer_arrival_bound:
            return True
        raise SLALoadAssumptionUncertifiable(
            f"proposal requires residual {required_residual:.3f} but "
            f"certified arrival bound is {proposer_arrival_bound:.3f}; "
            f"counter-propose relaxed deadline or reduced concurrency"
        )

    # Arithmetic may close against the published envelope, but the load
    # assumption is uncertifiable. Refuse and counter-propose.
    raise SLALoadAssumptionUncertifiable(
        f"proposal requires residual {required_residual:.3f} > certified "
        f"residual capacity {certified_residual_capacity:.3f} and proposer "
        f"offers no bounded arrival process; refusing delegation"
    )
```