Do prompt à Era Maestro — camadas que se acumulam

Uma pergunta que parece histórica, mas é operacional

Você abre uma conversa e escreve: “crie um sistema de manutenção”. A resposta produz telas, código e uma lista de tecnologias. Parece avanço. Porém, ninguém definiu quem pode concluir uma ordem de serviço, como provar que uma reserva no ERP não será duplicada ou o que fazer quando a rede cair. O problema não é apenas um prompt ruim. Faltam contexto confiável, regras de negócio, ferramentas controladas, critérios de aceite e verificação.

Esse exemplo explica por que a evolução do trabalho com IA não pode ser narrada como “primeiro prompts, depois skills, depois agentes”. As camadas continuam existindo ao mesmo tempo. Um agente ainda recebe instruções; uma skill ainda precisa de contexto; um harness ainda usa modelos; uma avaliação ainda depende de um requisito. A pergunta profissional é: qual camada resolve qual problema e quem responde por ela?

Você não precisa saber programar para acompanhar este capítulo. Ao final, deverá conseguir desenhar as camadas de um sistema assistido por IA, escolher a arquitetura mínima para três tarefas e justificar quando a complexidade adicional não compensa.

Vocabulário antes do mapa

• Prompt: entrada que orienta uma execução do modelo. Tradução literal: instrução ou estímulo. Não é sinônimo de especificação completa.
• Context engineering: seleção, organização e atualização das informações disponíveis durante uma execução. Não significa enviar tudo o que existe.
• RAG (Retrieval-Augmented Generation): recuperação de trechos relevantes antes de gerar uma resposta. A recuperação pode trazer evidência e também conteúdo malicioso.
• Tool use: capacidade de o modelo solicitar uma função externa, como ler um arquivo ou consultar uma API. Escolher uma ferramenta não concede autorização para usá-la.
• Workflow: sequência cujo caminho principal é definido pelo programa.
• Agent: sistema em que o modelo participa dinamicamente da escolha dos próximos passos e ferramentas dentro de limites externos.
• Skill: pacote de instruções e recursos para um procedimento repetível, carregado quando a tarefa combina com seu gatilho.
• MCP (Model Context Protocol): protocolo aberto para conectar clientes de IA a ferramentas e contexto. Não é memória, modelo nem selo de confiança.
• Harness: software e convenções ao redor do modelo: contexto, ferramentas, permissões, estado, orçamento, avaliações, rastreamento e parada.
• Eval: caso de avaliação que mede um comportamento definido. Pode usar código, um modelo julgador ou revisão humana.
• Observability: capacidade de reconstruir o que aconteceu por registros, métricas e rastros.

Modelo mental: uma oficina que ganha controles

Imagine uma oficina. O modelo é um trabalhador capaz, mas não conhece automaticamente a planta, não possui todas as chaves e não decide sozinho o que pode sair do estoque. O prompt é a ordem de trabalho; o contexto são os manuais e dados selecionados; as ferramentas são os instrumentos; a skill é o procedimento; o agente é o trabalhador que escolhe passos; o harness é a oficina organizada, com áreas permitidas, checklists, supervisão e registro; os evals são ensaios que comprovam o resultado.

A analogia tem limite: modelos não têm compreensão, intenção ou responsabilidade jurídica equivalentes às de uma pessoa. Ela serve apenas para separar capacidades e controles.

Leia da esquerda para a direita. O desenho não afirma uma cronologia exata nem que toda tarefa precisa de todas as caixas. Ele mostra dependências: sem objetivo não há critério de relevância; sem limite uma ferramenta aumenta risco; sem avaliação, adicionar agentes apenas aumenta movimento.

As etapas da evolução prática

1. A era do prompt: melhorar uma interação

O foco inicial era formular instruções melhores: papel, contexto, exemplos, formato e restrições. Isso continua útil. Um bom pedido inclui objetivo, contexto relevante, restrições e “pronto quando”. O erro é esperar que palavras resolvam ausência de dados, autoridade ou teste.

Quando basta: explicar um conceito, transformar um texto fornecido ou sugerir hipóteses que uma pessoa verificará.

Limite: o modelo não vê o repositório, não executa o produto e não possui prova independente só porque recebeu uma persona detalhada.

2. Copilotos, busca e RAG: aproximar evidência

O modelo passa a receber código, documentos ou resultados recuperados. Isso reduz a distância entre pergunta e fonte. Contudo, contexto maior não significa contexto melhor. Arquivo desatualizado, duplicado ou malicioso continua sendo uma entrada ruim.

