Três Times, Três Designs de Skills: O Debate de Arquitetura Veio à Tona

Em abril de 2026, dois times publicaram ensaios sérios sobre Agent Skills dentro da mesma janela de seis semanas. A Perplexity Research descreveu como seus times internos projetam, refinam e mantêm Skills em produção. Addy Osmani, trabalhando dentro do Google Chrome, publicou um catálogo de 20 Skills organizado em torno do ciclo de vida de software. Os dois estavam escrevendo sobre o mesmo primitivo. Chegaram a conclusões quase opostas sobre como estruturá-lo.

Seis semanas antes, a Vercel havia rodado um benchmark público e concluído que Skills tinham desempenho inferior a arquivos AGENTS.md: 100% de aprovação para AGENTS.md, 53% para Skills. A explicação foi estrutural, não partidária. Agentes pulam Skills. Leem prosa por padrão.

Três times. Três conclusões diferentes sobre o mesmo primitivo de governança. A tentação é perguntar quem está certo. Essa é a pergunta errada. A pergunta interessante é o que cada design está otimizando, e em qual ponto do ciclo de vida a disciplina precisa segurar.

A Resposta da Perplexity: Hierarquia e Progressive Disclosure

A Perplexity Research descreve Skills da forma como um engenheiro de sistemas descreveria um módulo de kernel. Uma Skill é um diretório. O diretório contém um arquivo de frontmatter com nome e descrição. Contém scripts/ para lógica executável, references/ para documentação aprofundada e assets/ para material estático. Skills compõem. Uma Skill pai pode rotear para Skills filhas. O Skill de roteamento fiscal aninha três níveis e cobre 1.945 seções do código fiscal do IRS.

O compromisso arquitetural é o progressive disclosure. O índice, cerca de 100 tokens, está sempre carregado para que o agente saiba que a Skill existe. O corpo da Skill, cerca de 5.000 tokens, carrega em runtime quando o agente decide que a Skill é relevante. Arquivos de referência carregam condicionalmente, sem teto de tokens. Três camadas: sempre, runtime, condicional. O agente nunca lê o que não precisa.

A Perplexity endurece isso com avaliação. Rodam suas Skills contra múltiplas famílias de modelo: GPT, Claude Opus, Claude Sonnet. Testam precision e recall do carregamento. Testam cross-loads proibidos, onde uma Skill puxa indevidamente uma irmã que não deveria. Testam leituras progressivas de arquivos, onde o agente precisa descer até a referência certa na profundidade certa. Testam conclusão de tarefas ponta a ponta. O catálogo de Skills não é exercício de escrita. É superfície de avaliação, e as avaliações decidem o que sobrevive.

O estágio do ciclo de vida que a Perplexity está governando é runtime. Quando o agente está em produção, roteando entre milhares de seções de código, a pergunta que importa é: ele carregou a capacidade certa e apenas a capacidade certa? Hierarquia mais progressive disclosure mais avaliação respondem essa pergunta.

A Resposta do Osmani: Fases do Ciclo e Anti-Racionalização

O catálogo de Addy Osmani é organizado em torno de outro eixo. Ele tem 20 Skills. Estão divididas em seis fases do ciclo de vida: Define, Plan, Build, Verify, Review, Ship, mais um balde transversal para atividades que não pertencem a uma fase única. Cada Skill termina em evidência concreta: um artefato escrito, um resultado de teste, um checklist que um auditor poderia puxar do log do git seis meses depois.

A escolha de design mais interessante é o que Osmani chama de anti-racionalização. Ele coloca isso diretamente nas Skills que publica:

Cada skill inclui uma tabela de desculpas comuns que um agente pode usar para pular o workflow, pareadas com uma refutação escrita.

Essa frase descreve uma postura de governança diferente da postura da Perplexity. A Perplexity está perguntando: o agente carregou a capacidade certa? Osmani está perguntando: quando o agente decide que pode pular a disciplina, o que o impede? A resposta dele é enumerar as racionalizações antecipadamente. A própria Skill contém os contra-argumentos para o próprio bypass. O agente que quer cortar caminho na fase de verify precisa ler, dentro da Skill que está tentando pular, por que “essa mudança é pequena” e “eu já chequei manualmente” e “o teste é instável” não são razões aceitáveis.

O estágio do ciclo de vida que Osmani está governando é decisão. O momento em que o agente está escolhendo se invoca uma Skill ou não. Hierarquia não ajuda ali. Progressive disclosure não ajuda ali. O que ajuda é forçar a racionalização para fora e antecipá-la.

A Resposta da Vercel: Não Use Skills

