Protocol

Isolate concurrency for the slow dependency

A slow neighbor should not be allowed to rent the whole building.

When it fits

One dependency or work type can block threads, workers or agent slots needed by unrelated work.

When to avoid it

Hard partitions can waste idle capacity; dynamic borrowing needs safeguards that preserve the isolation during overload.

Why it matters

Give the risky dependency or workload its own bounded concurrency pool. When that pool is full, queue, reject or degrade that workload without consuming the capacity reserved for unrelated core work. Observe pool saturation so the isolation boundary can be tuned.

Steps

The slow or failure-prone dependency has a separate concurrency limit.
Core work retains reserved capacity.
Pool saturation is visible.
Overflow behavior is defined.
The isolated pool is reviewed for both starvation and excess reservation.

An example

Give an external web-research tool a separate agent-worker pool so slow web calls cannot occupy every coding and repository worker.

Check your result

Saturation of the dependency-specific workload does not consume all shared execution slots.

Keep this limit in mind

Hard partitions can waste idle capacity; dynamic borrowing needs safeguards that preserve the isolation during overload.

Connected ideas

Evidence and sources

Supports

AWS's 2026 dependency-isolation guidance uses separate concurrency pools or bulkheads to keep slow dependencies from consuming all shared execution capacity.

Partitioning capacity can strand unused resources and requires sizing and observability.

Using dependency isolation to contain concurrency overload · Dependency isolation and concurrency overload

All sources (1)

Using dependency isolation to contain concurrency overload