Fluxo Agentic

O fluxo de trabalho agentic e os agentes autônomos são conceitos que vêm ganhando destaque no mundo da inteligência artificial, especialmente com o aumento do uso da inteligência artificial geradora. De acordo com o relatório da Deloitte, até 2027, cerca de 50% das empresas que utilizam inteligência artificial geradora terão lançado projetos-piloto ou provas de conceito de inteligência artificial agentic. É uma onda de adoção grande o suficiente para que o termo “agentic” comece a ser aplicado a quase tudo que inclui uma chamada de modelo de linguagem grande, desde um pipeline de cinco etapas fixas onde a terceira etapa acontece de chamar o GPT para um resumo até um sistema que se dirige completamente sozinho e planeja seu próprio caminho sem nenhum roteiro.

No entanto, essas duas coisas não são a mesma. Tratá-las como intercambiáveis leva a dois tipos de erros: superengenharia de uma tarefa simples e bem compreendida com autonomia desnecessária ou subengenharia de um problema genuinamente aberto, forçando-o a entrar em um pipeline rígido que quebra no momento em que a realidade se desvia do plano. A Anthropic traça a linha fundamental em seu artigo amplamente citado “Construindo Agentes Eficazes”: os fluxos de trabalho são sistemas onde os modelos de linguagem grandes e as ferramentas são orquestrados por meio de caminhos de código pré-definidos. Os agentes são sistemas onde os modelos de linguagem grandes direcionam dinamicamente seu próprio processo e uso de ferramentas, mantendo o controle sobre como eles realizam uma tarefa. Tudo neste artigo é detalhado sob essa distinção.

Este artigo mapeia o espectro completo de fluxos de trabalho determinísticos, sistemas orquestrados, agentes reativos simples e sistemas de agentes autônomos múltiplos, com código em cada etapa que torna a diferença de controle concreta em vez de abstrata. O código aqui ilustra a arquitetura, não um sistema implantável; o objetivo de cada trecho é mostrar quem decide o que acontece em seguida, não enviar um recurso. Antes de comparar as arquiteturas, vale a pena substituir a pergunta errada. A pergunta não é “este sistema usa um modelo de linguagem grande”. Quase tudo usa agora. As duas perguntas que realmente importam, emprestando uma estrutura que ganhou tração real em círculos de arquitetura, são: este processo precisa ser repetível, auditável e explicável passo a passo? E: o caminho correto é conhecido com antecedência ou o sistema precisa descobri-lo em tempo de execução?

Um sistema pode depender muito de um modelo de linguagem grande e ainda ser completamente determinístico em estrutura – um pipeline fixo onde uma etapa acontece de chamar um modelo para geração de texto, mas a próxima etapa é hardcoded independentemente do que é retornado. Um sistema também pode ser “agentic” com muito pouca autonomia real: um loop rigidamente scriptado com apenas duas ações permitidas e um limite de etapa rígido. A presença de uma chamada de modelo de linguagem grande não é o sinal. A propriedade do fluxo de controle é. A própria documentação de padrões de design do Google Cloud traça essa linha exata operacionalmente: fluxos de trabalho determinísticos incluem tarefas com um caminho claramente definido conhecido com antecedência, onde as etapas não mudam muito de uma execução para a outra. Fluxos de trabalho que requerem orquestração dinâmica envolvem problemas onde o agente deve determinar a melhor maneira de prosseguir, sem um roteiro pré-definido. É o espectro que este artigo percorre, uma etapa de cada vez.

Este é o baseline. Um fluxo de trabalho determinístico tem uma sequência de etapas conhecida decidida no tempo de design, por um humano, em código. Um modelo de linguagem grande pode estar dentro de qualquer etapa – gerando texto, classificando entrada, redigindo um resumo – mas não escolhe o que acontece após a execução da sua própria etapa. O código de orquestração faz isso, independentemente do que o modelo retorna. Para executar, basta rodar o comando python deterministic_pipeline.py, sem dependências necessárias. O resultado mostra que o modelo de linguagem grande classificou as duas entradas de maneira completamente diferente, faturamento versus geral, e fez zero diferença para o caminho que cada entrada tomou. Ambas passaram pelas mesmas quatro funções na mesma ordem. É a definição completa de determinístico: a rota é fixa, mesmo quando um modelo de linguagem grande está fazendo um trabalho real dentro de uma das etapas.

Este é o terreno médio que mais frequentemente é mal rotulado como “agentic”, e vale a pena parar aqui porque é a linha que a maioria das pessoas realmente cruza quando começam a usar essa palavra de forma solta. Um fluxo de trabalho orquestrado ainda tem um grafo de caminhos possíveis definidos inteiramente com antecedência, mas qual caminho é tomado agora depende de uma decisão em tempo de execução, frequentemente feita por uma chamada de modelo de linguagem grande. Este ainda é um fluxo de trabalho. Cada ramo que poderia ser tomado foi antecipado e escrito em código por um humano antes de o sistema ser executado. O modelo de linguagem grande escolhe um ramo de um menu que alguém mais escreveu. Ele não inventa um novo item nesse menu.

Para executar, basta rodar o comando python orchestrated_pipeline.py, sem dependências necessárias. O resultado mostra que três entradas diferentes tomaram três caminhos diferentes. É exatamente a “orquestração dinâmica” categoria que o Google Cloud separa dos agentes genuínos – o sistema precisa planejar e rotear, mas dentro de uma estrutura que um humano ainda projetou completamente. É importante notar que os exemplos de código fornecidos aqui são ilustrativos e não devem ser considerados como sistemas implantáveis. O objetivo é mostrar a diferença de controle entre os diferentes tipos de fluxos de trabalho