Tool vs. Skill vs. Sub-agent: O Espectro de Delegação e sua Governança

De todas as fronteiras traçadas pelo glossário de agentes, aquela entre tools, skills e sub-agents é a mais tênue — o próprio glossário admite que esse limite varia entre frameworks. No entanto, o espectro por trás disso é estável e vale a pena ser projetado com cuidado: uma tool é uma ação, uma skill é um procedimento empacotado, e um sub-agent é um delegado que raciocina. Essas são três formas distintas de delegação e — a parte que a maioria das arquiteturas omite — três problemas de governança diferentes. Autorizar uma tool, versionar uma skill, atribuir uma identidade a um sub-agent: errar o nível significa governar um delegado de raciocínio como se fosse uma chamada de função, que é exatamente como surgem as surpresas de raio de impacto (blast radius).

Ingrid, uma engenheira staff, estava revisando um agente antes de enviá-lo para produção quando encontrou uma linha na lista de tools que a fez parar: uma das "tools" não era uma tool. Nove entradas eram chamadas de função legítimas — consultar o banco de dados de pedidos, enviar uma mensagem no Slack. A décima, "resolve-customer-issue", era um segundo agente inteiro disfarçado de tool: ele tinha seu próprio prompt, seu próprio orçamento de chamadas de modelo, seu próprio acesso a tools e raciocinava por até quinze etapas antes de retornar uma string. Ele havia herdado as permissões do agente pai integralmente — o modo de falha que uma configuração governada evita ao limitar o escopo do delegado explicitamente, em vez de permitir que ele herde as concessões do pai —, aparecia nos traces como uma única chamada opaca e tinha sido revisado em termos de segurança apenas como "uma tool" — o que significa que não passou por uma revisão de fato. Nada nele era malicioso. Tudo nele estava categorizado incorretamente.

A categorização incorreta é o modo de falha que esse vocabulário existe para evitar. O glossário de agentes da Hugging Face — cujos termos esta série adota, mapeados para infraestrutura em nosso artigo principal — separa esses três conceitos com clareza, embora admita que os frameworks costumam confundi-los. Este artigo aborda o espectro nível por nível: o que cada um representa, quando utilizá-los e a superfície de governança que cada um exige. Porque a décima entrada de Ingrid não era um problema de nomenclatura. Era um problema de delegação submetido ao regime de governança errado.

1. O Espectro Definido

Uma tool é uma ação. O modelo emite uma requisição estruturada — chame esta função com estes argumentos — e o harness a executa: uma chamada de API, uma consulta ao banco de dados, um comando shell, uma busca na web. O resultado retorna para o contexto e o loop continua. A tool não raciocina; ela executa. Tudo o que o modelo sabe sobre ela é sua descrição, e a chamada em si é um evento discreto e inspecionável com argumentos na entrada e um resultado na saída.

Uma skill é um conhecimento empacotado. Enquanto uma tool significa "execute este comando", uma skill agrupa o que é necessário para atingir um objetivo — investigar esta classe de bug, gerar este tipo de relatório — geralmente na forma de instruções e procedimentos estruturados (o padrão SKILL.md) carregados no contexto do agente sob demanda. Uma skill não executa nada por si só; ela molda a forma como o agente utiliza as tools de que dispõe. Trata-se de um scaffold tornado portável e reutilizável entre diferentes agentes.

Um sub-agent é um delegado. O agente chamador delega uma subtarefa para outro agente — um que possui seu próprio modelo, seu próprio scaffold, sua própria janela de contexto e possivelmente suas próprias tools —, o qual raciocina sobre o trabalho de forma independente e retorna um resultado. O pai recebe o resultado em vez de gerenciar cada etapa intermediária, da mesma forma que um gestor não digita pelo seu liderado. Essa opacidade é o propósito central e, ao mesmo tempo, o problema de governança. A distinção em relação a uma tool é exatamente aquela com a qual Ingrid se deparou: uma tool executa; um sub-agent decide, podendo ele próprio utilizar tools e falhar de formas imprevisíveis que uma função não permitiria.

2. Escolhendo um Nível: o Menor que Resolve o Problema

O espectro troca controle por capacidade à medida que se sobe por ele. Uma tool é maximamente legível — seu comportamento é a sua própria implementação e sua invocação é um evento único e auditável — e minimamente capaz: ela lida exatamente com aquilo para o qual foi programada. Um sub-agent é maximamente capaz — pode absorver ambiguidade, adaptar-se no meio da subtarefa e se recuperar de imprevistos — e minimamente legível: seu comportamento surge de um modelo raciocinando em um contexto invisível a partir do pai. Uma skill fica no meio termo: ela eleva a competência do agente em uma classe de tarefas sem adicionar um novo principal delegado.

