Agents ou Skills: qual escolher?

O que é um agent

Um agent, no contexto de IA e de sistemas baseados em LLMs, é uma entidade autônoma. Ele percebe o ambiente, toma decisões e executa ações para atingir um objetivo.

Ele não apenas responde a um prompt. Na verdade, ele planeja, delega, itera e avalia os próprios resultados.

O agent possui um loop de raciocínio, que pode seguir padrões como o ReAct (Reason + Act). Além disso, ele acessa ferramentas externas para ampliar suas capacidades.

O que é uma skill

Uma skill é uma capacidade bem definida, isolada e reutilizável. Ela encapsula um comportamento específico, como um template de prompt, uma sequência de instruções, uma transformação de dados ou uma chamada a uma API.

Diferente do agente, a skill não decide o objetivo. Ela executa, ou seja, quando acionada, segue um fluxo conhecido e retorna um resultado esperado.

Hoje o termo aparece em dois sentidos principais. Por isso, vale separar cada um deles.

Agents ou skills: a diferença fundamental

A diferença entre agents ou skills não é de tamanho nem de complexidade. Na verdade, é uma diferença de responsabilidade.

O agente é responsável por atingir um objetivo e decide o caminho. A skill, por outro lado, executa uma tarefa bem definida e não decide nada por conta própria.

Essa distinção importa porque define quem controla o fluxo. Em uma arquitetura multiagente, o agent orquestrador analisa o objetivo e seleciona as skills ou outros agentes que podem ajudar.

Em seguida, ele coordena a execução. Ou seja, as skills são as ferramentas nas mãos do agent.

Pense da seguinte forma: o agent é o estrategista e a skill é o especialista técnico. O estrategista não executa cada tarefa manualmente, porque delega para quem tem a competência certa e acompanha os resultados.

Quando usar agents

Agents são a escolha certa quando o problema envolve decisões dinâmicas e múltiplos passos interdependentes. Também servem quando o comportamento precisa mudar com base em resultados intermediários.

Se o fluxo depende de dados externos, do estado atual do sistema ou de uma sequência que varia caso a caso, então um agente é necessário.

Um exemplo prático é um revisor de código que analisa um pull request. Ele identifica problemas, sugere correções e cria comentários automaticamente no GitHub.

Outro exemplo é um assistente de suporte que consulta a base de conhecimento e verifica o histórico do cliente. Depois, ele decide se responde sozinho ou se escala para um humano.

Nesses cenários, não existe um script fixo. Por isso, o agente precisa raciocinar e adaptar o comportamento em tempo real.

Ainda assim, mesmo nesses casos, o agente raramente trabalha sozinho. Ele se apoia em skills para cada passo concreto, como ler o diff, buscar o histórico ou publicar o comentário.

Quando usar skills

Skills são a escolha certa quando o comportamento esperado é fixo, bem definido e reutilizável em vários contextos.

Se você consegue descrever o que deve acontecer em termos de entrada e saída, sem ambiguidade, então uma skill basta. Além disso, ela é mais previsível que um agente.

Um exemplo é uma skill que recebe um texto e retorna um resumo SEO com no máximo 160 caracteres. Outro é uma skill que formata uma resposta como JSON seguindo um schema específico.

Há ainda a skill que executa uma consulta no banco de dados e retorna os resultados paginados. Essas operações são valiosas, mas não exigem raciocínio.

Elas exigem execução confiável. Nesse ponto, a skill entrega mais previsibilidade e menor custo computacional.

Por que agents e skills se complementam

A separação entre agents e skills não é apenas teórica. Na prática, ela é uma estratégia arquitetural.

Ao isolar comportamentos em skills, você consegue testá-los individualmente e reutilizá-los em diferentes agentes. Também consegue substituí-los sem alterar a lógica do orquestrador.

O agent, por sua vez, ganha composabilidade. Ele não precisa saber como executar cada tarefa, apenas quando e por que invocar cada skill.

