Padrão bulkhead para agentes de IA: como isolar falhas

Uma fila volumosa pode parar processos que continuam saudáveis

Uma empresa usa agentes para analisar documentos, preparar follow-ups comerciais e organizar chamados internos. As três rotinas compartilham os mesmos workers, conexões de banco e fila de revisão.

No fechamento do mês, milhares de documentos entram de uma vez. As análises ocupam os workers, consomem conexões e acumulam exceções para conferência. O CRM e o sistema de atendimento continuam disponíveis, mas os follow-ups e os chamados deixam de avançar porque a capacidade compartilhada foi tomada pelo lote financeiro.

O padrão bulkhead separa recursos para impedir que uma sobrecarga ou falha local consuma toda a capacidade do sistema. O nome vem dos compartimentos estanques de uma embarcação. Se uma área é comprometida, as demais preservam condição de operar.

Em agentes de IA, o isolamento pode acontecer em filas, workers, conexões, cotas, credenciais, revisores, provedores e orçamentos. A meta é conter o domínio de falha sem criar uma coleção de silos caros e difíceis de administrar.

O que o padrão bulkhead protege

Agentes combinam recursos compartilhados com demanda variável. Uma única tarefa pode gerar várias consultas, chamadas de modelo, subtarefas e aprovações.

Sem isolamento, alguns eventos conseguem ampliar seu alcance:

um cliente envia lote muito maior que o normal;
uma integração fica lenta e prende conexões;
uma classe de tarefa entra em retentativa;
um modelo aumenta latência;
uma fila humana acumula exceções;
um agente cria subtarefas demais;
um erro de configuração eleva concorrência;
uma rotina de baixa prioridade usa a reserva inteira.

Bulkhead limita quanto cada classe pode ocupar e preserva espaço para trabalho que pertence a outro domínio.

O resultado esperado não é impedir qualquer atraso. É evitar que uma pressão localizada transforme todos os processos em vítimas do mesmo gargalo.

Bulkhead, rate limit e circuit breaker resolvem problemas diferentes

Os três controles participam da resiliência, mas respondem perguntas próprias.

Bulkhead separa recursos

Define quais filas, pools, workers, conexões, cotas ou pessoas uma classe pode consumir. O objetivo é conter o alcance da falha.

Rate limit distribui consumo no tempo

O rate limit para agentes de IA limita taxa e concorrência por dependência, cliente ou tarefa. Ele controla quanto entra em uma janela.

Circuit breaker reage à degradação

O circuit breaker para agentes de IA interrompe chamadas a uma dependência que apresenta erro ou latência fora da faixa. Depois, testa a recuperação de forma gradual.

Uma arquitetura pode combinar os três:

bulkhead reserva workers comerciais e financeiros separados;
rate limit impede que cada pool ultrapasse a cota do CRM ou ERP;
circuit breaker pausa chamadas quando um endpoint fica instável.

Separar sem limitar ainda permite saturação dentro do compartimento. Limitar sem separar pode deixar uma classe consumir todo o recurso compartilhado dentro do teto global.

Bulkhead também difere de isolamento de dados

O isolamento entre clientes em agentes de IA protege identidade, contexto, memória, arquivos e permissões para impedir mistura de dados e ações.

Bulkhead protege principalmente capacidade e propagação de falhas. As duas preocupações podem usar a mesma fronteira por cliente, mas não são equivalentes.

Um sistema pode manter dados separados e colocar todos os clientes no mesmo pool de workers. Nesse caso, um lote legítimo de uma conta consegue atrasar as demais. Também pode manter pools separados e usar a credencial errada entre clientes, preservando capacidade enquanto cria incidente de dados.

Segurança e resiliência precisam ser verificadas separadamente.

Quando usar o padrão bulkhead

O padrão merece consideração quando:

processos de criticidade diferente compartilham recursos;
um cliente ou área pode produzir picos desproporcionais;
tarefas longas competem com interações de prazo curto;
integrações lentas prendem threads, workers ou conexões;
filas de retentativa disputam espaço com trabalho novo;
revisão humana forma gargalo comum;
uma falha localizada já afetou serviços não relacionados;
contratos exigem capacidade mínima ou isolamento por conta;
a recuperação precisa ocorrer por classes;
a empresa precisa suspender um fluxo sem parar os demais.

Exemplos:

mensagens em tempo real separadas de análises em lote;
pagamentos e aprovações financeiras separados de relatórios exploratórios;
clientes estratégicos com capacidade contratada;
leitura e escrita em pools distintos;
produção separada de homologação;
rotinas comuns separadas de reprocessamento e replay;
atendimento externo separado de automações internas.

