LinkedIn descreve evolução dos agentes de IA: de chains a código executável

A InfoQ publicou nesta segunda-feira (26/10) um artigo que organiza em três gerações a forma como times de engenharia vêm construindo agentes de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI →: chains, grafos e, mais recentemente, harnesses baseados em código. O texto é assinado por Karthik Ramgopal e faz parte da série "Agentic AI Architecture" do veículo, com revisão de Rafał Gancarz. O recorte central: sair do "melhor esforço" probabilístico para sistemas com garantias de engenharia tradicional, usando casos reais do LinkedIn como ilustração.

Dos chains frágeis aos grafos com controle explícito

A primeira geração descrita no artigo é a dos chains: sequências lineares de prompts em que a saída de uma etapa alimenta a próxima. Segundo o autor, um dos primeiros agentes generativos do LinkedIn usava uma cadeia fixa de três passos construída com o framework LangChain, dividida em roteamento (classificar a pergunta e escolher o especialista certo), recuperação (buscar dados via Bing ou APIs internas do LinkedIn) e geração (sintetizar a resposta final).

Essa arquitetura é rápida de construir, mas frágil: um erro na etapa de roteamento se propaga sem nenhum mecanismo de detecção ou recuperação. O artigo descreve isso como o padrão "best-effort" dos primeiros produtos agentic, em que os 80% iniciais da experiência saíam rápido, mas fechar os últimos 20% exigia rodadas extensas de avaliação e ajuste de prompt.

A resposta a essa fragilidade foram os grafos: nós representam tarefas (chamada de LLM, invocação de ferramenta, validação) e arestas controlam o fluxo, permitindo ramificação condicional, paralelismo e retentativas. No LinkedIn, essa camada foi implementada sobre o LangGraph e trouxe quatro capacidades que o artigo lista como centrais:

• Execução condicional, com roteamento e reroteamento baseado em resultados intermediários;
• Retentativas e fallbacks para recuperação graciosa de falhas;
• Gerenciamento de estado estruturado além de texto solto;
• Validação explícita (schema, regras de negócio ou modelos secundários) antes de confiar na saída do LLM.

Essa estrutura também abriu espaço para sistemas multiagente com um orquestrador de nível superior, exigindo protocolos de comunicação assíncrona entre agentes como A2A e ACP (que depois se fundiram em A2A). No LinkedIn, essa orquestração foi construída reaproveitando o sistema de mensagens já existente da plataforma, com entrega garantida em ordem FIFO. O artigo cita o Hiring Assistant, primeiro agente de IA do LinkedIn voltado a recrutadores, como produto que nasceu dessa arquitetura em grafo.

Código como peça central: sandbox, testes e validação

A terceira geração trata código, e não prompt, como o meio principal de raciocínio do agente. Em vez de pedir ao modelo para "pensar em voz alta" sobre um problema complexo, o harness gera código, executa em um sandbox isolado e refina o resultado em loop até passar nos critérios de correção.

A diferença prática, segundo o artigo, é que texto gerado por LLM é probabilístico e, antes de validação, não é confiável; código, por outro lado, é determinístico: ou compila e entrega o resultado certo, ou falha de forma explícita. Esse ciclo de falha/sucesso binário é o que, na visão do autor, melhora de forma mais dramática a confiabilidade do sistema.

O artigo descreve quatro componentes como obrigatórios nessa arquitetura:

Um caso de produção: o agente de análise interna do LinkedIn

O LinkedIn usa esse padrão em uma ferramenta interna que permite a desenvolvedores, gerentes de produto, cientistas de dados e até pessoal de operações de negócio fazer perguntas analíticas em linguagem natural e receber respostas baseadas em dados agregados da plataforma. O agente traduz a pergunta em uma combinação de SQL↳SQL64 conteúdosSQL Server – Como evitar SQL Injection?Data · mai 2019Azure SQL DB Managed InstanceData · abr 2019SQL Server – Como evitar SQL Injection? Pare de utilizar Query Dinâmica como EXEC(@Query)Data · abr 2019Ver tudo em Data → declarativo e Python imperativo, executa contra uma amostra de dados, valida a saída contra restrições estritas de privacidade e governança, e itera em loop até atender todos os critérios.

Segundo o artigo, a abordagem baseada em código reduziu o tempo de lançamento em comparação com a construção manual de prompts, ferramentas e grafos de fluxo, além de tornar o sistema mais auditável e reproduzível, já que cada execução deixa um rastro de código e teste que pode ser inspecionado depois.

O que o autor recomenda como prática mínima

Independentemente do estágio da arquitetura, o artigo lista quatro princípios como separadores entre sistemas robustos e frágeis:

1. Tratar a saída do LLM como entrada não confiável, aplicando checagem de schema, regras de negócio ou modelos secundários antes de qualquer decisão downstream;
2. Desacoplar planejamento de execução, deixando o modelo propor um plano mas executando-o dentro de um framework de software controlado;
3. Investir em observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps →, capturando estado em cada etapa, traces de execução e resultados de validação, com mascaramento de dados sensíveis;
4. Construir para melhoria contínua, com loops de feedback que capturam falhas e alimentam evolução de prompt, política e memória do sistema.

Qual abstração escolher, e o que isso muda para quem desenvolve no Brasil

O artigo é direto sobre quando usar cada camada. Chains bastam para tarefas lineares e estreitas, como rascunho de resposta de suporte, resumo de documento ou extração de dados estruturados de entradas previsíveis, porque minimizam chamadas de modelo e overhead de orquestração. Grafos entram quando o fluxo exige ramificação condicional, retentativa ou invocação de ferramentas, como resolução de atendimento em múltiplas etapas ou automação de TI corporativa. Harnesses de código se justificam onde precisão e verificação são críticas, como agentes de engenharia de software, análise financeira ou validação de documento jurídico, áreas em que a saída pode ser testada, compilada ou validada formalmente.

O princípio fundamental é simples: use o sistema menos complexo que resolva o problema de forma confiável.

The fundamental principle is simple: Use the least complex system that reliably solves the problem.Karthik Ramgopal, autor do artigo e engenheiro de IA do LinkedIn

Para quem constrói agentes de IA por aqui, o recorte prático é direto: a tentação de pular direto para arquiteturas de grafo ou harness de código, por serem o assunto do momento, custa dinheiro e latência sem necessariamente melhorar o resultado de negócio. O artigo reforça que organizações de engenharia fortes não vencem maximizando sofisticação arquitetural, vencem otimizando capacidade por dólar gasto. Antes de desenhar um grafo em LangGraph ou um sandbox de execução de código, vale medir se o problema realmente exige mais do que uma cadeia linear de prompts validada com schema checks na saída.

Também muda o papel de quem programa esses sistemas. O texto descreve uma transição do "Prompt Designer" para o "System Architect": nos primeiros chains, o diferencial estava na habilidade artesanal de escrever o prompt certo; em grafos e harnesses de código, o foco migra para engenharia de software de verdade, desenho de fluxo de execução, gestão de estado e dependências, e construção de mecanismos de validação e recuperação. É esse deslocamento, mais do que qualquer framework específico, que o artigo da InfoQ documenta como a mudança estrutural na forma de construir IA em produção.

Fonte: InfoQ