Isso estabelece uma heurística de seleção direta: escolha o menor nível que resolva o problema. Se a subtarefa for determinística e bem especificada — busque este registro, execute estes testes —, trata-se de uma tool; envolvê-la em um sub-agent adiciona custo, latência e um modo de falha aberto sem qualquer benefício. Se a subtarefa for um procedimento que um especialista do domínio poderia documentar — triar um bug desta forma, estruturar o relatório desta maneira —, trata-se de uma skill: o próprio raciocínio do agente pai, aprimorado com know-how empacotado, sem necessidade de delegação. Reserve o sub-agent para subtarefas que exigem julgamento real com seu próprio estado de trabalho — analisar profundamente este corpus de logs, pesquisar esta questão —, onde o trabalho sobrecarregaria o contexto do pai ou exigiria um raciocínio que o pai não deveria intercalar com sua thread principal. O delegado categorizado incorretamente por Ingrid, julgado por essa heurística, era legitimamente um sub-agent; o erro nunca esteve no nível escolhido, mas sim na sua classificação de governança.

3. Tools: Governe a Chamada

Como uma tool é uma ação discreta executada, sua unidade de governança é a chamada. Três perguntas acompanham cada invocação: este chamador está autenticado, este chamador está autorizado para esta tool específica e esta chamada em particular é aceitável — cobrindo tanto argumentos de entrada (uma instrução injetada contida em um parâmetro) quanto o resultado de saída (um segredo ou PII na resposta). Essa é a superfície por chamada, e é exatamente o que um gateway MCP oferece: um registry para que os agentes alcancem apenas tools sancionadas, autenticação centralizada para que os agentes não carreguem credenciais individuais por tool, RBAC por tool e guardrails pré/pós-chamada com uma trilha de auditoria para cada execução. O MCP Gateway da TrueFoundry implementa esse nível de ponta a ponta, incluindo superfícies de tools curadas com privilégio mínimo por função via servidores MCP virtuais.

Uma observação importante sobre a camada de scaffold cabe aqui por ser uma das falhas de tools mais frequentes na prática: o modelo seleciona tools puramente com base em suas descrições, de modo que uma descrição vaga ou com sobreposições gera mau uso que nenhuma checagem por chamada conseguirá capturar — a chamada é autorizada, bem formatada, mas errada. Trate as descrições de tools como scaffold revisado e versionado, e considere que uma tool que continua sendo usada incorretamente possui um bug de documentação antes de presumir que o modelo tem uma falha de raciocínio.

4. Skills: Governe o Artefato

Uma skill não executa nada, de forma que a governança por chamada não tem onde atuar; sua unidade de governança é o artefato. As questões relevantes são proveniência e versionamento: quem escreveu este procedimento, quem o revisou, qual versão cada agente está executando e o que mudou entre as versões — porque uma skill é comportamento, e uma edição não revisada em uma skill amplamente utilizada representa uma alteração silenciosa de comportamento em todos os agentes que a carregam. O modo de falha de skills não governadas é o mesmo do "copia e cola" sem controle: procedimentos duplicados em variantes privadas, versões desatualizadas executando indefinidamente e nenhuma capacidade de responder a "quais agentes foram afetados?" quando um procedimento se mostra incorreto.

A solução é a mesma aplicada ao código: um registry. O Skills Registry da TrueFoundry trata skills como artefatos SKILL.md versionados com RBAC — publicados, revisados, com versões fixadas por agentes e carregados no contexto sob demanda, em vez de colados em cada definição. O carregamento sob demanda traz um duplo benefício: é um ganho de engenharia de contexto (o procedimento só consome espaço da janela quando relevante) e um ganho de governança (o registry sabe exatamente quais agentes utilizam qual skill e em qual versão, fornecendo uma resposta clara à pergunta "quais agentes foram afetados"). Uma skill em um registry é conhecimento institucional; uma skill na área de transferência é um rumor.

5. Sub-agents: Governe o Principal

Um sub-agent raciocina, portanto nem a chamada nem o artefato representam a unidade de governança adequada — o principal é essa unidade. Quatro propriedades tornam um sub-agent governável, e todas as quatro estavam ausentes na décima entrada de Ingrid. Identidade: o sub-agent atua como ele mesmo, e não de forma anônima dentro do pai, garantindo que suas ações sejam rastreáveis. Permissões de escopo reduzido: ele recebe apenas as tools de que sua subtarefa precisa — e não as permissões do pai por herança; um delegado de análise de logs não deve ter acesso de escrita ao sistema de pedidos herdado do pai. Recursos delimitados: seus próprios orçamentos de etapas e tokens, para que um delegado que se desvie não consuma silenciosamente a execução do pai (a preocupação com prevenção de loops abordada em nosso artigo sobre multi-agentes, um nível abaixo). Seu próprio trace: o registro do pai exibe a delegação e o resultado; o registro do sub-agent exibe as quinze etapas intermediárias — uma linha única e opaca em um trace é exatamente como um delegado classificado incorretamente se esconde.