No sistema de manutenção, o assistente pode recuperar o procedimento do equipamento. A resposta só deve citar trechos autorizados e abster-se quando não houver evidência. RAG não cria permissão nem garante verdade.

3. Ferramentas e workflows: produzir efeitos delimitados

Uma ferramenta converte uma intenção em uma chamada estruturada. Um workflow fixa a ordem quando o processo é conhecido: validar a OS, consultar estoque, reservar peça e registrar auditoria. Código convencional deve controlar regras determinísticas; não faz sentido pedir ao modelo para “julgar” se um campo obrigatório está vazio.

4. Agentes: decidir próximos passos dentro de limites

Um agente observa o estado, escolhe uma ação permitida, recebe o resultado e decide se continua. Flexibilidade custa latência, tokens e superfície de falha. A Anthropic distingue workflows, com caminhos predefinidos, de agentes, nos quais o modelo dirige dinamicamente o processo, e recomenda começar pela solução mais simples que atenda ao caso.

5. Skills e engenharia de contexto: tornar trabalho reutilizável

Quando o mesmo procedimento é repetido, ele deixa de caber bem em prompts improvisados. Uma skill registra gatilho, entradas, passos, saída, verificações e parada. Regras sempre relevantes ficam em instruções do repositório; detalhes sob demanda ficam na skill. Memória ajuda a recordar, mas não substitui fonte de verdade versionada.

6. MCP: conectar capacidades externas por um contrato

MCP padroniza como ferramentas e recursos são expostos. Use-o quando dados mudam fora do repositório ou uma ação externa precisa ser integrada de modo repetível. Um arquivo estático de arquitetura não precisa de MCP; um serviço de chamados atualizado pode precisar.

Servidor instalado não é servidor confiável. A especificação de autorização exige tokens destinados ao recurso correto; encaminhar o token recebido para outro serviço é um antipadrão. Esse tema será aprofundado no volume de segurança.

7. Harness engineering: projetar o ambiente, não apenas a instrução

À medida que modelos executam trabalho longo, o gargalo muda. A OpenAI descreve equipes humanas especificando intenção e construindo ambientes legíveis e verificáveis para agentes. A Anthropic mostra que decomposição, artefatos de handoff e avaliadores separados podem aumentar a qualidade, mas também registra grande custo e a necessidade de remover partes do harness que modelos mais capazes deixaram de precisar.

Portanto, harness engineering não é empilhar mecanismos. É transformar necessidades reais em interfaces, políticas e feedback mensuráveis.

8. Era Maestro: governar o sistema completo

“Maestro” é a metáfora deste Grimório para a pessoa que projeta o sistema de trabalho. Ela não precisa escrever cada linha, mas continua responsável por:

1. definir o problema e os limites;
2. tornar o repositório legível;
3. escolher o fluxo mínimo;
4. definir avaliações antes da construção;
5. limitar ferramentas e aprovações;
6. interpretar evidências e riscos;
7. transformar falhas recorrentes em testes ou regras;
8. remover complexidade que não traz ganho.

Como era e como funciona atualmente

Ênfase anterior	Prática atual recomendada	O que permaneceu
prompt longo contendo tudo	instrução curta + fontes de verdade + contexto sob demanda	objetivo claro e exemplos ainda ajudam
uma tentativa e inspeção visual	execução, checks determinísticos e avaliação independente proporcional	revisão humana continua necessária
agente único com permissão ampla	ferramenta mínima, política externa e aprovação para alto impacto	o modelo ainda propõe ações
multiagente como sinal de sofisticação	paralelismo apenas para partes independentes ou perspectivas necessárias	decomposição continua valiosa
histórico como memória total	documentos versionados, handoff e memória seletiva com proveniência	continuidade ainda precisa ser preservada

Três decisões concretas

Caso A — explicar HTTP: S0. Uma conversa com exemplo e recuperação ativa é suficiente. Criar quatro agentes e um juiz aumentaria custo sem criar evidência relevante.

Caso B — corrigir validação de formulário: S1. Um agente lê o código, altera uma fatia pequena, executa teste e revisão do diff. Não precisa de MCP se tudo está no repositório.

Caso C — criar autenticação para um portal corporativo: S2 ou S3 conforme risco. Antes do código, exige requisitos, ameaça, critérios, testes de integração e revisão independente. A implantação em produção permanece sujeita à aprovação humana.

