A maioria dos sistemas de agentes em produção opera sobre um loop imperativo: o orquestrador recebe uma tarefa, decompõe em subtarefas e delega, depois coleta resultados pra decidir o próximo passo. Cada iteração consome tokens e acumula latência, e exige que o orquestrador mantenha uma representação do estado global precisa o suficiente pra rotear a próxima decisão. Quando o volume de tarefas cresce, o orquestrador vira gargalo, porque cada decisão de roteamento é uma chamada ao modelo, e cada chamada carrega o custo proporcional ao contexto acumulado. O padrão funciona em fluxos curtos e degrada de forma não linear quando a concorrência aumenta.
O modelo event-driven inverte essa dinâmica. Cada agente subscreve a eventos que definem sua fronteira de atuação, e dispensa o orquestrador que puxa trabalho e distribui. Quando um evento de domínio entra no barramento, os agentes interessados reagem e produzem saídas que se tornam novos eventos, de modo que o fluxo avança sem que nenhum componente central precise manter o grafo completo de execução em memória. O estado do sistema reside no barramento de eventos, materializado e recuperável, e o contexto da conversa deixa de carregar essa responsabilidade. Pra mim, a diferença entre um orquestrador que consulta o modelo a cada decisão de roteamento e um barramento que roteia eventos por tópico e subscription é a mesma entre um controller monolítico e microsserviços desacoplados: a segunda abordagem não é mais simples, mas escala em dimensões que a primeira não alcança.
O ganho mais imediato é em custo. Um agente event-driven permanece inativo até que um evento relevante chegue, o que significa zero consumo de tokens no tempo de espera. No loop imperativo, o orquestrador precisa verificar estado e reprocessar contexto periodicamente mesmo sem tarefa nova. A diferença é marginal em pipelines de baixa frequência e fica dominante em sistemas com centenas ou milhares de tarefas por hora. Apache Kafka, Amazon EventBridge e Redpanda são os barramentos mais comuns em arquiteturas reativas em 2026, e a escolha entre eles depende mais do perfil de throughput e da infraestrutura existente do que de capacidade funcional.
A latência também muda de perfil. No modelo imperativo, a latência de cada tarefa é a soma das latências de cada chamada ao modelo, porque as etapas são sequenciais por definição. No modelo reativo, agentes que não dependem entre si processam eventos em paralelo, e a latência total é determinada pelo caminho crítico. Em um cenário recente de processamento documental com pipeline de seis agentes em que três pares operavam em paralelo, a migração reduziu a latência ponta a ponta de 14 segundos pra 6, sem alterar modelos, prompts ou catálogos de ferramentas. O ganho veio inteiramente da topologia.
O custo dessa inversão é a perda de controle centralizado sobre o fluxo. No orquestrador imperativo, a sequência de execução é explícita no código e cada decisão de roteamento pode ser logada com o raciocínio que a produziu. No sistema event-driven, o fluxo emerge da composição dos subscriptions, e reconstruir a trajetória de uma tarefa exige correlacionar eventos distribuídos no tempo. A observabilidade fica mais cara e, ao mesmo tempo, mais necessária. Correlation IDs, tracing distribuído e projeções de estado a partir do log deixam de ser acessórios e passam a ser infraestrutura obrigatória. Quem migra sem investir em observabilidade proporcional perde a capacidade de diagnosticar falhas, e esse trade-off se paga no primeiro incidente sério.
O AutoGen v0.4 da Microsoft foi reescrito com um core event-driven e execução async-first, o que sinaliza que a comunidade de frameworks agênticos está convergindo pra esse modelo. O LangGraph opera com grafos de estado explícitos que podem ser mapeados pra topologias reativas quando combinados com checkpointing externo e filas de mensagens. O CrewAI, cujos processos Sequential e Hierarchical ainda operam como padrão síncrono apesar do suporte async introduzido em versões recentes, tende a enfrentar pressão de migração à medida que os casos de uso em produção exigirem concorrência real entre agentes. O que se vê é a readoção quase literal das primitivas que sustentam sistemas distribuídos há duas décadas: publicação, subscription, barramento, idempotência e replay.
Na minha avaliação, a decisão de migrar pra event-driven não é binária nem imediata. O ponto de transição aparece quando o orquestrador vira gargalo de latência ou de custo, quando a concorrência não pode ser explorada pela topologia atual, ou quando a resiliência exige que o estado seja recuperável sem reexecutar o pipeline inteiro. Antes desse ponto, a complexidade do modelo reativo não se justifica, e o orquestrador imperativo com validação estruturada nas fronteiras continua sendo a escolha correta. Depois dele, insistir no modelo imperativo significa pagar custo crescente por uma previsibilidade que o próprio modelo já não sustenta.
Nos sistemas que fizeram a transição com sucesso, a arquitetura event-driven não eliminou o orquestrador, transformou. Ele deixou de decidir cada passo e passou a definir as regras de subscription e a monitorar o fluxo agregado, intervindo só quando o sistema desvia do esperado. A inteligência de roteamento saiu do loop quente da execução e migrou pra configuração da topologia, onde mudanças são deliberadas e versionadas. O agente que antes esperava instruções passou a reagir a contexto, e o sistema que dependia de um cérebro central passou a operar sob contratos entre partes. A engenharia de sistemas distribuídos não inventou nada novo pra resolver os problemas de agentes, ela já tinha as respostas. O que mudou foi a pergunta.