Existe um tipo de conselho sobre inteligência artificial que parece útil até a terceira vez que você precisa segui-lo.

“Use este prompt — o pedido, em texto ou voz, que orienta o que a IA deve fazer.”

“Antes, mande a IA pesquisar.”

“Depois, peça para ela assumir o papel de especialista.”

“Não esqueça de exigir fontes, definir o formato, mandar revisar, conferir os riscos, preservar o contexto e pedir a resposta em tabela.”

Ótimo. Agora basta a pessoa lembrar de montar uma pequena licitação pública toda vez que quiser resolver um problema.

Eu não sou contra prompt. O pedido continua sendo a forma mais direta de dizer à máquina o que eu quero. O que me incomoda é a expectativa de que cada usuário precise decorar a coreografia operacional da IA: quando pesquisar, qual ferramenta acionar, como transferir o contexto, quais dados não expor, que validação executar e até onde o agente de IA — um sistema que recebe contexto, usa ferramentas e executa etapas para alcançar um objetivo — pode ir sem pedir uma decisão.

Se o trabalho é recorrente, esses critérios não deveriam continuar morando apenas na memória de quem faz o pedido. Eles deveriam estar no sistema.

Ter uma pasta cheia de skills — instruções e capacidades reutilizáveis para executar uma classe de tarefa — e não saber quando acioná-las é como colecionar superpoderes e deixá-los fora de cena justamente na hora do problema. Não sei você, mas, quando eu assistia a Heroes e via Sylar acumular habilidades, eu ficava sobretudo indignado — e um tanto nervoso. A situação apertava, eu lembrava de uma habilidade que ele já tinha adquirido e que parecia perfeita para aquilo, e dava uma vontade quase física de avisar o personagem pela tela: “Ô, infeliz! Você já tem a ferramenta certa; usa logo”. Para melhorar a minha indignação, no arsenal dele havia até uma supermemória. Era exatamente isso que me irritava como espectador: capacidade disponível no inventário não é a mesma coisa que capacidade disponível na prática.

Uma skill instalada, mas nunca reconhecida pelo agente no contexto certo, continua sendo um superpoder esquecido. O usuário não deveria precisar lembrar o nome exato da habilidade nem prescrever cada etapa para trazê-la ao palco. O Harness de IA — o conjunto de contexto, regras e critérios que decide quando e como usar essas capacidades — precisa ligar o pedido natural ao contrato daquela execução.

É aí que entram também os recursos e scripts usados pelas skills, as regras de acionamento, os contratos, os dados de contexto, os fluxos de trabalho, as validações e os limites. Não como palavras sofisticadas para vender um prompt maior. Como partes da operação.

O objetivo prático é simples: eu faço um pedido natural; o sistema reconhece o tipo de trabalho, carrega a habilidade adequada e segue o processo já acordado. Eu continuo dando a direção. Só não preciso reaprender a dirigir a mesma rotatória toda manhã.

Isso não acontece porque a IA ganhou intuição. Depende de alguém desenhar os sinais de acionamento, testar casos reais, corrigir escolhas ruins e manter regras e fontes atualizadas.

O usuário não deveria navegar por um menu invisível de hacks — /pesquise, /encaminhe, /revise, /agora-seja-especialista — para a operação funcionar. Ele descreve o resultado, fornece o contexto que só ele conhece e declara as restrições. O Harness escolhe a capacidade e o roteiro aplicável; se duas rotas forem plausíveis, faltar autorização ou a decisão tiver consequência real, ele pergunta em vez de escolher escondido.

Um prompt bom ajuda. Um sistema bom deixa de depender da minha memória

Um prompt improvisado pode produzir uma resposta excelente. Também pode produzir uma resposta excelente na segunda-feira, uma mediana na terça e uma pequena obra de ficção corporativa na quarta.

O problema não é apenas a qualidade do texto que escrevi no campo de conversa. É tudo o que ficou de fora dele porque eu estava com pressa, cansado ou simplesmente achei óbvio.

Compare:

Pesquise esse assunto e me entregue um relatório completo.

Com um pedido para um Harness que já conhece o contrato de pesquisa:

Quero entender se essa solução faz sentido para o nosso cenário.

