Roteamento de Agentes: como Skills, CoT e RAG transformam um LLM em um sistema que decide

Quando um agente de IA recebe uma solicitação, a primeira pergunta não é "qual resposta dar?" — é "o que fazer com isso?". Essa decisão — rotear a solicitação para o caminho cognitivo correto — é o coração de qualquer sistema agêntico real. E ela depende de três peças que, juntas, formam uma arquitetura de raciocínio: Skills, Chain of Thought e RAG.

Entender como essas três peças se articulam é entender por que alguns sistemas de IA parecem inteligentes e outros apenas parecem sofisticados. A diferença não está no modelo de linguagem. Está na arquitetura ao redor dele.

O problema que o LLM sozinho não resolve

Um modelo de linguagem grande é, em essência, uma máquina de completar texto. Dado um contexto, ele produz a continuação mais provável. Isso é extraordinariamente poderoso — mas tem um limite fundamental: o modelo não sabe o que fazer. Ele sabe o que dizer.

Coloque diante de um LLM uma solicitação corporativa complexa — digamos, uma contestação de sinistro com documentos anexados, histórico de apólice e cláusulas específicas — e ele vai produzir uma resposta coerente. Mas coerente não é o mesmo que correto, e correto não é o mesmo que executado. O modelo não abre o sistema. Não aciona o perito certo. Não aplica a cláusula exata. Não registra a decisão com rastreabilidade.

O problema é estrutural: um LLM sem arquitetura ao redor trata todas as solicitações da mesma forma — produz texto. Uma contestação de sinistro, uma solicitação de reembolso, um pedido de informação sobre apólice, uma notificação de fraude: para o modelo, tudo vira texto de saída. Para uma operação real, cada uma dessas situações exige um caminho de ação completamente diferente, com sistemas diferentes, validações diferentes, responsáveis diferentes.

Para transformar capacidade linguística em operação real, você precisa de roteamento. E roteamento precisa de estrutura. É aí que entram Skills, CoT e RAG.

Skills: o vocabulário executável do agente

Uma Skill é a unidade de capacidade de um agente. Mas ela é mais do que uma função ou uma ferramenta disponível no menu — ela é uma especificação estruturada que define quatro dimensões ao mesmo tempo:

O conjunto de skills disponíveis para um agente é o seu vocabulário executável — o repertório de ações que ele pode tomar no mundo. Um agente sem skills bem definidas é um orador eloquente sem nada para fazer. Um agente com skills bem definidas tem capacidade de ação estruturada.

Essa distinção é crucial. Uma skill não é equivalente a uma chamada de API. É o conjunto de raciocínio que decide se e como chamar aquela API — com qual parâmetro, verificando qual condição antes e validando qual resultado depois. A skill é o que impede o agente de executar a ação certa na situação errada.

Um sistema de agentes maduro pode ter dezenas de skills: analisar documento, verificar fraude, calcular indenização, notificar cliente, escalar para perito, registrar no sistema. Cada uma com fronteiras claras. O roteamento decide qual delas invocar a cada momento — e essa decisão precisa de raciocínio estruturado. É o que o Chain of Thought fornece.

Chain of Thought: não é um truque de prompt, é uma estrutura de raciocínio

O Chain of Thought (CoT) ficou famoso como a técnica de pedir ao modelo para "pensar passo a passo". Mas reduzir CoT a um modificador de prompt é perder o que há de mais poderoso nele.

Em sua forma mais profunda, o Chain of Thought é a estrutura do raciocínio do agente — o esquema de perguntas que ele percorre para transformar uma situação ambígua em uma decisão fundamentada. E esse esquema não deve ser genérico. Deve ser moldado ao domínio.

Pense na diferença entre dois raciocínios. O primeiro, genérico: "A solicitação menciona dano em veículo, então vou usar a skill de análise de sinistro." O segundo, estruturado: "A solicitação menciona dano em veículo. A apólice está ativa? Sim. O tipo de dano está coberto? Preciso verificar. As imagens foram anexadas? Sim, três. O histórico do cliente indica algum padrão de fraude? Não. Grau de completude da informação: 85%. Skill aplicável: Analisar Laudo de Dano. Pré-condições satisfeitas: sim." O segundo é qualitativamente superior — não porque o modelo é mais capaz, mas porque o raciocínio seguiu um esquema.

Considere o que acontece quando um agente recebe uma solicitação. Antes de selecionar uma skill, o CoT bem estruturado percorre:

• →Desambiguar a intenção: o que exatamente está sendo pedido? Há ambiguidade? Há informação faltando que bloqueie a execução?
• →Contextualizar: qual é o estado atual do mundo relevante para esta solicitação? Que histórico existe? Há condicionantes ativos?
• →Identificar a skill aplicável: dadas a intenção e o contexto, qual caminho de ação é o mais apropriado? Há skills concorrentes? Qual tem prioridade?
• →Verificar pré-condições: a skill selecionada pode ser executada agora? Há restrições, validações ou autorizações necessárias que ainda não foram satisfeitas?
• →Antecipar consequências: qual é o resultado esperado? O que fazer se algo sair diferente? Quando escalar para humano?

