O problema da falha em cascata: como um único agente em falha pode corromper uma pipeline inteira

Cada agente numa pipeline multiagente é desenhado individualmente para ser correto e seguro. O problema de composição pergunta se as propriedades de segurança se mantêm quando esses agentes são encadeados. O problema da falha em cascata pergunta algo mais agudo: quando um agente falha em produção, sob carga e com inputs reais, até onde viaja o dano? Na maioria das pipelines, mais longe do que alguém especificou, porque a contenção nunca foi desenhada.

Uma falha pode propagar-se de três formas. Pode empurrar outputs corrompidos para a frente, tratando agentes a jusante como consumidores passivos. Pode abusar de autoridade delegada, usando credenciais para instruir subagentes de formas que a hierarquia de principal nunca autorizou. E pode esgotar recursos partilhados, como memória, chamadas API com limite de taxa ou capacidade de hardware, prejudicando agentes vizinhos. Cada modo exige mecanismo de contenção diferente, e poucas pipelines têm algum.

Propagação de outputs corrompidos

Um agente a jusante que confia no input a montante sem validação independente é um amplificador passivo da falha. Se o agente a montante produzir um output plausível mas errado, por degradação do modelo, envenenamento de contexto ou falha silenciosa de hardware, o agente seguinte incorpora esse erro no seu raciocínio e passa adiante um erro ainda mais entrelaçado. Quando a corrupção chega ao output final, é inseparável de passos válidos e invisível para o consumidor terminal.

A correção estrutural não é desconfiar de todos os inputs, mas definir em cada fronteira que propriedades do output a montante devem valer antes de prosseguir. Não é verificação completa do raciocínio, o que seria intratável. São invariantes de fronteira: o output deve estar numa faixa, referir apenas fontes atestadas e carregar assinatura válida ao nível do estágio. Um agente que recebe input violando invariantes deve parar e escalar, não continuar sobre estado corrompido.

Corrupção da cadeia de autoridade

Um agente em mau funcionamento não age só em nome próprio. Em muitas arquiteturas, um orquestrador detém credenciais para criar e dirigir subagentes. Esses subagentes aceitam instruções na suposição implícita de que o orquestrador opera dentro da autorização. Quando o orquestrador é corrompido por envenenamento de contexto, erro lógico ou modelo comprometido, os subagentes executam fielmente instruções que a hierarquia original nunca autorizou. Eles não se comportam mal; seguem o desenho. A falha de autorização é invisível para eles.

Fechar isto exige que subagentes validem não só a credencial que lhes dá a tarefa, mas a cadeia de autoridade por trás dela. O agente delegante deve vincular criptograficamente o seu âmbito de autorização à tarefa delegada. Uma instrução só é válida se o orquestrador demonstrar autoridade para a emitir. Isto é mais forte do que modelos atuais, que verificam a credencial em vez da cadeia de autoridade que ela codifica.

Cascata por exaustão de recursos

Um agente em falha consome recursos de forma diferente de um agente saudável. Um modelo preso num ciclo de raciocínio faz muito mais chamadas geradoras de tokens. Um agente de atestação de hardware que repete pedidos contra serviço indisponível mantém ligações abertas. Um gerador de plano de cuidados à espera de contexto a montante ocupa capacidade que agentes de outros residentes precisam. Estas falhas propagam-se horizontalmente: vizinhos começam a falhar não por inputs defeituosos, mas por contenção introduzida pelo estágio em falha.

A resposta arquitetural é análise de raio de impacto. Para cada agente, definir a reivindicação máxima de recursos, o tempo máximo antes de um disjuntor o terminar e a ação explícita quando o limite é atingido: falha limpa com sinal de erro, fallback para caminho reduzido ou escalada humana. Um disjuntor é uma decisão pré-comprometida sobre degradação aceitável. Sem ele, a resposta ao estágio em falha fica por omissão em inação.

Como os cruzamentos concentram o problema

No cruzamento da segurança pós-quântica, a cascata tem dimensão criptográfica. Uma chave de assinatura num estágio intermédio cria cadeia de confiança para agentes a jusante. Se esse estágio for comprometido, por chave vazada ou modelo manipulado para assinar outputs maliciosos, todas as atestações a jusante que encadeiam a partir dele ficam invalidadas. A migração pós-quântica é oportunidade para redesenhar cadeias com raízes independentes por estágio, não derivações de uma hierarquia única.

No cruzamento do hardware, o problema aparece como herança de atestação. Pipelines atestadas por hardware muitas vezes atestam a pipeline inteira em vez de cada estágio. Um estágio que execute parcialmente fora da fronteira atestada, por erro de memória, atualização de firmware durante execução ou escape de contentor, corrompe a afirmação de atestação para estágios seguintes. Atestação independente por estágio contém o raio de impacto no estágio comprometido.

No cruzamento dos cuidados no mundo físico, a falha em cascata tem imediatismo. Um agente de avaliação que produz pontuação de risco errada alimenta premissa errada no agente de medicação, no agente de escalada e no de notificação familiar. Quando um clínico revê o output final, a cascata já produziu um plano coerente mas profundamente errado. O invariante em cada fronteira de cuidados tem de incluir verificações de plausibilidade clínica, não apenas técnicas.

Desenhar antes da implantação

A falha em cascata não pode ser corrigida depois examinando registos. Quando o output final é revisto, a cadeia de corrupção é indistinguível de raciocínio válido. Invariantes de fronteira, validação de cadeia de autoridade, disjuntores e limites de raio de impacto devem ser desenhados antes de a pipeline correr e aplicados em cada transição de estágio. Uma pipeline não desenhada para falhar é desenhada para falhar em escala.