Um Agente por Skill: Por Que a Composição Vence o Generalista

Toda vez que um time começa a construir algo agêntico, a primeira ideia que aparece é sempre a mesma: um agente único, com acesso a tudo, capaz de pesquisar, escrever código, revisar, documentar e se comunicar com o resto do sistema. Faz sentido do ponto de vista de esforço inicial. É mais rápido montar um prompt gigante e um conjunto amplo de ferramentas do que parar para desenhar fronteiras entre responsabilidades diferentes.

O problema é que essa comodidade cobra um preço depois, e a indústria já está enxergando isso. A Gartner projeta que, até 2027, um terço das implementações de IA agêntica vai combinar agentes com skills diferentes, em vez de depender de um único agente generalista fazendo de tudo. Não é uma previsão sobre estética de arquitetura, é reconhecer que o generalista escala mal quando o sistema cresce e as consequências de erro sobem.

Neste post eu quero fazer o caso técnico para a composição: por que um agente especializado por skill tende a ser mais confiável, mais fácil de debugar e mais fácil de conceder o escopo certo de permissão do que um agente generalista. E também quero ser honesto sobre quando o generalista ainda é a escolha certa, porque composição não é bala de prata.

A Tentação do Agente Que Faz Tudo

O agente generalista é sedutor porque imita a forma como enxergamos um bom profissional sênior: alguém que entende o contexto todo e resolve o que aparecer na frente. Só que essa analogia esconde uma diferença importante. O sênior humano tem anos de calibração tácita sobre quando parar, escalar ou pedir ajuda. O agente generalista não tem esse freio; ele executa a instrução com o conjunto de ferramentas disponível, que tende a crescer sem controle conforme o time empilha casos de uso novos.

Eu já vi esse padrão se repetir em times diferentes. Alguém cria um agente para revisar código, depois pede para ele rodar testes, depois adiciona acesso ao banco "só para consultar", depois integra com o Slack para postar resultado. Em seis meses, o revisor de código virou um agente com permissão de leitura em produção, capacidade de escrever mensagens externas e um prompt de duas mil linhas tentando explicar quando cada coisa se aplica.

O sintoma mais claro de que isso deu errado é o comportamento imprevisível. Com muitas skills misturadas na mesma sessão, o agente passa a aplicar contexto errado no lugar errado: usa o tom de revisão de código numa mensagem para o cliente, ou tenta "corrigir" um dado que devia apenas reportar. Isso não é falha de modelo, é falha de design — você pediu para um único ator carregar responsabilidades que deveriam estar separadas.

Existe hoje um debate técnico crescente sobre o que exatamente separa um agente, um sub-agente, uma skill e uma tool. Não é debate acadêmico por vaidade: ele existe porque a comunidade sentiu na pele que composição malfeita, com skills e responsabilidades misturadas no mesmo agente, é fonte comum de comportamento imprevisível. Quando você não sabe onde termina a responsabilidade de um componente e começa a de outro, já perdeu a capacidade de prever o que o sistema vai fazer.

Por Que Composição Ganha em Confiabilidade

A alternativa é simples de descrever e mais trabalhosa de implementar: um agente por skill, cada um com escopo estreito, e uma camada de orquestração que decide qual agente entra em cada etapa. Um pesquisa, outro escreve, outro revisa, outro documenta, cada um recebendo apenas o contexto e as ferramentas necessárias para a sua fatia do trabalho.

A confiabilidade melhora porque cada agente tem uma superfície de comportamento muito menor para errar. Um agente de revisão de código só precisa ser bom em uma coisa, e o prompt dele pode ser afiado nessa única tarefa sem competir com instruções de outras funções. Isso reduz os casos em que o modelo "confunde papéis", porque a sessão simplesmente não tem contexto nem ferramenta para operar fora do seu escopo.

O debug também fica mais tratável. Num agente generalista, você investiga um prompt enorme, um histórico de ferramentas variadas e um contexto acumulado de múltiplas responsabilidades para entender onde a decisão nasceu. Num agente especializado, o espaço de busca é muito menor: você já sabe que aquele agente só fazia uma coisa, então o problema está nessa fatia estreita de comportamento — a mesma lógica de microsserviços aplicada a comportamento de IA.

E tem o argumento de permissão, que para mim é o mais forte dos três. Dar escopo certo de acesso é fácil quando o agente faz uma coisa só: um agente que só lê código para revisar não precisa de permissão de escrita em produção, um agente que só gera release notes não precisa de acesso ao banco de clientes. Dar permissão a um generalista, em contraste, força você a somar a união de tudo que ele pode eventualmente precisar, o que quase sempre resulta em superprivilégio.

O Caso da Fountain: Composição em Produção

Um bom teste para qualquer argumento técnico é ver se ele se sustenta fora do papel, e o caso da Fountain, empresa de recrutamento, é um exemplo concreto de composição em produção real. Em vez de um agente único cobrindo todo o funil de contratação, a Fountain adotou orquestração hierárquica multiagente, com agentes especializados por etapa do processo.

A lógica de divisão faz sentido assim que você olha o funil: triagem de currículo é uma tarefa, agendamento e comunicação com candidato é outra, verificação de documentos é outra, onboarding é outra ainda, cada uma com regras, riscos e ferramentas próprias. Um agente de triagem não precisa de acesso aos sistemas de onboarding, e um agente de onboarding não precisa reavaliar critérios já decididos etapas atrás.