Quando o custo da separação supera a proteção

Criar um pool para cada agente, cliente e tipo de tarefa aumenta ociosidade, configuração e observabilidade. A equipe passa a operar muitos compartimentos pequenos, cada um com pouca folga.

Um pool compartilhado pode ser suficiente quando:

o volume é baixo e previsível;
as tarefas possuem criticidade semelhante;
limites por fila e cliente já contêm a demanda;
a recuperação é rápida;
não existe histórico de propagação entre classes;
o custo de reservar capacidade supera o impacto do atraso;
a equipe consegue pausar a origem antes da saturação.

Comece pelo domínio de falha relevante. Não transforme nomes de agentes em fronteiras automáticas. Dois agentes podem pertencer ao mesmo processo e compartilhar recursos com segurança. Um único agente pode precisar de compartimentos diferentes para leitura, escrita e ações financeiras.

Identifique domínios de falha antes de dividir recursos

Um domínio de falha é o conjunto que pode degradar junto e ser recuperado sob a mesma decisão.

Mapeie:

processo empresarial;
classe de tarefa;
criticidade e prazo;
cliente ou unidade;
dependências usadas;
padrão de volume;
recursos compartilhados;
efeito da saturação;
autoridade para pausar;
caminho de recuperação.

Pergunte:

Qual origem consegue gerar pressão?
Que recurso fica ocupado primeiro?
Quais outros processos usam o mesmo recurso?
Que trabalho precisa continuar durante a falha?
Que capacidade mínima deve permanecer livre?
Quem decide reduzir carga ou ampliar reserva?

A fronteira correta costuma aparecer onde impacto, prazo e responsável mudam.

Escolha as camadas de isolamento

Bulkhead pode ser aplicado em várias camadas. Separar apenas a fila não resolve quando todos os consumidores usam o mesmo pool de conexões.

Filas

Filas distintas impedem que um lote pesado fique na frente de uma ação urgente. Podem separar:

tempo real;
processamento comum;
lote;
reprocessamento;
tarefas de alto risco;
revisão humana;
clientes ou áreas com contrato próprio.

Cada fila precisa de prioridade, prazo, tamanho máximo, expiração e destino quando satura.

Workers e concorrência

Pools de workers evitam que tarefas lentas ocupem toda a execução disponível. Defina mínimo, máximo e concorrência por classe.

Uma rotina de OCR pode usar workers próprios. Um agente comercial mantém capacidade para atualizar o CRM mesmo durante um lote documental.

Conexões e threads

Banco, HTTP, browser, arquivos e serviços internos usam pools escassos. Separe quando uma chamada lenta consegue prender recursos necessários para outros processos.

Limite também o tempo de ocupação. Um pool separado com timeout indefinido continua acumulando tarefas até esgotar sua própria fronteira.

Provedores, modelos e contas

Processos críticos podem usar cota ou conta de consumo própria quando o fornecedor permite. Isso reduz a chance de uma análise exploratória consumir o orçamento ou limite de uma operação de atendimento.

A separação precisa respeitar governança. Criar outra chave para contornar uma cota ou bloqueio viola o controle em vez de melhorar resiliência.

Orçamento

Reserve teto por processo, cliente, ambiente e classe. Um agente de pesquisa não deveria consumir a verba necessária para uma rotina que sustenta receita ou atendimento.

O controle de custos de agentes de IA governa orçamento por unidade e período. Bulkhead impede que uma classe alcance a reserva da outra.

Pessoas e aprovações

Revisores também são capacidade. Se toda exceção chega à mesma pessoa, os pools técnicos separados convergem para um gargalo humano comum.

Distribua por alçada, função, horário e substituição. Preserve uma rota para casos críticos sem transformar qualquer tarefa em prioridade máxima.

Credenciais e permissões

Identidades separadas limitam alcance e ajudam a atribuir consumo. Uma credencial de leitura não deve dividir o mesmo destino operacional de uma credencial capaz de pagamento ou exclusão.

Essa separação participa de segurança e de resiliência. Revogar uma capacidade sensível não precisa interromper leituras autorizadas que mantêm a operação legível.

Defina a unidade de isolamento

As fronteiras mais comuns são:

por processo;
por cliente;
por ambiente;
por criticidade;
por dependência;
por tipo de efeito;
por carga interativa ou em lote;
por novo trabalho ou recuperação.

A escolha deve refletir o risco real.

Por processo

Útil quando comercial, financeiro e atendimento possuem prazos e donos diferentes.

Por cliente

Útil quando uma conta produz volume alto, possui capacidade contratada ou precisa de contenção própria. Não exige um pool exclusivo para cada cliente. Faixas ou grupos podem atender a maior parte dos casos.