No segundo caso, a frase é menor, mas o trabalho por trás dela pode ser maior. A skill de pesquisa sabe que precisa identificar a decisão em jogo, priorizar fontes primárias, separar evidência de inferência, registrar limites, verificar atualidade, comparar alternativas e não transformar uma página comercial em comprovação independente.

Eu não precisei recitar esse checklist porque ele já foi discutido, escrito, testado e versionado.

A documentação do GitHub descreve justamente essa função das Agent Skills: instruções, scripts e recursos carregados quando relevantes para uma tarefa especializada. A própria orientação diferencia regras gerais, que cabem em instruções do projeto, de procedimentos detalhados que só deveriam entrar em contexto quando necessários.

Isso é importante porque enfiar todas as regras em todo pedido também não resolve. Só troca a amnésia pelo congestionamento.

A habilidade certa precisa aparecer sem virar palavra mágica

Uma skill útil não é um amuleto chamado resposta-perfeita.md.

Ela precisa declarar pelo menos:

• que problema sabe resolver;
• quais sinais devem acioná-la;
• que informações mínimas exige;
• quais fontes e ferramentas pode usar;
• quando pesquisar antes de afirmar e quando encaminhar o trabalho a outro especialista;
• que passos não podem ser pulados;
• que formato de saída entrega;
• como a qualidade será verificada;
• que autorização recebeu e quais ações continuam fora do escopo;
• quando deve parar e pedir julgamento humano.

A descrição é parte do comportamento. Se uma skill diz apenas “ajuda com pesquisa”, quase tudo pode acioná-la e quase nada define o que ela deveria fazer. Se diz que deve ser usada quando uma afirmação atual, uma escolha de fornecedor ou uma decisão de arquitetura depende de evidência externa, o agente tem uma fronteira mais útil.

O GitHub documenta que o agente pode selecionar uma skill pela descrição da tarefa. Isso não prova que a seleção será perfeita em qualquer ferramenta ou contexto. Prova algo mais modesto e mais importante para este artigo: já existe implementação concreta da ideia de carregar instruções especializadas no momento relevante, em vez de obrigar o usuário a colá-las manualmente em toda conversa.

Se Sylar representa a frustração de ter a capacidade e não acioná-la, Batman representa o uso positivo. Ele não é Batman apenas porque carrega um cinto de utilidades; é porque reconhece a ferramenta adequada, sabe como usá-la e a põe em ação no momento certo. É isso que uma skill bem integrada ao Harness precisa fazer pela operação — sem a capa, porque o orçamento também tem limites.

O pedido natural continua sendo necessário. O ritual inteiro, não.

Pesquisa profunda não deveria depender de eu lembrar de pedir pesquisa profunda

Se eu pergunto qual cor fica melhor num botão, talvez não seja necessário abrir uma expedição científica.

Se eu pergunto se uma arquitetura deve armazenar dados pessoais em outro país, responder apenas pelo que o modelo recorda seria irresponsável.

O usuário comum não deveria precisar conhecer o nome do modo de pesquisa, decidir quantas buscas fazer ou mandar o agente “raciocinar passo a passo”. O Harness pode reconhecer os sinais: assunto atual, decisão cara, risco jurídico, referência específica, informação incerta ou alegação que será publicada.

Nesse caso, ele aciona o processo adequado, informa que vai pesquisar e retorna não apenas uma conclusão, mas o caminho verificável até ela.

Isso não elimina uma pergunta essencial ao usuário:

O que você pretende decidir com essa pesquisa?

Sem objetivo, até uma pesquisa impecável pode resolver o problema errado com referências muito bonitas.

Passagem de contexto não é copiar a conversa inteira e rezar

Outro prompt recorrente é: “continue de onde paramos”.

De onde, exatamente?

Uma tarefa longa acumula decisões, arquivos, hipóteses, resultados de testes, pendências, autorizações e coisas que pareciam verdade três horas atrás. Copiar a conversa inteira transfere volume, não necessariamente contexto útil. É o telefone sem fio com anexo de 80 páginas.

Uma skill de passagem de contexto pode exigir um pacote mínimo:

• objetivo atual;
• estado real do trabalho;
• decisões já adotadas;
• hipóteses ainda abertas;
• arquivos e sistemas envolvidos;
• validações executadas;
• riscos, bloqueios e próximo passo;
• o que a nova tarefa está autorizada — e não autorizada — a fazer.

O usuário pode dizer “leva isso para outra tarefa”. O Harness deveria saber que “isso” não significa despejar tudo. Significa preservar o estado que permite continuar sem inventar continuidade.

“Revise” precisa significar mais do que reler com a mesma confiança

Quando eu peço uma revisão, não quero que a mesma resposta troque três adjetivos e volte usando óculos.

Uma skill de revisão precisa saber o objeto e o critério. Código pode exigir testes, análise do diff, compatibilidade e riscos. Um artigo pode exigir coerência autoral, fontes, links, afirmações fortes, tradução, leitura móvel e metadados. Uma decisão pode exigir que alguém procure premissas frágeis e alternativas que foram ignoradas.

O trabalho pode usar fluxos diferentes. A Anthropic descreve, em seu texto sobre construção de agentes eficazes, padrões como encadeamento, roteamento, execução paralela e um ciclo no qual uma etapa produz e outra avalia segundo critérios definidos. A empresa também recomenda começar pela solução mais simples que funcione e acrescentar complexidade apenas quando ela trouxer resultado mensurável.

Isso sustenta o padrão técnico, não uma promessa de qualidade automática. Um avaliador ruim pode aprovar uma resposta ruim com uma solenidade impressionante. O critério ainda precisa ser escrito, testado e revisto por pessoas que entendem o trabalho.

Dados sensíveis precisam mudar a rota antes de entrarem no prompt

“Resuma esta planilha” pode ser um pedido inocente.

A planilha pode conter salário, diagnóstico, documento, contrato, segredo comercial ou informação de alguém que nunca autorizou seu envio a um provedor externo.

Não é razoável esperar que todo colaborador se lembre, em cada conversa, de recitar a política de dados da empresa. Também não é razoável concluir que uma linha no prompt transforma um fluxo inseguro em seguro.

O Harness deveria classificar o contexto antes da ação e aplicar regras como:

• minimizar os dados usados;
• preferir processamento local ou ambiente aprovado quando exigido;
• remover identificadores que não sejam necessários;
• bloquear provedores ou ferramentas fora da política;
• pedir autorização quando a finalidade não estiver coberta;
• registrar o que foi transmitido sem copiar o conteúdo sensível para o log.

O perfil para riscos de IA generativa do Instituto Nacional de Padrões e Tecnologia dos Estados Unidos (NIST) trata gestão de risco como trabalho de governança, mapeamento, medição e gestão ao longo do ciclo de vida. Ele não oferece uma configuração universal para o seu Harness e não certifica que uma política em Markdown será obedecida. Serve aqui para sustentar a necessidade de contexto, responsabilidades, avaliação e monitoramento — não para terceirizar ao NIST uma decisão que continua sendo da organização.

Publicar não é sinônimo de terminar de escrever

Uma das diferenças mais importantes entre chatbot e operação é que gerar um artefato não concede automaticamente o direito de colocá-lo no mundo.

Se eu digo “prepare um post”, uma skill editorial pode pesquisar, escrever, revisar links, gerar imagem, validar o site e abrir uma versão para avaliação. Ainda assim, publicação pode exigir minha aprovação explícita.

Se eu digo “publique o próximo texto aprovado”, o Harness pode verificar:

• se há aprovação humana registrada;
• se a revisão técnica terminou;
• se a data representa a publicação real;
• se traduções, imagem e metadados estão completos;
• se existe dependência com outro conteúdo;
• se o ambiente de produção está saudável;
• se há um caminho de reversão.

Perceba a diferença: a skill não me obriga a lembrar de cada condição que precisa ser satisfeita antes de avançar — cada gate —, mas também não transforma minha frase em autorização infinita.

Isso vale para uma campanha, uma alteração de infraestrutura, um pagamento ou um e-mail. A ação final pode ser simples; as condições para chegar até ela não são.

O que continua sendo responsabilidade de quem pede

Eu quero eliminar coreografia inútil, não responsabilidade.

O usuário ainda precisa fornecer quatro coisas que nenhum pacote de instruções deveria inventar:

