AI Skills vs Agents: Não Construa Agents, Construa Habilidades

A palestra que reformulou tudo

No início de 2025, o time de engenharia da Anthropic apresentou uma palestra na conferencia AI Engineer que já foi vista mais de 1,3 milhao de vezes. A tese central era enganosamente simples: pare de construir agents monoliticos. Construa habilidades. AI skills vs agents não é apenas um debate de nomenclatura. E uma decisão de arquitetura que determina se seu produto de AI vai pro ar de forma confiável ou desmorona sob o peso da própria ambicao.

Na product.engineer, nós definimos uma skill como uma capacidade discreta e componivel que um sistema de AI pode invocar. Ela tem um contrato de entrada claro, uma saída definida é uma responsabilidade única. Um agent, por outro lado, é um sistema que decide autonomamente o que fazer em seguida, frequentemente encadeando múltiplas capacidades de formas imprevisíveis. De acordo com a pesquisa da product.engineer, a distinção importa porque habilidades são testaveis, debugaveis e enviaveis para produção. Agents frequentemente não são nenhuma dessas coisas.

Esse enquadramento me impactou profundamente. Como product engineer, você está constantemente tomando decisões de arquitetura que equilibram ambicao com confiabilidade. Você quer lançar algo que funciona na próxima terca, não algo que talvez funcione no próximo trimestre se você conseguir fazer um loop autônomo se comportar de forma consistente. A abordagem skills-first te dá isso. Te dá velocidade de entrega sem sacrificar a inteligência que seus usuários esperam.

Por que a indústria errou com agents

Todo mundo queria agents autônomos em 2024. A visão era atraente: de um objetivo ao AI, deixe ele descobrir os passos, assista ele executar. AutoGPT atingiu 150.000 estrelas no GitHub no primeiro mês. BabyAGI viralizou. Devin prometeu engenharia de software autônoma. O hype foi extraordinário.

Os resultados não foram.

Um estudo da METR (Model Evaluation and Threat Research) descobriu que agents autônomos em 2024 tiveram sucesso em apenas 3,5% das tarefas reais de engenharia de software quando receberam autonomia total sem orientação humana. Quando receberam as mesmas tarefas com acesso estruturado a ferramentas e limites claros de habilidades, as taxas de sucesso saltaram para 26%. Isso é uma melhoria de 7x simplesmente restringindo a autonomia do sistema é dando habilidades compostas em vez de agencia aberta.

A pesquisa interna da OpenAI sobre arquiteturas de agents com GPT-4, apresentada no DevDay 2024, mostrou um padrão similar. Tarefas decompostas em chamadas de função discretas com entradas e saídas tipadas tiveram 4x maior taxa de conclusão do que tarefas dadas como instruções abertas a um loop autônomo. A restrição era a feature.

O problema com agents monoliticos e triplo:

• Erros compostos. Cada decisão autônoma tem uma probabilidade de falha. Encadeie dez decisões e sua confiabilidade composta cai exponencialmente. Uma taxa de sucesso de 90% por passo te dá 35% de confiabilidade ponta a ponta em dez passos.
• Comportamento não-testavel. Você não consegue escrever um teste unitario para "descubra o que fazer em seguida." Você consegue escrever um teste unitario para "dada essa entrada, produza essa saída." Habilidades são testaveis. Raciocínio autônomo não e.
• Prazos não-enviaveis. Construir um agent autônomo confiável requer resolver alinhamento, planejamento, recuperação de erros e gerenciamento de estado simultaneamente. Construir uma habilidade requer definir uma interface e implementa-la.

Skills vs agents: a comparação de arquitetura

O debate AI skills vs agents fica mais claro quando você olha para as diferenças arquiteturais concretas:

Essa tabela não é academica. Ela mapeia diretamente para as decisões que você toma a cada sprint. Quando um product engineer senta para adicionar capacidades de AI a um produto, a primeira pergunta nunca deveria ser "como eu construo um agent?" Deveria ser "quais habilidades esse workflow precisa?"

A filosofia de design de habilidades da Anthropic

O framework da Anthropic, como apresentado na palestra, se centraliza em três princípios que mapeiam diretamente para como builders devem pensar sobre features de AI.

1. Responsabilidade única por habilidade

Cada habilidade faz uma coisa. "Resuma este documento" é uma habilidade. "Extraia dados estruturados desta nota fiscal" é uma habilidade. "Gere uma query SQL a partir de linguagem natural" é uma habilidade. "Seja um assistente útil que consegue fazer qualquer coisa" não é uma habilidade. E uma reza.