Por criticidade

Protege ações com prazo e impacto elevado. A classificação deve vir de regras verificáveis, não do adjetivo usado no texto da tarefa.

Por tipo de efeito

Leitura, preparação, escrita, comunicação externa e movimentação financeira podem receber compartimentos diferentes. Uma falha na escrita não precisa eliminar toda capacidade de análise.

Por fase de recuperação

Replay, reconciliação e drenagem de backlog merecem limite próprio. A recuperação não deve competir sem controle com a demanda nova.

Dimensione cada compartimento pela capacidade útil

Reservar recursos exige compreender demanda e prazo. O planejamento de capacidade para agentes de IA ajuda a medir chegada, tempo de serviço, gargalo, folga e drenagem.

Para cada bulkhead, registre:

unidade válida entregue;
volume comum e pico;
tempo de serviço;
concorrência;
capacidade líquida;
prazo máximo;
tamanho e idade da fila;
folga necessária;
custo da reserva;
condição de ampliação;
condição de redução;
responsável.

Evite dois extremos.

O primeiro é reservar demais e pagar por pools ociosos que raramente protegem algo. O segundo é reservar apenas no papel, deixando todos os pools dependerem de uma única conexão, credencial ou pessoa.

A fronteira precisa existir no recurso que realmente satura.

Use capacidade mínima, máxima e empréstimo controlado

Um compartimento pode ter:

capacidade mínima garantida;
teto máximo para conter pressão;
capacidade elástica dentro de um pool comum;
regra de empréstimo quando outras classes estão ociosas;
retomada da reserva quando a classe protegida recebe demanda.

O empréstimo melhora utilização, mas precisa ser revogável. Se um lote ocupa temporariamente workers livres, novas tarefas críticas devem recuperar sua faixa sem esperar o lote inteiro terminar.

Use unidades preemptíveis apenas quando a tarefa permite pausa ou checkpoint. Interromper uma escrita externa no meio pode criar resultado incerto.

Defina o comportamento quando o compartimento satura

Cada bulkhead precisa terminar em um estado operacional conhecido.

Possíveis respostas:

recusar nova entrada com protocolo claro;
manter na fila até o prazo;
reduzir escopo;
mover trabalho sem urgência para lote;
expirar unidades vencidas;
pausar a origem;
encaminhar uma parcela para revisão;
usar rota previamente homologada;
ativar capacidade temporária;
voltar ao processo manual;
preservar apenas classes críticas.

Nunca faça overflow silencioso para o pool protegido de outro processo. Isso apaga a fronteira justamente quando ela deveria funcionar.

Uma tarefa recusada precisa deixar evidência, responsável e próxima ação. Descartar por falta de capacidade transforma contenção técnica em perda operacional.

Proteja recursos compartilhados que permanecem abaixo dos pools

Filas e workers separados podem convergir para componentes comuns:

banco de estado;
broker;
provedor de identidade;
gateway de modelos;
armazenamento;
rede;
serviço de logs;
equipe de suporte.

A arquitetura deve identificar esses pontos e aplicar:

cotas por consumidor;
pools de conexão;
prioridades;
limites de cardinalidade;
reserva de capacidade;
modos degradados;
monitoramento por classe.

Se todos os compartimentos escrevem no mesmo banco sem limite, um lote consegue saturar a base e atravessar a separação dos workers.

Bulkhead reduz propagação. Ele não elimina dependências compartilhadas.

Coordene com retentativas e filas de erro

Retentativas podem manter um compartimento ocupado por trabalho sem chance imediata de sucesso. Separe nova demanda, tentativas agendadas e itens que esgotaram o teto.

Uma política útil registra:

classe do erro;
tentativa atual;
próxima janela;
prazo da unidade;
dependência afetada;
capacidade consumida;
condição de parada;
rota para reconciliação ou fila de erros.

A fila de erros para agentes de IA retira unidades problemáticas do fluxo saudável. O bulkhead impede que a própria rota de recuperação consuma os recursos do trabalho novo.

Retentativas de um cliente também não deveriam monopolizar o pool de todos os clientes.

Preserve idempotência durante transbordo e recuperação

Mover uma unidade entre filas, reiniciar worker ou ativar outro pool pode provocar reentrega. Mantenha o mesmo identificador e a mesma chave de efeito.

Antes de executar:

consulte o estado atual;
confirme a versão do objeto;
verifique ação manual durante a espera;
preserve a chave original;
confirme a autoridade;
bloqueie efeito já concluído.

O guia de idempotência para agentes de IA cobre reserva atômica, resultado incerto e confirmação externa.