1. Objetivo

O que precisa mudar no mundo depois do trabalho?

“Analise os dados” é atividade. “Quero decidir se devo manter este produto” é direção.

2. Contexto que só ele conhece

Uma skill pode saber onde procurar os arquivos. Não sabe que o fornecedor prometeu uma condição fora do contrato, que a equipe perdeu uma pessoa ou que a prioridade mudou na reunião de ontem — a menos que isso tenha sido registrado e esteja acessível.

3. Restrições reais

Prazo, orçamento, privacidade, infraestrutura, risco aceitável, pessoas afetadas e o que não pode ser alterado. Se a restrição muda o caminho, ela precisa estar no pedido ou numa fonte de contexto confiável.

4. Decisão

O agente pode organizar evidência, mostrar cenários e apontar inconsistências. A decisão que compromete dinheiro, pessoas, reputação ou direção continua precisando de um responsável identificável.

Eu já escrevi que dados não decidem por nós. Skills também não.

O que continua sendo responsabilidade da organização

Uma empresa não “instala” skills e encerra o assunto.

Ela precisa observar o uso real:

• a habilidade está sendo acionada nos pedidos certos?
• deixa de aparecer quando deveria?
• pede contexto demais ou de menos?
• suas fontes continuam válidas?
• os scripts ainda funcionam?
• as validações encontram defeitos reais?
• os limites refletem a política atual?
• o custo e o tempo ainda fazem sentido?
• pessoas conseguem contestar e corrigir o resultado?

Contexto envelhece. Processo muda. Ferramenta é substituída. Uma skill que resolveu o problema de janeiro pode automatizar a regra aposentada de setembro com eficiência admirável.

A OpenAI relata, em seu artigo sobre engenharia de Harness, que concentrar tudo num AGENTS.md gigantesco gerou instruções demais, perda de contexto útil, envelhecimento e dificuldade de verificação. A direção descrita é usar o arquivo como mapa para fontes de verdade menores e estruturadas.

Não é uma lei universal, nem prova de que a mesma arquitetura serve para toda empresa. É um relato primário de implementação que combina com o problema: critérios operacionais precisam ser encontráveis, específicos e verificáveis. Um prompt de 40 páginas colado em toda conversa não é maturidade. É um gaveteiro despejado em cima da mesa.

O nome disso não é autonomia cega

Quando o sistema reconhece uma tarefa e aplica a habilidade adequada, parece que a IA “já sabe o que fazer”. A frase é conveniente, mas merece cuidado.

Ela não sabe como uma pessoa sabe. Ela recebe descrições, regras, ferramentas, contexto e sinais que aumentam a chance de escolher um caminho útil. Essa seleção pode falhar. A execução pode falhar. O ambiente pode ter mudado. Duas regras podem entrar em conflito.

Por isso um Harness confiável precisa incluir também:

• estados de incerteza;
• critérios de parada;
• permissões proporcionais ao risco;
• evidências do que foi executado;
• avaliações repetíveis;
• revisão humana nos pontos de impacto;
• reversão quando a ação modifica algo real.

A documentação da OpenAI sobre o Codex descreve AGENTS.md como uma forma de registrar organização do projeto, comandos de teste e práticas esperadas. A documentação também ressalta ambientes configurados, testes confiáveis e evidência verificável. Não é “escreva duas regras e confie para sempre”. É justamente o contrário: transforme expectativa em contrato e resultado em algo que possa ser conferido.

Como eu começaria sem construir a NASA para mandar um e-mail

Escolha uma tarefa recorrente que hoje depende de alguém lembrar muitos detalhes. Não comece pela mais crítica da empresa.

Pode ser preparar uma pesquisa, revisar uma proposta, organizar o contexto de uma reunião ou validar um artigo antes da avaliação.

Depois:

1. registre três exemplos bons e três ruins;
2. escreva quando a habilidade deve e não deve ser acionada;
3. defina as entradas mínimas e o que precisa ser perguntado;
4. transforme o processo real em passos curtos;
5. marque os gates que exigem decisão humana;
6. automatize apenas as verificações que podem ser comprovadas;
7. rode a habilidade nos exemplos;
8. revise os erros e atualize o contrato;
9. acompanhe se ela melhora consistência, tempo ou retrabalho;
10. retire a skill se ela só acrescentar cerimônia.