Esse percurso — do input à decisão — é o Chain of Thought funcionando como mecanismo de roteamento. Cada passo filtra e qualifica a decisão. O resultado não é apenas "skill X foi escolhida", mas uma cadeia de raciocínio auditável que explica por quê aquela skill e não outra.

Isso tem uma implicação que vai além da performance: tem a ver com governança. Em operações corporativas, não basta que o agente decida corretamente — é preciso que a decisão seja explicável, rastreável e auditável. O CoT é a trilha de auditoria embutida no processo de raciocínio. Quando um agente precisa ser questionado — por um auditor, por um regulador, por um gestor — o CoT é o que permite dizer: "aqui está cada passo do raciocínio que levou a esta decisão."

Mas há uma limitação: o CoT é tão bom quanto o contexto sobre o qual raciocina. Se o agente não tem acesso ao conhecimento específico e atualizado do domínio, o raciocínio mais estruturado do mundo ainda pode chegar à conclusão errada. É aí que o RAG entra.

RAG: a memória que o modelo não tem — e por que ela muda o roteamento

O Retrieval-Augmented Generation (RAG) — geração aumentada por recuperação — resolve um problema fundamental de qualquer LLM: o modelo foi treinado em dados que têm uma data de corte e que, de todo modo, nunca incluíram o conhecimento específico da sua empresa, dos seus processos, dos seus clientes.

O RAG funciona assim: antes de raciocinar sobre uma solicitação, o agente faz uma busca numa base de conhecimento externa e traz para o contexto as informações relevantes. Só então raciocina. Em vez de depender exclusivamente do que aprendeu no treinamento, o agente passa a ter acesso a um repositório vivo — que pode ser atualizado sem retreinar o modelo.

Mas no contexto do roteamento, o RAG tem um papel que vai além de "dar mais contexto ao modelo". Ele é a peça que fundamenta o raciocínio do CoT em conhecimento específico e atual.

Sem RAG, quando o CoT pergunta "qual skill se aplica aqui?", ele responde com base no que aprendeu no treinamento — conhecimento genérico, potencialmente desatualizado, definitivamente não específico ao domínio. Com RAG, essa mesma pergunta é respondida com base no conhecimento recuperado: as políticas vigentes desta empresa, os casos análogos desta operação, as restrições regulatórias atuais deste setor, os parâmetros de negócio que mudam trimestre a trimestre.

Há, porém, uma sutileza crítica sobre o RAG que raramente é discutida: o que você recupera depende de como o seu conhecimento está estruturado. Um banco de documentos planos — parágrafos de texto sem relação entre si — produz recuperações fragmentadas. O agente recebe pedaços de contexto sem entender como eles se relacionam. O CoT tenta raciocinar sobre fragmentos. O resultado é uma decisão frágil.

Quando o conhecimento está organizado com relações explícitas — hierarquias, dependências, equivalências, histórico — o RAG recupera não apenas o fragmento relevante, mas a rede de conhecimento ao redor dele. O agente raciocina sobre contexto completo, não sobre pedaços isolados. E isso, como veremos, conecta diretamente com o que torna a tríade tão poderosa.

A tríade em ação: como os três se articulam

Isoladamente, cada um desses elementos tem valor. Juntos, eles formam um sistema de roteamento que é qualitativamente diferente da soma das partes. A chave está em entender que cada peça tem uma responsabilidade específica — e nenhuma substitui a outra.

O RAG não raciocina — ele recupera o substrato certo para o raciocínio acontecer. O CoT não executa — ele percorre o esquema de perguntas que leva à decisão correta. A Skill não improvisa — ela aplica o procedimento certo no contexto certo, com as verificações certas. Quando os três funcionam juntos, o resultado é um agente que age com precisão e com explicação.

O fluxo de uma decisão agêntica bem arquitetada funciona assim:

A estrutura do conhecimento como espinha dorsal

Há um insight que raramente aparece nas discussões técnicas sobre RAG e CoT: a qualidade do roteamento é, em última instância, função da qualidade da estrutura do conhecimento.

Pense assim: o RAG vai buscar na sua base de conhecimento. O CoT vai raciocinar sobre o que o RAG trouxe. Se a base de conhecimento for um amontoado de documentos — PDFs escaneados, e-mails exportados, planilhas coladas como texto — o RAG vai recuperar ruído junto com sinal, e o CoT vai raciocinar sobre um contexto poluído.

O que significa "conhecimento estruturado" aqui? Não basta ter documentos bem escritos. Estrutura significa que os conceitos têm definições precisas, que as relações entre conceitos estão explícitas (este produto depende desta regulação, que foi atualizada nesta data, e está relacionada a estes casos históricos), e que o conhecimento forma uma rede navegável — não um arquivo plano.