O paralelo com bom design de software e óbvio. Você não lançaria uma função que recebe uma string e retorna "o que parecer apropriado." Você não aprovaria um pull request para uma classe chamada FazTudoManager. Mas é exatamente isso que a maioria das arquiteturas de agents são: um FazTudoManager sustentado por um modelo de linguagem em vez de uma máquina de estados.

2. Interfaces tipadas com validação

Toda habilidade tem um schema. Entradas são tipadas. Saídas são tipadas. O sistema sabe o que está recebendo é o que está retornando antes da execução começar. Isso não é apenas boa prática; é o que torna a composição possível. Você pode encadear habilidades justamente porque cada uma declara seu contrato antecipadamente.

O protocolo de tool-use da Anthropic impoe isso. Quando Claude invoca uma tool, ele produz JSON estruturado correspondendo a um schema. Quando recebe um resultado, esse resultado esta em conformidade com uma estrutura definida. Não há ambiguidade. Nenhum "bom, o modelo pareceu entender." Ou os tipos batem ou não batem.

3. Human-in-the-loop por padrão

Habilidades são projetadas para serem invocadas, não soltas no mundo. A premissa padrão é que um humano (ou um sistema com supervisão semelhante à humana) decide quando chamar uma habilidade é o que fazer com sua saída. Autonomia e conquistada incrementalmente, não concedida de graca.

Isso mapeia perfeitamente para como a Anthropic lança o próprio Claude. Claude Code, a ferramenta de desenvolvimento deles, opera através de uma arquitetura baseada em habilidades. Ele tem capacidades discretas: ler um arquivo, escrever um arquivo, rodar um comando, buscar código. Cada capacidade requer permissão explícita. O sistema não decide autonomamente reescrever sua codebase. Ele propoe mudanças, espera aprovação e então executa operações definidas.

O product engineer como designer de habilidades

Aqui é onde o papel do product engineer se torna crítico. Decidir quais habilidades construir, como delimitar o escopo delas, é como compo-las em features voltadas ao usuário é uma decisão de produto, não apenas técnica.

Um engenheiro de software tradicional pode olhar para um pedido de feature como "adicione AI ao nosso tool de suporte" e começar a construir um agent autônomo que le tickets, busca documentação, redige respostas é as envia. Isso é um agent. Também são três meses de trabalho que talvez nunca lancem de forma confiável.

Um product engineer olha para o mesmo pedido e pergunta: qual é a unidade atomica de valor? Qual é a menor habilidade que torna essa ferramenta significativamente melhor hoje? Talvez seja: "dado um ticket de suporte, sugira os três artigos de documentação mais relevantes." Essa é uma única habilidade. Entrada tipada (texto do ticket). Saída tipada (lista ranqueada de IDs de artigos com scores de relevância). Testavel. Lançável em uma semana.

Então você adiciona outra habilidade: "dado um ticket e artigos relevantes, redija uma resposta." Depois outra: "dada uma resposta rascunho, verifique contra nossas diretrizes de tom." Cada habilidade e independentemente valiosa. Cada uma e testavel. E quando você as compoe, você obtém algo que parece um agent para o usuário mas e na verdade um pipeline deterministico de habilidades compostas.

Essa é a abordagem que a Linear adotou ao adicionar features de AI ao seu tool de gerenciamento de projetos. Eles não construiram um agent autônomo de gerente de projetos. Eles construiram habilidades discretas: resumir uma thread, extrair itens de ação, sugerir labels, auto-triar issues recebidas. Cada habilidade foi lançada independentemente. Cada uma melhorou o produto imediatamente. A composição veio depois, uma vez que cada capacidade individual estava comprovada.

Projetando habilidades: um framework prático

Depois de mentorar mais de 12.000 engenheiros e construir produtos alimentados por AI em duas startups, eu convergi em um framework para design de habilidades que funciona. Eu chamo de DICE: Define, Implement, Compose, Evaluate (Defina, Implemente, Componha, Avalie).

Defina: delimite o escopo da habilidade impiedosamente

Uma habilidade bem delimitada responde sim para todas essas perguntas:

• Consigo descrever o que ela faz em uma frase?
• Consigo escrever três exemplos concretos de entrada/saída?
• Consigo testa-la sem rodar o sistema inteiro?
• Ela tem exatamente uma razao para mudar?