A conclusão prévia da Vercel se sobrepõe às outras duas. Na avaliação deles, agentes simplesmente não invocavam Skills de forma confiável. AGENTS.md é lido a cada turno. É passivo. Não exige decisão. Skills exigem que o agente reconheça um gatilho e carregue o corpo. Quando o gatilho dispara, você ganha os benefícios da Perplexity ou de Osmani. Quando não dispara, você ganha nada.

Isso não é uma refutação da Perplexity ou de Osmani. É o terceiro vértice do mesmo triângulo. A Vercel está dizendo: se sua governança precisa segurar a cada turno, independente do julgamento do agente, não coloque em uma Skill. Coloque em um arquivo que o agente lê passivamente. Skills são invocáveis. AGENTS.md é ambiente.

O estágio do ciclo de vida que a Vercel está governando é todo turno. A linha de base incondicional.

O Que as Três Divergências Realmente São

Empilhe as três posições e as divergências estruturais ficam claras.

Passivo vs invocável. A Vercel quer as regras no ar o tempo todo. Perplexity e Osmani aceitam pagar o custo de uma decisão de invocação em troca de modularidade, escopo e contexto progressivo.

Prescritivo vs procedural. As Skills da Perplexity são prescritivas: aqui está o que fazer, aqui está o material de referência, aqui está o script. As Skills do Osmani são procedurais: aqui está o workflow, aqui está a evidência que você precisa produzir, aqui estão as desculpas que não funcionam. Os dois são válidos. Respondem perguntas diferentes.

Eficiência em runtime vs integridade da decisão. O progressive disclosure da Perplexity é uma otimização de runtime. O agente, tendo decidido invocar, carrega exatamente o que precisa. As tabelas de anti-racionalização do Osmani são uma intervenção no momento da decisão. Tornam a escolha de invocar-ou-pular mais difícil de manipular.

Nenhuma dessas posições está errada. Estão respondendo perguntas diferentes sobre onde a governança precisa segurar.

Um Frame de Decisão

Se você está desenhando um catálogo de Skills, a escolha não é “qual time está certo”. É: em qual ponto do ciclo de vida você mais precisa que a disciplina prenda?

Se seu risco é incondicional e a cada turno, escreva AGENTS.md. Skills são o primitivo errado. O agente vai pular vezes suficientes para que a disciplina não segure.

Se seu risco está no ponto de decisão, onde o agente pode racionalizar pular o workflow, projete como Osmani. Fases do ciclo de vida. Evidência concreta. Tabelas de anti-racionalização que antecipam os argumentos de bypass. A Skill existe para tornar a escolha de invocar mais difícil de evitar.

Se seu risco está em runtime, onde o agente precisa rotear entre uma superfície grande de capacidades sem inflar contexto ou puxar a irmã errada, projete como Perplexity. Skills hierárquicas. Progressive disclosure. Avaliações que testam precisão de carregamento, cross-loads proibidos e conclusão ponta a ponta. A Skill existe para fazer a capacidade certa carregar no momento certo.

A maior parte dos sistemas em produção vai precisar dos três. Um AGENTS.md ambiente para as regras incondicionais. Skills no estilo Osmani nas fronteiras do ciclo de vida onde decisões são tomadas. Skills no estilo Perplexity dentro das superfícies profundas de capacidade onde roteamento importa. Tratar as três como escolas concorrentes é erro de categoria. São camadas.

Por Que Esse Debate Importa Agora

Seis meses atrás, a pergunta era se Skills eram um primitivo real ou marketing de fornecedor. Essa pergunta está resolvida. Vinte e seis plataformas adotaram o formato. Dois dos times mais rigorosos da área publicaram ensaios de implementação na mesma janela. Um terceiro publicou um benchmark que empurra de volta. Isso é o que um primitivo parece quando está sendo usado a sério.

A próxima fase não é sobre se usar Skills. É sobre como compor Skills com o resto da superfície do agente. AGENTS.md para o piso. Skills para os workflows estruturados acima do piso. Avaliações para ambos. Anti-racionalização onde decisões podem ser puladas. Hierarquia onde superfícies de capacidade são profundas.

Trate os três designs publicados como entradas complementares, não como votação. Os times que acertarem isso não serão os que escolheram o lado vencedor. Serão os que reconheceram que Vercel, Perplexity e Osmani resolveram problemas diferentes, e construíram um stack que respeita os três.

Fontes

Perplexity Research. “Designing, Refining, and Maintaining Agent Skills at Perplexity.” Abril de 2026.
Addy Osmani / Google Chrome. “Agent Skills.” Abril de 2026.

A Victorino ajuda líderes de engenharia a escolher o design de skills adequado ao ciclo de governança: contato@victorino.com.br | www.victorino.com.br