Essa divisão de responsabilidades lembra o que o Domain-Driven Design prega no código. Cada componente deve ter uma responsabilidade única e bem delimitada.

Nessa analogia, o agent é o agregado que coordena, e a skill é o serviço de domínio que executa.

Em arquiteturas mais avançadas, as skills podem virar ferramentas expostas via MCP (Model Context Protocol). Assim, qualquer agent conectado invoca a skill pelo nome, sem conhecer a implementação interna.

O problema de transformar tudo em agent

Um erro comum em projetos novos é tratar tudo como agente. O raciocínio parece lógico: se o agente é mais poderoso, por que não usá-lo sempre?

O problema é que agentes têm custo. Cada ciclo de raciocínio consome tokens, introduz latência e aumenta a superfície de falha.

Um agent que poderia virar uma simples skill determinística só adiciona complexidade sem justificativa.

Além disso, agentes são mais difíceis de testar. Uma skill tem entrada e saída bem definidas, enquanto um agente pode tomar caminhos diferentes a cada execução.

Isso dificulta a reprodução de comportamentos e a escrita de testes confiáveis. Para medir esse tipo de sistema, o artigo sobre evals para agentes de IA apresenta práticas úteis.

O princípio aqui é usar o componente mais simples que resolve o problema. Portanto, se uma skill resolve, não crie um agente.

O problema de transformar tudo em skill

O caminho oposto também tem armadilhas. Codificar toda a lógica de negócio em skills fixas, sem um agente para orquestrar, gera fluxos rígidos.

Esses fluxos quebram quando o cenário muda levemente. Em outras palavras, a rigidez cobra seu preço na primeira variação de entrada.

Skills sem agentes são como funções sem um chamador inteligente. Alguém precisa decidir qual skill invocar, em que ordem e o que fazer com o resultado.

Se essa decisão ficar fixa no código, o sistema perde flexibilidade. Consequentemente, ele se torna frágil diante de variações no input.

A combinação correta, então, é esta: agents para raciocinar e decidir, skills para executar com precisão.

Multi-agent e composição de skills

Em sistemas multi-agent, a separação entre agents e skills fica ainda mais clara. Um agente orquestrador recebe o objetivo de alto nível e o decompõe em tarefas menores.

Algumas dessas tarefas vão para outros agentes especializados, como um agente de análise de código, um de documentação ou um de deploy.

Cada agent especializado, por sua vez, usa um conjunto de skills para executar seu trabalho. Assim, a hierarquia fica clara em todos os níveis.

Essa estrutura cria um sistema escalável e fácil de manter. Adicionar uma nova capacidade pode significar apenas criar uma skill nova e registrá-la no agent correto.

O protocolo A2A define como os agentes se comunicam nessa hierarquia, trocando mensagens estruturadas e delegando tarefas. Já o MCP define como as skills chegam aos agentes na forma de ferramentas.

Juntos, os dois protocolos formam a espinha dorsal de uma arquitetura de IA moderna.

Critérios para decidir entre agents ou skills

Para decidir entre agents ou skills em uma situação concreta, três perguntas ajudam a clarear a escolha.

Primeiro: o comportamento pode virar uma função com entrada e saída bem definidas? Se sim, provavelmente é uma skill.

Segundo: o fluxo de execução depende de decisões baseadas em resultados intermediários? Se sim, provavelmente é um agent.

Terceiro: o componente precisa ser reutilizado em vários contextos sem modificação? Nesse caso, encapsule como skill e deixe que diferentes agents a invoquem.

Essas perguntas não são absolutas. Mesmo assim, elas orientam bem a maioria dos casos práticos em projetos de IA aplicada.

Na dúvida, comece pela opção mais simples. Uma skill bem descrita pode virar ferramenta de um agente no futuro, enquanto desmontar um agente desnecessário costuma dar mais trabalho.

Implementação de agents e skills em C#

No ecossistema .NET, tanto o Semantic Kernel quanto o Microsoft Agent Framework oferecem suporte nativo para os dois conceitos. A seguir, você vê como cada um representa essa separação.