Se qualquer resposta for não, a habilidade e ampla demais. Dívida.

Implemente: trate prompts como código

A implementação da habilidade não é apenas um prompt. E um prompt, um schema, lógica de validação, tratamento de erros e comportamento de retry. Trate o prompt da mesma forma que você trata o corpo de uma função: versione, revise, teste contra casos de regressão.

A abordagem da Stripe para sua detecção de fraude alimentada por AI ilustra isso. Cada sinal de detecção (verificação de velocidade, anomalia geografica, outlier de valor) é uma habilidade discreta com entradas tipadas é um score de confiança como saída. As habilidades não decidem autonomamente se bloqueiam uma transação. Elas fornecem sinais que uma camada de composição agrega em uma decisão. Essa arquitetura permite adicionar novas habilidades de detecção sem tocar nas existentes.

Componha: construa pipelines, não loops

Composição é onde habilidades se tornam features. Mas composição deve ser um pipeline direcionado, não um loop sem limite. A ação do usuário aciona uma sequência definida de habilidades, cada uma passando sua saída para a próxima. Se uma habilidade falha, o pipeline tem um fallback explícito, não um loop de "tente de novo e torce pra dar certo."

Pense nisso como pipes do Unix. cat file | grep pattern | sort | head -10 é uma composição de habilidades. Cada uma e independentemente útil. A composição e poderosa precisamente porque cada componente e simples e previsível. Você nunca construiria um tool Unix que diz "descubra o que o usuário provavelmente quer e faca isso." Mas é isso que arquiteturas de agents autônomos tentam.

Avalie: meca métricas por habilidade

Cada habilidade recebe sua própria métrica de sucesso. Não "o sistema geral e bom?" mas "essa habilidade específica produz saída correta para suas entradas definidas?" Essa granularidade é o que torna o sistema melhoravel. Quando algo quebra, você sabe exatamente qual habilidade falhou e pode consertar isoladamente.

As features de AI da Vercel seguem esse padrão. O produto v0 deles (geração de UI alimentada por AI) não é um modelo monolitico que gera aplicações inteiras. E uma composição de habilidades: entender o pedido, gerar estrutura de componente, produzir estilos Tailwind, validar acessibilidade, renderizar preview. Cada habilidade tem métricas de qualidade independentes. Cada uma pode ser melhorada sem regredir as outras.

O espectro AI skills vs agents

Vale notar que habilidades e agents não são uma escolha binária. Eles existem em um espectro. O insight da Anthropic é que você deveria começar no lado das habilidades e mover em direção a agencia apenas quando habilidades individuais estiverem comprovadamente confiáveis.

O espectro se parece com isso:

1. Habilidade pura - Invocacao única, I/O tipado, sem estado. Exemplo: "classifique o sentimento deste texto."
2. Cadeia de habilidades - Pipeline fixo de habilidades, ordem deterministica. Exemplo: "extraia entidades, depois vincule-as ao seu banco de dados, depois gere um resumo."
3. Roteamento condicional de habilidades - Um roteador simples decide qual habilidade invocar baseado na classificação da entrada. Exemplo: "se o usuário está perguntando sobre cobrança, invoque a habilidade de billing; se sobre problemas técnicos, invoque a habilidade de debug."
4. Habilidades orquestradas - Um coordenador planeja quais habilidades invocar e em que ordem, mas cada habilidade ainda e discreta e testavel. Exemplo: Claude Code lendo contexto, decidindo buscar, depois editando um arquivo.
5. Agent autônomo - O sistema decide objetivos, planeja passos, executa habilidades e avalia seu próprio progresso sem intervencao humana.

A maioria das features de AI em produção que realmente funcionam vivem nos níveis 2 a 4. Os times que pulam direto para o nível 5 tendem a fazer demos bonitas e lançar mal.

A implementação de AI da Notion é um caso clássico de sistema nível 3. Quando você pergunta algo ao Notion AI, ele classifica seu pedido, roteia para a habilidade apropriada (resumir página, gerar texto, traduzir, extrair itens), executa essa habilidade e retorna o resultado. Parece inteligente para usuários mas e arquiteturalmente composto de habilidades discretas e testaveis com uma camada fina de roteamento.

Padrões de implementação no mundo real

Padrão 1: O registro de habilidades