Quando o conhecimento tem essa organização, ele passa a fazer três coisas ao mesmo tempo:

Isso explica por que dois sistemas que usam o mesmo modelo de linguagem, o mesmo framework de agentes e até as mesmas skills podem produzir resultados radicalmente diferentes. A diferença não estava no modelo — estava em como o conhecimento estava organizado para alimentar o raciocínio. A estrutura do conhecimento é silenciosa, mas é ela que determina o teto de qualidade do sistema.

Por que roteamento agêntico é diferente de roteamento tradicional

Software tradicional roteia por regras explícitas: se campo A contém valor X, siga o fluxo B. Isso funciona bem para processos completamente previsíveis e estáveis. O problema é que o mundo corporativo não é assim — especialmente nas margens, nos casos excepcionais, nas situações que nunca foram antecipadas quando o sistema foi desenhado.

Sistemas baseados em regras quebram exatamente onde o negócio mais precisa de inteligência: nas exceções. Um sinistro com cobertura parcial e documentação incompleta. Um cliente com dois contratos e histórico de contestação. Uma solicitação que deveria seguir o fluxo A, mas tem uma característica específica que muda tudo. O fluxo rígido trava. O agente raciocina.

O roteamento agêntico é fundamentalmente diferente porque opera em três dimensões simultaneamente:

• Semântica:o agente entende a intenção, não apenas o padrão de texto. Uma solicitação pode ser formulada de cem formas diferentes e ainda assim rotear para a mesma skill — ou formulada de forma semelhante e rotear para skills diferentes dependendo do contexto. "Preciso revisar minha cobertura" e "quero atualizar minha apólice" roteiam para a mesma skill. "Meu carro foi roubado ontem" e "meu carro foi amassado ontem" roteiam para skills diferentes, apesar da estrutura linguística similar.
• Contextual:a mesma solicitação pode rotear diferente dependendo do histórico, do estado atual do sistema, das políticas vigentes, do perfil de quem solicitou. Uma pergunta sobre cobertura de dano atmosférico roteia diferente para um cliente com apólice básica do que para um com apólice premium, mesmo que a pergunta seja idêntica. O roteamento é dinâmico, não estático.
• Adaptativo:quando uma situação não tem precedente exato, o agente não trava — ele raciocina por analogia, recupera o caso mais próximo via RAG, aplica princípios gerais via CoT e, quando necessário, escala para o humano curador com o contexto completo do raciocínio já organizado. O humano recebe a situação pré-digerida, não o problema bruto.

Isso tem uma implicação operacional profunda: sistemas agênticos bem arquitetados ficam mais precisos com o tempo. Cada decisão tomada, cada caso tratado, cada exceção resolvida enriquece a base de conhecimento que alimenta o RAG. O CoT de amanhã raciocina sobre um contexto mais rico do que o de hoje. O sistema não precisa de retreinamento para melhorar — precisa de operação.

Implicações para quem está desenhando sistemas agênticos

Se você está construindo ou avaliando uma arquitetura de agentes, as perguntas certas a fazer não são "qual modelo vamos usar?" ou "qual framework de agentes?". Essas são perguntas táticas — importantes, mas secundárias. As perguntas estratégicas são as que dizem respeito às três dimensões que vimos:

A maioria dos projetos de IA que falha em produção não falha por limitação do modelo. Falha porque as skills são vagas, o CoT é genérico e a base de conhecimento é um dump de documentos. O modelo faz o que pode com o que tem. E o que tem, nesses casos, não é suficiente.

O roteamento como expressão da inteligência arquitetural

Há uma inversão de perspectiva importante aqui. Durante anos, a conversa sobre IA focou no modelo — sua capacidade, seu tamanho, seus benchmarks. O modelo era o produto. Tudo mais era acessório.

Sistemas agênticos em produção revelam que essa perspectiva estava errada. O modelo é o motor, mas motores sozinhos não dirigem. O que dirige é a arquitetura ao redor: como o conhecimento está estruturado para ser recuperado, como o raciocínio está esquematizado para chegar à decisão certa, como as capacidades estão especificadas para executar com precisão.

Skills, CoT e RAG não são features de um sistema de IA — são as dimensões fundamentais de qualquer agente que precisa tomar decisões reais, em contextos reais, com consequências reais. Cada um resolve um problema diferente: Skills definem o vocabulário de ação; CoT garante que o raciocínio chegue à decisão certa; RAG garante que o raciocínio seja feito sobre o contexto certo. Quando bem articuladas, as três transformam um LLM — que sabe muito mas não sabe o que fazer — em um sistema que percebe, raciocina e age com precisão mensurável e rastreável.

Essa é a distinção que separa projetos de IA que entram em produção e escalam daqueles que ficam eternamente em piloto. Não é o modelo. É a arquitetura. E a arquitetura começa pela clareza sobre o que cada peça faz — e o que ela não faz.