Um compartimento alternativo amplia capacidade. Ele não autoriza repetir a consequência.

Monitore por compartimento e pelo sistema inteiro

Acompanhe por bulkhead:

chegadas e conclusões;
utilização;
concorrência ativa;
tamanho e idade da fila;
prazo estimado de drenagem;
recusas e expirações;
retentativas;
erros por causa;
tempo de serviço;
custo por unidade válida;
capacidade mínima usada;
capacidade emprestada;
tempo para recuperar reserva;
efeitos em dependências compartilhadas;
impacto em SLA e resultado do processo.

Também monitore o conjunto. Compartimentos verdes podem esconder um broker, banco ou revisor global perto da saturação.

Um alerta útil informa:

qual domínio saturou;
que recurso está ocupado;
quais processos permanecem protegidos;
quantas unidades aguardam;
quando o prazo será perdido;
que contenção entrou;
quem decide o próximo movimento.

Teste a propagação que o padrão promete conter

Inclua cenários como:

lote de um cliente ocupa seu teto;
tarefa longa prende todos os workers de uma classe;
integração lenta consome conexões;
fila de retentativas cresce rapidamente;
processo crítico recebe demanda durante pico de baixa prioridade;
banco compartilhado degrada;
revisor principal fica indisponível;
capacidade emprestada precisa voltar à classe protegida;
um pool reinicia com unidades em andamento;
trabalho transborda para rota alternativa;
uma credencial é revogada em somente um compartimento;
recuperação do backlog compete com entradas novas;
um limite é configurado alto demais;
monitoramento perde a identidade da classe.

Verifique se a falha permanece dentro do domínio esperado, se tarefas preservam estado e se processos protegidos mantêm sua capacidade mínima.

O ambiente de teste para agentes de IA deve reproduzir filas, pools, limites e dependências. A engenharia do caos para agentes de IA pode validar combinações depois que os casos determinísticos estiverem cobertos.

Erros comuns

Separar filas e compartilhar todos os workers

A ordem muda, mas a capacidade continua comum. Tarefas lentas ainda ocupam toda a execução.

Criar um pool por agente

O nome do componente não define o domínio de falha. A fronteira deve acompanhar processo, impacto e recurso escasso.

Reservar capacidade sem observar uso

Pools ociosos geram custo e escondem uma configuração inadequada. Meça utilização e revise a reserva.

Permitir overflow automático

Quando um compartimento satura, enviar trabalho para qualquer pool disponível pode contaminar a área protegida.

Ignorar pessoas

Filas técnicas separadas podem despejar exceções na mesma pessoa. O gargalo reaparece no último metro.

Compartilhar uma dependência sem cota

Workers separados não protegem um banco, broker ou provedor usado sem limite por classe.

Usar credencial extra para contornar limite

Resiliência trabalha dentro das políticas. Criar outra identidade para escapar de uma barreira aumenta risco e dificulta atribuição.

Checklist de implementação

[ ] Os domínios de falha foram definidos por impacto e recuperação?
[ ] Processos críticos possuem capacidade mínima protegida?
[ ] Filas, workers e conexões refletem a fronteira necessária?
[ ] Tarefas interativas, lotes e recuperação estão separadas quando preciso?
[ ] Clientes de alto volume possuem contenção adequada?
[ ] Dependências compartilhadas aplicam cotas por consumidor?
[ ] Revisão humana faz parte do desenho?
[ ] Cada compartimento possui mínimo, máximo, prazo e dono?
[ ] Empréstimo de capacidade pode ser revogado?
[ ] Saturação termina em um estado conhecido?
[ ] Overflow para outra reserva exige política explícita?
[ ] Transbordo e retomada preservam idempotência?
[ ] Métricas mostram saúde por compartimento e no conjunto?
[ ] Testes provam que uma falha local não contamina processos protegidos?
[ ] O custo do isolamento é menor que o impacto evitado?

Isole o gargalo que realmente pode se propagar

O padrão bulkhead ajuda agentes a compartilhar uma plataforma sem compartilhar todo o destino de cada falha. Filas, workers, conexões, cotas, orçamentos e pessoas podem formar fronteiras compatíveis com criticidade, cliente e processo.

O desenho funciona quando a separação alcança o recurso escasso, preserva capacidade mínima e define o que acontece na saturação. Criar filas com nomes diferentes sobre o mesmo gargalo apenas pinta compartimentos no diagrama.

Comece pelos domínios que já possuem impacto, prazo e dono distintos. Proteja o trabalho crítico, limite a pressão local e teste a recuperação. A empresa ganha resiliência sem precisar duplicar toda a infraestrutura.