Michel Tricot, CEO da Airbyte, publicou em 14 de maio um post comparando arquitetura event-driven e polling para acionar agentes de IA em pipelines de dados. O argumento central: um agente que recebe dado com cinco minutos de atraso pode aprovar reembolso errado, escalar ticket ja resolvido ou mandar email para o cliente errado.
Por que a latencia importa de outro jeito agora
Em pipeline de BI tradicional, atraso de minutos ou horas e tolerado. O dashboard atualiza tarde, o relatorio sai com defasagem, e a vida segue. Agente de IA muda o calculo: o output da agente vira acao — manda email, abre ticket, aprova transacao, agenda intervencao.
Quando dado velho vira acao, o erro nao e estatistico, e operacional. O agente que age com base em estado defasado nao gera um relatorio errado, gera uma decisao errada com consequencias diretas. Tricot usa exemplos concretos: cliente que recebe email de cobranca apos ter quitado a divida; ticket de suporte escalado para um time que ja resolveu; reembolso aprovado para uma compra cancelada.
O que e event-driven, o que e polling
Na arquitetura event-driven (orientada a eventos), o sistema fonte publica um evento toda vez que algo muda — nova linha em tabela, mudanca de status, transacao criada. Um broker como Kafka, Pulsar ou um SQS distribui o evento e o agente recebe a notificacao em segundos.
No polling, o agente pergunta periodicamente: “o que mudou desde a ultima vez que olhei?”. A cadencia define a defasagem: polling de 1 minuto da latencia media de 30 segundos; polling de 5 minutos da 2,5 minutos. Quanto mais frequente, mais carga no sistema fonte.
Os trade-offs em pratica
O post lista quatro dimensoes para decidir.
Latencia: event-driven entrega segundos; polling entrega minutos. Para acao sensivel a tempo, eventos ganham. Para sincronizacao de catalogo que vai usar amanha, polling resolve.
Custo: polling escala em consultas — cada agente, cada minuto, gera carga. Eventos escalam em throughput de broker, que e mais previsivel mas pede infraestrutura adicional.
Complexidade operacional: polling e cliente HTTP. Event-driven exige montar broker, lidar com replay, dead letter queue, ordering. A curva de aprendizado e maior.
Tolerancia a falhas: polling se recupera sozinho — a proxima rodada pega o que ficou para tras. Event-driven precisa de garantias de entrega configuradas certo. Mensagem perdida pode significar acao perdida.
Onde polling ainda faz sentido
Tricot defende que polling nao morreu. O caso de uso onde brilha: sistemas legados que nao expoem webhook nem mantem changelog publicavel. Banco antigo, ERP de 2005, planilha do Excel rodando no SharePoint. Para essas fontes, polling e a unica opcao viavel.
Outro caso: agentes que aceitam latencia de minutos sem custo operacional. Daily refresh de catalogo, recalculo noturno de KPI, sincronizacao de dimensao raramente atualizada. Forcar event-driven nesses casos custa mais do que entrega.
Padroes hibridos que aparecem
O post discute combinacoes uteis. Eventos como caminho principal + polling como fallback para detectar mensagens perdidas. Polling de baixa frequencia para descobrir fontes novas; eventos para acompanhar mudancas dentro de fontes ja descobertas. Polling para snapshot inicial; eventos para mudancas incrementais.
A mensagem implicita: o time bom raramente escolhe so um. A maior parte do trabalho de quem opera pipeline em escala e decidir caso a caso e tornar o padrao explicito no codigo.
A peca de produto que aparece no fim
Tricot conecta a discussao com o Airbyte Agent Engine, anunciado pela empresa em 4 de maio. O Engine expoe gatilhos via API — evento via webhook, polling configurado, schedule fixo — para que um agente conectado nao precise lidar com integracao a cada fonte manualmente.
E marketing dentro do post tecnico, mas a posicao do conteudo deixa visivel. Quem nao quer comprar produto pode usar so o framework conceitual; quem quer terceirizar a parte chata da integracao tem o que olhar.
Como avaliar isso na pratica
Para times que ainda nao decidiram a arquitetura: vale mapear cada fonte por dois eixos — frequencia de mudanca real e custo operacional do erro se a acao do agente sair com base em dado velho. Fontes com mudanca alta e erro caro vao para eventos; o resto pode comecar em polling e migrar quando o custo justificar.
A serie do Airbyte sobre infraestrutura agentic-first ja publicou outros posts em maio. Vale acompanhar a sequencia se voce esta desenhando pipeline novo agora.
Reportado originalmente por Airbyte Blog em 2026-05-14.