Falhas comuns e diagnóstico

Sintoma	Causa provável	Verificação	Correção
prompt cresce a cada erro	regra durável no lugar errado	a regra vale para todo trabalho?	mover para documento, skill ou teste
agente repete ações	ausência de estado ou parada	trace mostra o mesmo passo?	limite, idempotência e condição de parada
vários agentes produzem conflitos	trabalho não era independente	arquivos e decisões se sobrepõem?	serializar ou usar fronteiras/worktrees
resposta cita documento proibido	recuperação ignorou ACL	testar usuário de outro escopo	filtrar antes e depois da recuperação
“funciona” sem execução	autoavaliação virou prova	existe comando e saída registrados?	marcar UNVERIFIED e preparar a ferramenta

Exercício e evidência

Classifique três tarefas reais suas. Para cada uma, entregue uma tabela com objetivo, camada mínima, ferramenta necessária, risco, prova e condição de parada. Em seguida, escolha uma tarefa e retire uma camada. Se a evidência continuar suficiente, a camada era excesso; se uma garantia concreta desaparecer, registre por que ela é necessária.

O exercício está concluído quando outra pessoa consegue repetir sua classificação e chegar à mesma decisão usando os critérios — não quando você apenas escreve “S2”.

Recuperação ativa

Sem voltar ao texto, responda: por que agente não substitui prompt? Qual diferença entre workflow e agente? Quando uma skill é melhor que AGENTS.md? O que MCP fornece e o que não garante? Por que um harness deve poder diminuir? Quem autoriza uma ação crítica?

No próximo capítulo, esse mapa será usado para transformar uma ideia pequena em um primeiro projeto observável.

Fotografia de 2026: o que realmente mudou

Em 2026, a mudança mais importante não foi o surgimento de uma nova palavra para prompt. O trabalho passou a ser tratado como um sistema observável. A OpenAI descreveu harness engineering como o desenho do ambiente, das restrições e dos ciclos de feedback que permitem aos agentes executar trabalho confiável. Meses depois, publicou a especificação Symphony, na qual um quadro de projeto funciona como plano de controle e cada tarefa é executada em um espaço isolado. O Agents SDK passou a oferecer sandbox nativo e um manifesto portátil do workspace. Essas peças aproximam o desenvolvimento do modelo intenção → execução isolada → prova, mas não removem requisitos, Git, testes ou responsabilidade humana.

A Anthropic chegou a uma conclusão complementar. Ao separar planejador, construtor e avaliador, obteve ganho em aplicações longas e em design subjetivo; porém, também observou que o avaliador pode virar sobrecarga quando um modelo mais capaz já resolve a tarefa com confiabilidade. Em Managed Agents, a empresa separa sessão, harness e sandbox e alerta que as suposições do harness envelhecem. Portanto, a arquitetura correta é adaptativa: mede onde o modelo falha, adiciona o menor controle capaz de detectar a falha e revisita esse controle após mudanças de modelo.

O loop contemporâneo, sem mistério

Leia o fluxo como uma cadeia de responsabilidade. O transcript explica o caminho percorrido, mas o outcome é o estado final do ambiente. Um agente pode escrever “reserva criada”; o teste precisa confirmar a reserva no banco. Um agente pode declarar “layout acessível”; o navegador, o teclado e a auditoria de contraste precisam comprovar a afirmação.

O que permanece experimental

Agentes de longa duração e agent swarms ampliam a quantidade de trabalho que pode ser tentada, mas continuam sendo arquiteturas S3. A Cursor relatou árvores de decomposição, planners, workers, memória compartilhada, revisão por lentes e controle de versão especializado. Também registrou conflitos, custo alto e resultados de prova de conceito. Use múltiplos agentes somente quando as partes forem independentes ou quando uma perspectiva realmente precisar de contexto separado. Para uma alteração pequena, um agente, um teste e uma revisão continuam superiores a um enxame.

Critério de atualização

Toda prática volátil deste capítulo precisa responder a quatro perguntas: qual produto e versão foram observados, em que data, qual evidência sustenta a recomendação e qual teste mostraria que ela deixou de ser útil. Sem essas respostas, “prática moderna” vira apenas moda recente.

Fontes atuais: OpenAI — Harness engineering, OpenAI — Symphony, OpenAI — evolução do Agents SDK, Anthropic — harnesses para aplicações longas, Anthropic — avaliações de agentes e Anthropic — Managed Agents.