Este é o nível em que o harness mostra seu valor, pois essas propriedades são características de tempo de execução (runtime). O Agent Harness da TrueFoundry executa sub-agents como componentes de primeira classe da sua estrutura de engenharia de contexto: cada delegado opera em uma janela de contexto isolada e devolve conclusões, não transcrições, ao pai — e cada um aparece no trace por etapa com suas próprias chamadas de modelo, chamadas de tools e custos. Delegação sem governança por principal é como as permissões de um único agente se transformam silenciosamente em um organograma de cópias não auditadas; delegação com governança é simplesmente uma boa decomposição.

6. O Eixo do Contexto: o Espectro como Instrumento de Gestão de Janela

Existe um segundo eixo que percorre todo o espectro, o qual não tem relação com segurança, mas sim com qualidade: o custo que cada nível impõe à janela de contexto do agente pai. Uma tool pré-carregada custa sua descrição a cada etapa em que permanece exposta (cada descrição de tool pré-carregada pode acompanhar a janela de contexto), além dos seus resultados à medida que chegam — razão pela qual o tratamento de resultados (truncamento, offloading) é responsabilidade do harness, e por que um agente com oitenta tools pré-carregadas pode pagar um custo fixo de contexto por todas elas, usando-as ou não. É exatamente por isso que o carregamento diferido de tools sob demanda existe. Uma skill, carregada sob demanda, não custa nada até se tornar relevante, e seu procedimento completo consome espaço apenas enquanto for necessário. Um sub-agent é o instrumento de contexto mais poderoso de todos: ele remove a subtarefa inteira para fora da janela do pai — o delegado consome seu próprio contexto limpo na investigação de quinze etapas e retorna apenas três frases.

Visto dessa forma, o espectro funciona também como um kit de ferramentas para engenharia de contexto, que é exatamente como o conjunto de engenharia de contexto do harness o trata: superfícies de tools curadas mantêm baixo o custo fixo de descrições, skills carregam procedimentos just-in-time e sub-agents isolam subtarefas extensas para que a janela do pai permaneça enxuta ao longo de execuções longas. A mesma decisão de decomposição — qual nível deve processar este trabalho — é simultaneamente uma decisão de governança e uma decisão de orçamento de janela. As arquiteturas que funcionam sem esforço são aquelas em que ambas as escolhas foram feitas intencionalmente.

7. Compondo os Níveis: Um Exemplo Prático

Os níveis se compõem, e um agente realista utiliza todos os três. Considere o agente de operações de clientes de Ingrid, reestruturado adequadamente:

Um agente, três níveis — cada um governado em sua própria superfície (ilustrativo)

A composição se lê de forma natural: tools são o que ele pode fazer, skills são o que ele sabe como fazer, o sub-agent é o que ele delega. E cada linha se conecta a um sistema de governança diferente que já sabe como tratá-la — o MCP Gateway autoriza e audita as chamadas, o Skills Registry rastreia as versões, e o harness executa o delegado com sua própria identidade, orçamento e trace. A arquitetura não consiste em três casos isolados; é um espectro único com a governança vinculada a cada nível. É isso que significa "codifique o espectro, não os rótulos" na prática: independentemente de como um framework chame esses elementos, classifique cada um pelo que ele é — ação, procedimento ou principal — e os controles corretos serão aplicados naturalmente.

8. Refatorando ao Longo do Espectro

O nível adequado hoje pode mudar com o tempo. Uma tool que ganha muitas flags de opção e comportamentos condicionais está se aproximando de um procedimento — avalie se essa lógica não deveria estar em uma skill que orquestra tools mais simples. Uma skill que inclui repetidamente "avalie se..." está se aproximando de um delegado — procedimentos não deveriam exigir julgamento adaptativo; esse é o sinal para promover esse julgamento a um sub-agent com seu próprio escopo. E um sub-agent cujas execuções se mostram quase idênticas todas as vezes está migrando para baixo — se o delegado nunca exerce julgamento real, rebaixe o trabalho para uma skill combinada com tools e recupere a legibilidade e o custo.

Duas práticas tornam essa refatoração segura. Primeiro, o trace indica o momento de agir: registros por etapa mostram quando uma tool passa a ser invocada com argumentos cada vez mais incomuns, quando uma skill é ignorada por raciocínios ad-hoc ou quando um sub-agent gera as mesmas cinco etapas a cada execução. Segundo, a avaliação confirma se a alteração funcionou: mudar de nível altera o comportamento — trata-se de uma mudança de política, no vocabulário do glossário, que o loop de avaliação deve validar como qualquer outra modificação. A decomposição não é uma decisão de design pontual; é uma propriedade contínua, e o espectro fornece a direção para essa manutenção.