using System.ComponentModel;
using Microsoft.SemanticKernel;

public class SummarySkill
{
    [KernelFunction("generate_summary")]
    [Description("Generates an SEO summary with at most 160 characters")]
    public string GenerateSummary(
        [Description("The text to summarize")] string text)
    {
        // lógica determinística de resumo
        return text.Length <= 160 ? text : text[..157] + "...";
    }
}

using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.Agents;
using Microsoft.SemanticKernel.Connectors.OpenAI;

var builder = Kernel.CreateBuilder();
builder.AddOpenAIChatCompletion("gpt-4o-mini", apiKey);

// Registra a skill como plugin do kernel
builder.Plugins.AddFromType<SummarySkill>();
var kernel = builder.Build();

// O agente decide quando usar a skill
ChatCompletionAgent agent = new()
{
    Name = "ContentAgent",
    Instructions = "You help writers prepare articles for publishing.",
    Kernel = kernel,
    Arguments = new KernelArguments(new OpenAIPromptExecutionSettings
    {
        FunctionChoiceBehavior = FunctionChoiceBehavior.Auto()
    })
};

using Microsoft.Agents.AI;
using Microsoft.Extensions.AI;
using OpenAI;

// Descobre skills no formato SKILL.md dentro da pasta "skills"
var skillsProvider = new AgentSkillsProvider(
    Path.Combine(AppContext.BaseDirectory, "skills"));

AIAgent agent = new OpenAIClient(apiKey)
    .GetChatClient("gpt-4o-mini")
    .AsAIAgent(new ChatClientAgentOptions
    {
        Name = "ContentAgent",
        ChatOptions = new()
        {
            Instructions = "You help writers prepare articles for publishing.",
            // A skill determinística entra como ferramenta
            Tools = [AIFunctionFactory.Create(new SummarySkill().GenerateSummary)]
        },
        AIContextProviders = [skillsProvider]
    });

Console.WriteLine(await agent.RunAsync("Create the SEO summary for this article."));

Conclusão

Agents e skills não são concorrentes. Na verdade, eles são partes complementares de uma arquitetura de IA bem projetada.

O agente traz raciocínio, autonomia e capacidade de adaptação. A skill, por outro lado, traz precisão, reutilização e previsibilidade.

Tentar substituir um pelo outro gera excesso de complexidade ou excesso de rigidez. Por isso, a dúvida entre agents ou skills deve partir sempre da natureza do problema.

Comportamentos fixos e bem definidos pedem skills, enquanto fluxos dinâmicos e decisões contextuais pedem agents. Por fim, sistemas realmente robustos usam os dois, cada um no papel que desempenha melhor.

FAQ

Qual é a diferença entre agent e skill em termos práticos?

O agente decide o que fazer e quando, enquanto a skill executa uma tarefa específica quando alguém a invoca. Em resumo, o agente usa skills como ferramentas para atingir um objetivo maior.

Posso usar skills sem agents?

Sim, mas nesse caso você precisa de um orquestrador externo para decidir qual skill invocar e em que ordem. Sem esse componente, o código chama cada skill de forma explícita.

Um agent pode ser uma skill de outro agent?

Sim, porque em arquiteturas multiagente um agente pode virar ferramenta de outro. O protocolo A2A facilita essa comunicação entre agentes de plataformas diferentes.

Skills têm custo de tokens?

Depende da implementação, já que uma skill com código determinístico não consome tokens e uma skill baseada em prompt consome. No formato SKILL.md, as instruções também ocupam contexto quando o agente as carrega.

Qual framework .NET suporta os dois conceitos?

O Semantic Kernel e o Microsoft Agent Framework suportam ambos. O Agent Framework é o sucessor do Semantic Kernel e adiciona workflows, suporte a MCP e carregamento de Agent Skills.

Como testar agents e skills de forma isolada?

Skills aceitam testes unitários tradicionais, pois têm entrada e saída definidas. Agentes exigem testes de integração, simulação do ambiente ou evals.