Um prompt inicial poderia ser:

Ajude-me a transformar esta tarefa recorrente em uma skill para o meu agente. Primeiro, identifique objetivo, sinais de acionamento, contexto mínimo, ferramentas, passos, formato de saída, validações, limites e decisões que continuam humanas. Use três casos reais que deram certo e três que deram errado. Não escreva a versão final antes de apontar ambiguidades e riscos. Depois proponha um teste pequeno, reversível e mensurável.

Isso ainda não produz uma skill confiável. Produz um primeiro artefato para discussão. A confiabilidade começa quando o texto encontra casos reais e sobrevive a eles.

A melhor interface pode voltar a ser uma frase normal

Eu invisto bastante tempo aperfeiçoando meus agentes para que, na hora de trabalhar, eu não precise gastar o mesmo tempo ensinando tudo de novo.

Essa é a parte aparentemente contraditória: por trás de um pedido simples pode existir um sistema complexo. Não porque eu queira esconder a complexidade com uma demonstração bonita, mas porque decidi onde ela deve morar.

Pesquisa tem contrato de pesquisa. Publicação tem gate de publicação. Dados sensíveis mudam a rota. Revisão procura defeitos segundo critérios. Passagem de contexto preserva estado. O agente recebe ferramentas compatíveis com a tarefa e para quando encontra uma decisão que é minha.

O mercado vai continuar vendendo o prompt definitivo da semana. Alguns serão úteis. Eu provavelmente vou aproveitar ideias de vários deles.

Só não quero depender de lembrar que o encantamento certo era Wingardium Leviosa — sem mandar um “Leviossáá” de Rony e ouvir da Hermione que “é Leviôssa, não Leviosá” — antes de cada trabalho.

Quero dizer o que preciso e fornecer o contexto que só eu tenho. O Harness reconhece a capacidade, aplica o roteiro e respeita as condições que já acordamos.

O prompt continua sendo a conversa.

O Harness é o que impede a conversa de precisar reinventar a empresa toda vez que eu abro a boca.

Se esse é o tipo de operação que você quer construir — menos ritual, mais contexto e resultado verificável —, conheça a I-9.ai.

Continue lendo

• O modelo é só o motor. O Harness de IA é o carro inteiro
• Seu agente sabe quando parar?
• Se ninguém sabe o que acontece depois, você não tem um workflow
• Meu Harness aprende, mas não ganha licença para reescrever o passado

Referências e limites de uso

• GitHub Docs — About agent skills: sustenta a definição de skill como pacote de instruções, scripts e recursos carregável para trabalho especializado. Não prova que o acionamento será correto em todo agente nem que uma skill será boa por existir.
• GitHub Docs — Adding agent skills for GitHub Copilot: sustenta o papel da descrição no acionamento e a distinção entre instruções gerais e skills específicas. Refere-se ao comportamento documentado do GitHub Copilot.
• Anthropic — Building Effective AI Agents: sustenta os padrões de roteamento, encadeamento, avaliação e orquestração, além da recomendação de começar simples. É experiência publicada por um fornecedor, não comparação independente de retorno empresarial.
• Anthropic — Effective context engineering for AI agents: sustenta a distinção entre otimizar um prompt isolado e cuidar do conjunto de instruções, ferramentas, memória, histórico e dados disponíveis ao agente. É orientação técnica do próprio fornecedor.
• NIST AI 600-1 — Generative Artificial Intelligence Profile: sustenta a abordagem de governança e gestão de risco ao longo do ciclo de vida. Não oferece uma arquitetura pronta nem certifica os controles descritos neste texto.
• OpenAI — Harness engineering: sustenta o relato sobre limites de um arquivo monolítico de instruções e o uso de documentação estruturada como fonte de verdade. É um caso de implementação da OpenAI, não regra universal.
• OpenAI — Introducing Codex: sustenta o uso de AGENTS.md, ambientes configurados, testes e evidência verificável no Codex. Não prova autonomia ou confiabilidade para qualquer tarefa fora do contexto descrito.