What it does: Resource pools are partitioned by agent. Each agent has its own bounded pool of connections, threads, tokens, and memory. One agent exhausting its pool cannot borrow from another agent's pool — isolating the resource failure to the agent that caused it.
The shipping bulkhead analogy: A bulkhead on a ship divides the hull into compartments. If one compartment floods, the bulkheads prevent the water from flowing to other compartments — keeping the ship afloat even though one section is flooded. Applied to agents: if the retrieval agent's database connection pool is exhausted, it doesn't starve the synthesis agent's connections — each has its own bounded pool.
What to partition: LLM API connections (per-agent token budgets and rate limit allocations), vector database connections (connection pools scoped per agent type), task queue consumers (separate consumer groups for different agent types, so one type's slowdown doesn't starve another type's queue), and memory limits (agent processes have memory caps so one memory-hungry agent doesn't cause OOM kills on co-located agents).
Addresses Scenario 3 directly: With bulkhead isolation, all 4 retrieval agents sharing the same vector database would each have their own connection pool. One agent's retry storm can only exhaust its own pool — it cannot consume connections belonging to the synthesis agents or the orchestrator.
What it does: Terminal action agents — those that take real-world irreversible actions — are constrained by rate limits and batch size caps. Requests above the threshold require human confirmation before execution.
The blast radius principle: The damage from a cascaded error is proportional to the number of actions executed before detection. Rate limiting reduces the per-minute action volume, giving monitoring systems time to detect an anomaly and trigger intervention before the full batch executes. Human confirmation for bulk actions ensures that a cascaded error producing 11,000 send instructions is reviewed by a human before 11,000 emails go out.
What to gate: Email/notification campaigns above N recipients. Financial transfers above threshold amount. Bulk record modifications or deletions. External API calls above a rate that exceeds normal operating parameters by more than 2×. Any irreversible action targeting >100 external entities simultaneously.
Ask your team: is there a hard cap on how many emails, notifications, or records your AI agents can act on in a single operation — enforced by the system, not just by the agent's instructions? Ask whether a misbehaving agent could trigger bulk actions affecting thousands of customers before anyone could intervene.