Os números que saíram dessa reestruturação justificam o esforço: triagem 50% mais rápida, onboarding 40% mais rápido, conversão de candidatos duas vezes maior, e staffing caindo de semanas para menos de 72 horas. Isso não veio de um modelo mais inteligente, veio de decompor um processo grande em etapas com donos claros, orquestradas por uma camada que sabe passar o bastão no momento certo.

O paralelo com times humanos é direto, e eu já escrevi sobre isso quando falei de topologia de agentes e a lei de Conway aplicada a times técnicos: a topologia de agentes especializados que funcionou na Fountain espelha a topologia de times especializados que qualquer organização madura de recrutamento já teria adotado com pessoas. A composição de agentes não é ideia nova sobre IA; é a mesma lição de sempre sobre dividir trabalho grande em unidades que cabem na cabeça de quem executa, só que aplicada a um executor diferente.

O Que Muda Para Quem Constrói

Um efeito colateral pouco discutido da composição é que ela muda a habilidade que passa a importar para o tech lead. Num mundo de agente generalista, a tentação é competir em quem escreve mais prompt, mais código, mais instrução dentro de um único bloco monolítico. Num mundo multiagente, isso deixa de ser o gargalo: o que importa é escrever specs claras para cada agente especializado, decompor o problema em unidades que fazem sentido isoladamente e verificar o output de cada etapa antes de liberá-lo para a próxima. É trabalho de arquitetura, não de digitação, e é o que separa times que escalam composição com sucesso dos que voltam correndo para o generalista único depois de um trimestre de dor.

Essa mudança conecta com a discussão sobre quais capacidades vale a pena empacotar como skill reutilizável. Eu já tratei desse assunto quando escrevi sobre quais agent skills um time deveria versionar primeiro; aquele post foi sobre escolher as skills certas para adotar. Este é sobre a lógica seguinte: compor essas skills em agentes distintos com responsabilidade clara, em vez de empilhar todas dentro de um único agente que carrega tudo ao mesmo tempo.

Não é coincidência que essa preocupação esteja crescendo como termo de busca técnico. A categoria de orquestração e composição de agentes saiu de recurso de nicho no LangChain em 2024 para um termo de busca nos Estados Unidos com cerca de 480 buscas mensais e crescimento de mais de 175% ano a ano em 2026 — sinal de que times já buscam ativamente como compor agentes na prática, não só discutir a ideia em teoria.

Quando o Generalista Ainda Faz Sentido

Dito tudo isso, seria desonesto apresentar composição como resposta universal. Existem situações em que o generalista continua sendo a escolha certa.

A primeira é escala pequena e escopo temporário. Se você está prototipando uma ideia, validando se um fluxo agêntico resolve um problema antes de investir em arquitetura, um agente generalista com poucas ferramentas é mais rápido de montar e mais barato de manter enquanto ainda não se sabe se o problema vale o investimento. Composição prematura, nesse estágio, é custo de engenharia sem retorno correspondente.

A segunda é quando as tarefas compartilham o mesmo contexto e não têm fronteira natural de responsabilidade. Um agente que ajuda um desenvolvedor a explorar uma base de código, indo de leitura para pergunta para sugestão na mesma sessão contínua, se beneficia de contexto compartilhado. Forçar uma fronteira artificial ali só para seguir a moda de composição cria overhead sem ganho real de confiabilidade.

A terceira é maturidade organizacional. Composição exige que alguém defina, mantenha e revise a orquestração entre agentes, trabalho contínuo que um time pequeno pode não ter capacidade de sustentar. Nesse caso, múltiplos agentes mal coordenados são piores que um generalista único, imperfeito, mas que alguém entende de ponta a ponta.

Conclusão

O caso para composição não é ideológico, é estatístico e é operacional. A projeção da Gartner de que um terço das implementações agênticas vai combinar agentes com skills diferentes até 2027 reflete times descobrindo, na prática, que confiabilidade, debug e permissão ficam mais tratáveis quando você divide responsabilidade em vez de empilhar tudo num único ator. O case da Fountain mostra que esse ganho não é teórico: triagem mais rápida, onboarding mais rápido, conversão maior e staffing cortado de semanas para menos de 72 horas vieram de decompor um processo em etapas com agentes especializados, exatamente como aconteceria com um time humano bem desenhado.

O que muda para quem lidera engenharia é a habilidade que passa a valer ouro. Não é mais quem escreve o prompt mais longo; é quem escreve a spec mais clara, decompõe o trabalho na fronteira certa e verifica o output antes de deixá-lo seguir adiante. Quem entender isso primeiro vai colher sistemas mais previsíveis. Quem insistir no agente que faz tudo vai continuar debugando um prompt de duas mil linhas até descobrir, do jeito difícil, por que a composição existe.

Fontes:

Um Agente por Skill: Por Que a Composição Vence o Generalista

Um Agente por Skill: Por Que a Composição Vence o Generalista

A Tentação do Agente Que Faz Tudo

Por Que Composição Ganha em Confiabilidade

O Caso da Fountain: Composição em Produção

O Que Muda Para Quem Constrói

Quando o Generalista Ainda Faz Sentido

Conclusão

Receba os artigos mais relevantes da semana, sem quebrar seu ritmo de leitura

eltonjose