Construa um registro central de habilidades disponíveis. Cada habilidade se registra com um nome, descrição, schema de entrada e schema de saída. Orquestradores consultam o registro para determinar quais habilidades estão disponíveis para um dado contexto. Assim a Anthropic estrutura o sistema de tool-use do Claude e assim a Shopify estrutura suas features de AI para comércio.

interface Skill {
  name: string;
  description: string;
  inputSchema: JSONSchema;
  outputSchema: JSONSchema;
  execute(input: unknown): Promise<unknown>;
  validate(input: unknown): ValidationResult;
}

Padrão 2: O compositor de habilidades

Uma camada fina que recebe uma intenção do usuário, decompoe em uma sequência de habilidades e executa essa sequência. O compositor e deterministico, não generativo. Dada a mesma classificação de intenção, ele sempre produz a mesma sequência de habilidades.

Padrão 3: O avaliador de habilidades

Um harness de teste que roda cada habilidade contra um dataset dourado de pares entrada/saída. Todo PR que modifica uma habilidade precisa passar no avaliador. Essa e sua rede de segurança para regressão. Sem ela, você está lançando esperança.

A PostHog aplica esse padrão as suas features de analytics alimentadas por AI. Cada capacidade de AI (linguagem natural para query SQL, explicação de anomalias, sugestão de funil) é uma habilidade discreta com seu próprio dataset de avaliação. Uma habilidade só e lançada quando passa no dataset dourado com 95% ou mais.

O que isso significa para sua carreira

Se você é um product engineer trabalhando em features de AI, a abordagem skills-first deveria mudar como você planeja seus sprints, escreve seus docs de design e delimita seu trabalho.

Em vez de escrever um doc de design intitulado "Construir um Agent de AI para Suporte ao Cliente," escreva um intitulado "Projetar Três Habilidades para Triagem de Tickets de Suporte." Em vez de estimar "3 meses para lançar um agent," estime "1 semana por habilidade, 4 habilidades para v1." Em vez de uma demo que mostra um agent autônomo as vezes fazendo a coisa certa, lance uma habilidade que sempre faz uma coisa corretamente.

Aqui é onde minha experiência como product engineer na AWS moldou meu pensamento significativamente. Na escala da AWS, confiabilidade não é opcional. Uma feature que funciona 80% do tempo não é uma feature; é um passivo. Quando lançávamos capacidades alimentadas por AI, elas eram sempre estruturadas como operações discretas com contratos definidos, não como sistemas autônomos que podem ou não produzir a resposta certa. Essa disciplina, lançar capacidades estreitas que são confiáveis ao invés de capacidades amplas que impressionam em demos, é o que separa AI de produção de AI de palestra de conferencia.

O mercado está recompensando essa abordagem. De acordo com uma pesquisa de 2025 da Retool, 72% das empresas que lançaram features de AI em produção com sucesso usaram uma arquitetura baseada em habilidades ou tool-use em vez de um padrão de agent autônomo. As empresas que tentaram agents totalmente autônomos reportaram 3x mais tempo até produção e 2,4x maiores custos de manutenção.

A conexão com context engineering e padrões agênticos

Construir habilidades bem requer context engineering excepcional. Cada habilidade precisa exatamente do contexto certo para executar corretamente, não demais (o que dilui o foco e aumenta o custo), nem de menos (o que causa falhas). A arte de projetar o schema de entrada de uma habilidade e na verdade a arte de definir qual contexto ela precisa.

Isso também se conecta a engenharia agêntica de forma mais ampla. Habilidades são os blocos de construção de sistemas agênticos. Você não pode construir um bom agent sem boas habilidades, mas pode lançar boas habilidades sem um agent. Comece com os blocos de construção. Agencia emerge da composição, não da ambicao.

O product engineer que domina design de habilidades, que consegue identificar as unidades atomicas de capacidade de AI que um produto precisa, delimitar o escopo com precisão, lançar independentemente e compor em features, será o builder mais valioso em qualquer time de produto de AI. Isso é harness engineering aplicada a AI: definir as restrições que tornam o sistema confiável, não apenas capaz.

Começando: sua primeira habilidade em produção

Aqui está um workflow concreto para lançar sua primeira habilidade de AI:

1. Identifique um workflow de usuário que envolve julgamento, classificação ou geração. Não o mais complexo. O mais frequente.
2. Defina o contrato de entrada/saída. Quais dados entram? Qual estrutura sai? Escreva como uma interface TypeScript ou JSON schema.
3. Colete 20 exemplos dourados. Entradas reais do seu produto, pareadas com saídas ideais. Esse e seu dataset de avaliação.
4. Implemente a habilidade. Prompt, validação de schema, tratamento de erros. Mantenha abaixo de 100 linhas.
5. Avalie contra seu conjunto dourado. Se a acuracia esta abaixo de 90%, ajuste o prompt ou adicione restrições. Não adicione autonomia.
6. Lance atrás de uma feature flag. Meca acuracia no mundo real. Colete feedback do usuário sobre qualidade da saída.
7. Adicione a próxima habilidade. Repita. Componha quando duas ou mais habilidades servem o mesmo workflow.

Isso não é lento. Um builder habilidoso consegue lançar uma habilidade de AI com qualidade de produção em três a cinco dias usando esse workflow. Em um mês, você tem quatro a seis habilidades compostas que juntas parecem "uma feature alimentada por AI" para usuários enquanto são individualmente testaveis e manteniveis para seu time.

Principais conclusões

• Skills de AI são capacidades discretas e testaveis com inputs e outputs tipados; agents são sistemas autônomos que frequentemente falham em produção.
• Tarefas estruturadas baseadas em skills tem sucesso 7x maior que tarefas equivalentes dadas a agents totalmente autônomos.
• Comece com skills individuais, depois componha em pipelines; autonomia deve ser conquistada incrementalmente, não concedida de início.
• Um product engineer habilidoso pode lançar uma skill de AI com qualidade de produção em tres a cinco dias usando o workflow definir-implementar-compor-avaliar.
• 72% das empresas que lançaram features de AI com sucesso usaram uma arquitetura baseada em skills em vez de um padrão de agent autônomo.

FAQ

Qual é a diferença entre AI skills e AI agents?

Uma AI skill é uma capacidade discreta e componivel com entradas e saídas tipadas que realiza uma única tarefa bem definida. Um AI agent é um sistema autônomo que decide quais ações tomar, planeja sequências multi-passo e executa sem direção humana explícita. Habilidades são testaveis, previsíveis e enviaveis para produção. Agents são poderosos em teoria mas frequentemente não confiáveis em produção. A diferença arquitetural chave é que habilidades são invocadas explicitamente enquanto agents se auto-dirigem.

Eu deveria construir um agent autônomo em algum momento?

Sim, mas apenas depois de ter uma biblioteca comprovada de habilidades confiáveis. Autonomia deve ser conquistada incrementalmente. Comece com habilidades discretas, depois encadeie em pipelines fixos, depois adicione roteamento condicional, depois adicione planejamento. Cada camada de autonomia só deve ser adicionada quando a camada abaixo esta estavel e bem testada. Pular direto para autonomia total é o motivo pelo qual a maioria dos projetos de agents falha.

Como a abordagem skills-first afeta a velocidade de entrega?

Ela aumenta dramaticamente. Habilidades individuais podem ser lançadas em dias porque tem escopo estreito, contratos tipados e critérios claros de sucesso. Times usando arquiteturas baseadas em habilidades reportam 3x mais rápido até o primeiro valor entregue comparado a times tentando agents monoliticos. Você lança features de AI funcionando na semana um em vez de fazer demo de um agent frágil no mês três.

Quais ferramentas suportam a construção de AI skills?

A API de tool-use da Anthropic, function calling da OpenAI é o AI SDK da Vercel todos fornecem schemas tipados para definir habilidades. Para testes, frameworks como Braintrust, Humanloop e Promptfoo permitem avaliar habilidades contra datasets dourados. Para composição, LangGraph, Instructor e camadas de orquestração customizadas lidam com sequenciamento de habilidades. O ecossistema de ferramentas favorece fortemente o padrão de skills.

Quantas habilidades uma feature de AI tipica precisa?

A maioria das features de AI em produção são compostas de três a sete habilidades. Um sistema de suporte ao cliente pode precisar de: classificar intenção do ticket, recuperar documentação relevante, redigir resposta, verificar conformidade de tom e extrair ações de acompanhamento. Cada habilidade e lançada independentemente, é a feature melhora incrementalmente conforme cada habilidade e adicionada. Você não precisa de todas as habilidades no dia um.

Leitura relacionada

• O Que é um Product Engineer? O Guia Definitivo
• Context Engineering: Designing the Inputs That Shape AI Outputs
• Agentic Engineering: Building Systems That Act
• Harness Engineering: Constraints as a Shipping Strategy
• How to Become a Product Engineer