Arquiteturas Event-Driven vs. Polling: como projetar gatilhos confiáveis para agentes de IA

Webhooks e polling não são alternativas técnicas neutras, são contratos operacionais com implicações diretas na confiabilidade de agentes de IA em produção. Webhooks entregam eventos 'pelo menos uma vez', mas sem ordem nem garantia de entrega, exigindo idempotência estrutural (não só no código, mas nas chaves de deduplicação derivadas de payload e contexto). Polling, por sua vez, é previsível, mas escala mal: um agente que verifica a cada 30 segundos em 10 mil instâncias gera 2 milhões de requisições por hora, sem valor se o dado mudou apenas duas vezes. A saída madura, como mostram casos reais da Netflix e Microsoft Build 2026, é combinar CDC com message bus (Kafka ou Azure Service Bus) para alimentar canais de evento duráveis, enquanto o polling serve apenas como mecanismo de reconciliação periódica, não de acionamento principal.

Isso muda o papel do runtime de agente: ele deixa de ser um simples executor de prompts e vira um orquestrador com estado persistido, capacidade de replay e integração nativa com filas. Plataformas como Azure AI Foundry e ambientes BYOC baseados em microVMs (ex.: Northflank) já incorporam isso, mas a maioria dos times ainda tenta encaixar agentes em runtimes stateless como Lambda, gerando falhas silenciosas em sessões longas e perda de contexto entre chamadas. O erro mais comum não é escolher webhook ou polling, mas ignorar que o verdadeiro ponto de falha está na camada de persistência do estado do agente, não na fonte do gatilho.

A cobertura CEVIU de 2026-05-30 sobre Kafka e Spark já alertava que arquiteturas bonitas em diagramas falham sob SLA real, agora, a nova matéria mostra como essa falha se materializa especificamente em agentes: não é o throughput do Kafka que quebra, mas a ausência de idempotência estrutural nos consumidores e a falta de reconciliação explícita entre evento e estado. Também evolui o conceito de backpressure: antes tratado como controle de carga em pipelines (2026-06-01), agora é aplicado diretamente no ciclo de vida do agente, quando um agente fica sobrecarregado, ele não só pausa, mas sinaliza ao message bus para reduzir a taxa de entrega via dead-letter queue ou backoff adaptativo, algo ausente nas primeiras implementações descritas em 'Como controlamos o Claude' (2026-05-27).

Agentes de IA não são apenas 'LLMs com ferramentas': são processos de longa duração que interagem com sistemas externos, armazenam estado e tomam decisões sequenciais. Se o gatilho falhar, por duplicata não tratada, latência excessiva ou perda de evento, o agente pode executar ações incorretas, repetir transações ou travar em loops silenciosos. Isso não é teórico: o Gartner prevê que 40% das empresas desativarão agentes autônomos até 2027 por falhas de governança identificadas *após* implantação, muitas delas originadas em arquiteturas de acionamento frágeis. Projetar gatilhos confiáveis é, na prática, definir os limites operacionais do agente: o que ele pode assumir, o que deve verificar e o que nunca deve repetir.