Depois de discutir as dificuldades de continuidade em arquiteturas híbridas, vale olhar para uma pergunta mais básica: em quais situações eu começaria com LangGraph, Agno ou CrewAI? Os três frameworks têm áreas de sobreposição e todos evoluíram bastante. Uma comparação baseada apenas em checklist de features tende a envelhecer rápido e, pior, não ajuda muito a decidir a arquitetura.
O critério que considero mais útil é observar a forma como o problema já aparece no domínio. Alguns sistemas são claramente workflows com estados e transições, enquanto outros se parecem mais com uma plataforma de especialistas reutilizáveis. Há também casos em que o negócio descreve naturalmente uma equipe com papéis, tarefas e entregas. Cada um desses formatos encontra uma abstração mais confortável em um dos frameworks.
Uma síntese aproximada seria:
Ampliar ↗Isso não cria fronteiras rígidas. LangGraph suporta multiagentes, Agno possui workflows e CrewAI possui Flows stateful. A diferença aparece no caminho que cada ferramenta torna mais direto e na quantidade de decisões que o time precisa assumir por conta própria.
LangGraph quando o processo precisa ficar visível no código#
Eu tendo a começar por LangGraph quando a aplicação se parece com uma máquina de estados de negócio. Crédito é um bom exemplo: uma solicitação passa por validação documental, fraude, análise, política, aprovação e execução. Em um fluxo assim, quero conseguir apontar no código quais estados existem, quais transições são permitidas, onde há checkpoint, quais etapas podem interromper a execução e quais condições liberam o próximo passo.
Ampliar ↗Essa abordagem combina bem com long-running workflows, branching, loops, human-in-the-loop e regras determinísticas intercaladas com chamadas de modelo. Outra vantagem é que nem todo nó precisa ser um agente. Um nó pode chamar uma API, executar uma regra Python, consultar um banco, esperar uma aprovação ou disparar uma tarefa assíncrona. O LLM fica concentrado nas partes que realmente precisam de interpretação ou geração.
O custo é a quantidade de engenharia explícita. State schema, nodes, edges, reducers, checkpointers, interrupts e subgraphs exigem decisões que outros frameworks escondem ou abstraem melhor. Para um agente pequeno com poucas ferramentas, esse nível de estrutura pode ser desnecessário, mas para um processo regulado ou com recuperação complexa, ele costuma ser justamente o que precisamos enxergar.
Agno quando o produto é uma plataforma de especialistas#
Agno costuma ficar atraente quando o domínio é composto por agentes ou Teams reutilizáveis e a equipe quer um ecossistema integrado ao redor deles. É natural organizar a solução em torno de Agent, Team, Workflow, sessões, knowledge e memory, e depois aproveitar o runtime e as APIs do AgentOS.
Pense em uma plataforma com analista de risco, pesquisador, especialista de investimentos e agente de compliance. Cada componente pode ter suas ferramentas e knowledge próprios, e o sistema precisa servi-los por API, manter sessões, observar runs e integrar outros protocolos. Nesse cenário, montar toda a camada operacional por fora pode custar mais do que a aplicação em si, e a integração oferecida pelo ecossistema passa a ter bastante valor.
A atenção principal, na minha experiência, é evitar que essa conveniência esconda responsabilidades sobrepostas. Se sessão, workflow, background jobs, HITL e retries já estão sendo controlados pelo AgentOS, não faz sentido introduzir outra camada que também tente possuir a mesma execução global sem uma divisão muito clara. Agno funciona bem como runtime principal; também funciona bem como capability especializada, desde que o papel esteja definido.
CrewAI quando o negócio já fala em pessoas, papéis e tarefas#
CrewAI me parece particularmente natural em problemas que são descritos como uma equipe. Uma due diligence pode ter um analista financeiro, um analista jurídico, um especialista de risco e alguém responsável pelo relatório final. Uma pesquisa pode ter pesquisador, crítico e redator. O domínio já chega em termos de quem faz o quê e qual entrega cada papel produz.
Ampliar ↗Nesse contexto, Agent, Task, Crew e Process representam o problema de forma bastante direta. A configuração declarativa também ajuda quando roles e tasks precisam ser ajustados sem redesenhar uma máquina de estados completa. CrewAI possui Flows para casos em que há necessidade de processo mais estruturado, persistência e routing, então eu evitaria tratá-lo como um framework restrito a demos de agentes colaborando.
O cuidado reaparece quando um Flow começa a ocupar a mesma camada que outro orquestrador. Se LangGraph controla o processo global e um CrewAI Flow também registra fases, retries e pontos de retomada do mesmo caso, voltamos à dificuldade discutida nos textos anteriores. Em uma arquitetura híbrida, eu prefiro usar um Crew como capability delimitada dentro do workflow principal, deixando o Flow para situações em que o próprio CrewAI foi escolhido como runtime do processo.
Comparando pelo tipo de problema#
Ampliar ↗Eu usaria essa tabela como ponto de partida, não como ranking. A escolha tende a ficar mais simples quando o time descreve primeiro o problema sem mencionar framework.
Se o requisito é controlar um processo de negócio com fases, aprovações, falhas e retomadas, LangGraph costuma encaixar bem. Se a maior parte do valor está em uma coleção de agentes e Teams servidos como plataforma, Agno merece uma avaliação séria. Se o domínio já está organizado em especialistas com papéis e tarefas, CrewAI pode reduzir bastante a quantidade de estrutura necessária para representar essa colaboração.
Quando faz sentido combinar#
Há casos em que os dois tipos de problema realmente coexistem. Um processo de concessão de crédito pode ser um workflow global stateful e, dentro da etapa de análise, existir uma equipe de especialistas. Nesse caso, um exemplo de composição possível é:
Ampliar ↗A mesma posição poderia ser ocupada por um Agent ou Team do Agno. O ponto relevante é que o componente interno devolve um resultado ao workflow principal e não mantém uma segunda versão do status global do processo.
Eu seria mais cauteloso com uma cadeia em que LangGraph chama um CrewAI Flow, que por sua vez chama um Agno Workflow, todos com persistência e retry próprios. Essa composição pode ser justificável em circunstâncias específicas, especialmente quando cada runtime é um serviço independente já existente, mas o custo operacional cresce rápido: lifecycle, schema, observabilidade, versionamento, recuperação e semântica de falha precisam ser entendidos em todas as fronteiras.
Há projetos em que eu não começaria com nenhum dos três#
Também vale considerar a solução mais simples: uma aplicação que faz uma chamada de modelo, consulta duas tools e executa um retrieval talvez seja melhor servida por código de aplicação convencional, um client de modelo, contratos tipados e estado explícito. Frameworks agentic têm valor quando resolvem uma complexidade que realmente existe; adotá-los apenas porque o projeto usa LLM pode antecipar problemas que ainda não apareceram.
Hoje, se eu tivesse que escolher, tentaria responder três perguntas:
qual parte do sistema precisa de estado durável
como o negócio descreve a colaboração entre componentes
qual runtime terá autoridade sobre a execução global.
Essas respostas normalmente reduzem bastante o espaço de decisão. Só depois compararia ergonomia, integrações, maturidade operacional e conhecimento do time.
Foi também por isso que acrescentei CrewAI ao repositório de exemplo desta série. O mesmo SpecialistRequest pode ser atendido por um agente Agno ou por um CrewAI Crew sem alterar o LangGraph. O experimento ajuda a separar duas decisões que frequentemente aparecem misturadas: qual framework implementa uma capability e qual componente possui a máquina de estados do produto.