9. Perguntas Frequentes

Os frameworks realmente não concordam sobre esses termos — essa distinção ainda importa? Os rótulos variam; o espectro não, e o glossário é transparente exatamente sobre isso. O que importa operacionalmente é categorizar cada capacidade pelo que ela é — uma ação executada, um procedimento carregado ou um principal que raciocina —, pois essa classificação determina a governança. O incidente de Ingrid não foi causado pela nomenclatura de um framework, mas sim pelo fato de a governança ter seguido o nome em vez da natureza do componente.

Um sub-agent é apenas uma tool do ponto de vista do chamador? Mecanicamente, ele é frequentemente invocado por meio da mesma interface, motivo pelo qual a classificação incorreta ocorre tão facilmente. A diferença está do outro lado da chamada: o comportamento de uma tool é sua própria implementação; o comportamento de um sub-agent é um modelo raciocinando em seu próprio contexto, com suas próprias tools, capaz de errar de formas imprevisíveis. Mesma convenção de chamada, espécies diferentes — e a governança deve acompanhar a espécie.

Quando uma skill é melhor do que simplesmente escrever instruções mais longas? Quando o procedimento é reutilizável, compartilhado ou exige governança. Instruções inline funcionam bem para um comportamento pontual de um único agente. No momento em que um procedimento passa a ser utilizado por vários agentes, mantido por alguém diferente do autor do agente, ou crítico a ponto de você precisar saber qual versão está executando em cada local — ele se torna uma skill e deve residir em um registry com versões e RBAC, e não em uma área de transferência.

Um sub-agent deve herdar as permissões do seu agente pai? Por padrão, não. A herança é conveniente, mas silenciosamente excessiva — o delegado recebe tudo o que o pai possui, necessário ou não, o que inverte o princípio do privilégio mínimo exatamente onde a autonomia de raciocínio torna essa proteção mais crítica. Delimite o escopo do sub-agent apenas às tools necessárias para sua subtarefa. Se isso parecer trabalhoso, é a arquitetura sinalizando que a fronteira de delegação exige o mesmo cuidado que qualquer outra fronteira de confiança, pois ela é, de fato, uma delas.

Subir no espectro não significa apenas maior custo e latência? Na maioria das vezes, sim — um sub-agent realiza chamadas de modelo que uma tool não faria —, e isso faz parte da heurística de escolher o menor nível possível. No entanto, a comparação não deve ser feita entre níveis em um vácuo, mas sim em relação à alternativa de o pai realizar todo o trabalho em sua própria janela. Uma subtarefa densa em contexto executada pelo pai pode degradar toda a execução (e seu custo acumula na janela crescente do pai); a mesma subtarefa delegada é executada em um contexto limpo e mais econômico. Meça o impacto por tarefa concluída, não por chamada individual.

A décima entrada de Ingrid nunca precisou ser proibida — ela precisava ser categorizada corretamente. Reclassificada pelo que realmente era, ela recebeu uma identidade, um escopo, um orçamento e um trace, sendo implantada em produção uma semana depois como o componente mais bem revisado do agente, em vez do menos auditado. Essa é a promessa central do espectro: as capacidades de um agente não são uma lista plana de "tools", mas sim três tipos de delegação, cada uma com uma governança correspondente. Ação, procedimento, principal. Classifique adequadamente.

Referências

• Hugging Face — agent glossary (maio de 2026) — as definições de tool/skill/sub-agent nas quais este artigo se baseia, parafraseadas com os devidos créditos.
• TrueFoundry MCP Gateway — governança por chamada para o nível de tools: registry, autenticação, RBAC, guardrails e auditoria.
• TrueFoundry Skills Registry — governança por artefato para o nível de skills: versões, proveniência, RBAC e carregamento sob demanda.
• TrueFoundry Agent Harness — governança por principal para o nível de sub-agents: isolamento, orçamentos e traces.
• O glossário de agentes mapeado para produção — o artigo principal desta série.

Ingrid é um exemplo ilustrativo consolidado, não uma pessoa, organização ou incidente específico. O vocabulário segue o glossário de agentes da Hugging Face (maio de 2026), que destaca como a fronteira entre tool/skill/sub-agent varia entre frameworks. Os trechos de configuração foram simplificados para fins de legibilidade e não representam esquemas literais do produto. As funcionalidades da TrueFoundry refletem a documentação pública no momento da redação; verifique a documentação atual para obter informações atualizadas.

‍