Novas competências para trabalhar com agentes

6.1. Entender a unidade técnica com que se trabalha

É útil distinguir modelo, agente e ambiente de execução. O modelo produz respostas e decisões de uso de ferramentas. O agente é o sistema que organiza essas interações ao longo de uma tarefa. O ambiente fornece arquivos, processos, rede, credenciais e recursos. O termo harness designa a infraestrutura que coordena o ciclo e suas interfaces.

Uma deficiência pode estar em qualquer camada. Um agente pode ter capacidade de raciocínio suficiente e falhar porque não consegue executar o teste, recebeu documentação antiga ou perdeu o estado do trabalho. Essa distinção permite corrigir a causa adequada, em vez de apenas mudar o texto do pedido.

Fluência mínima esperada: compreender janela de contexto, recuperação de informações, uso de ferramentas, variabilidade entre execuções, orçamento de tempo e custo, permissões, persistência de estado e limites do ambiente. Saber usar uma ferramenta de ponta a ponta é mais útil que conhecer superficialmente muitos nomes.

6.2. Especificar trabalho delegável

Uma tarefa delegável precisa esclarecer o resultado e as condições em que será considerado correto. Quanto maior a autonomia pretendida, mais importante é explicitar as ambiguidades que alteram a solução.

Um bom contrato de tarefa responde:

1. Qual resultado queremos e para quem?
2. Que comportamento precisa existir?
3. Quais invariantes e restrições devem ser preservados?
4. Quais fontes de contexto são confiáveis?
5. Qual é o perímetro da alteração?
6. Que evidências demonstrarão conclusão?
7. Que situação exige decisão humana?

Essa explicitação pode caber em poucas linhas para uma correção simples. Para uma mudança ampla, pode exigir desenho de interfaces, exemplos, decisões de domínio e plano de migração. O objetivo é reduzir incerteza relevante, não produzir documentos por volume.

O Spec Kit, publicado pelo GitHub em 2025, é um exemplo de ferramenta que organiza especificação, planejamento, tarefas e implementação. A capacidade durável é formular intenção verificável; a adoção daquele kit específico é uma escolha de processo. F27

Também é preciso saber o que deixar em aberto. Especificar o limite de latência e o contrato de uma operação pode ser necessário; escolher antecipadamente cada classe pode reduzir a liberdade do agente sem melhorar o resultado. Bons contratos restringem propriedades importantes e permitem explorar a implementação.

6.3. Engenharia de contexto

Engenharia de contexto é organizar a informação disponível ao agente durante o trabalho: requisitos, regras, código, documentação, ferramentas, resultados de execução e estado da tarefa. A Anthropic descreve essa atividade como uma curadoria contínua, com recuperação sob demanda e manutenção de informação pertinente. F17

A aplicação prática proposta aqui tem três camadas:

O engenheiro deve identificar a fonte de autoridade de cada informação. Uma decisão de arquitetura vigente, uma hipótese registrada em uma investigação e uma sugestão encontrada em uma issue não têm o mesmo peso.

Cada documento importante precisa ter um propósito e algum mecanismo de atualização. Quando houver conflito, deve existir um caminho para resolvê-lo. Acumular instruções antigas e contraditórias aumenta o trabalho de interpretação.

Um detalhe de alto valor é tornar resultados recuperáveis: caminhos de arquivos, identificadores de testes, versão do código e links para decisões. Um resumo que diz “os testes passaram” é menos útil que um registro que permite localizar quais testes, sobre qual versão e com que resultado.

6.4. Preparar o repositório para execução independente

O relato da OpenAI sobre harness engineering descreve um arquivo de orientação curto, funcionando como mapa para documentação mais detalhada, além de ambientes isolados e acesso a sinais de execução. Esse caso ilustra a importância de tornar o projeto compreensível e operável pelos agentes. F06

Como proposta prática, um repositório preparado deve permitir que um novo executor descubra como instalar dependências, iniciar o sistema, executar verificações pertinentes e entender limites arquiteturais. Deve também oferecer dados de teste adequados e explicar o que fazer quando uma dependência externa não estiver disponível.

Isso não exige transferir todo conhecimento da empresa para um único arquivo. O trabalho consiste em construir caminhos confiáveis até a informação necessária e eliminar passos que dependam de memória pessoal ou de intervenção manual repetida.

Teste de prontidão: uma pessoa da equipe que não conhece o módulo, ou um agente em uma sessão nova, consegue reproduzir uma falha e executar a validação relevante usando as instruções disponíveis? As dificuldades encontradas são oportunidades concretas de melhoria.

6.5. Ferramentas, APIs, CLI e MCP

O engenheiro deve entender como conectar agentes às ações e informações de que precisam. Isso inclui ferramentas de linha de comando, APIs, conectores e protocolos como MCP, conforme o ambiente utilizado.

O desenho da interface importa: nomes claros, argumentos tipados, resultados compreensíveis, erros úteis e operações delimitadas facilitam o uso. O artigo da Anthropic sobre ferramentas recomenda testar esses contratos em tarefas realistas e reservar casos para avaliar alterações. F18

Uma ferramenta de implantação, por exemplo, pode exigir ambiente, versão e identificador de operação, devolver um estado consultável e permitir distinguir “solicitação aceita” de “implantação concluída”. Uma interface que apenas executa um comando e retorna texto livre pode tornar essa distinção mais difícil.

O critério para adotar MCP ou construir uma ferramenta própria é resolver uma necessidade de integração. Uma CLI existente e bem documentada pode ser suficiente. O profissional deve conhecer as opções e avaliar manutenção, autorização, observabilidade e ergonomia; não precisa envolver toda operação em um novo framework.

6.6. Procedimentos reutilizáveis e skills

Uma skill pode reunir instruções, scripts, exemplos e recursos para um tipo de trabalho. A proposta de Agent Skills publicada pela Anthropic usa carregamento progressivo dessas informações para especializar a execução conforme a tarefa. F19

Um bom ponto de partida é uma dificuldade recorrente. Se toda migração exige os mesmos passos delicados, eles podem virar um procedimento verificável. Se toda investigação de desempenho exige localizar os mesmos sinais, um recurso compartilhado pode reduzir a preparação.

Uma skill deve ter critérios de uso, entradas, resultado esperado e verificação. Precisa ser testada em casos representativos e revisada quando o ambiente mudar. Um conjunto de instruções que parece sensato, mas nunca foi exercitado, ainda é uma hipótese de processo.

É útil separar orientação de execução determinística. Quando uma transformação já pode ser realizada por uma função ou script confiável, o agente pode selecionar e operar essa ferramenta, sem regenerar sua lógica em cada uso.

6.7. Decomposição, paralelismo e integração

O engenheiro precisa reconhecer dependências antes de distribuir tarefas. Frentes independentes podem avançar em paralelo; decisões compartilhadas ainda indefinidas precisam ser resolvidas ou ter um responsável claro.

Boas candidatas a paralelismo: investigar subsistemas distintos, revisar riscos diferentes, explorar alternativas arquiteturais e implementar módulos contra interfaces já acordadas.

Situações que pedem cuidado de coordenação: vários agentes alterando a mesma infraestrutura, versões incompatíveis de uma API, migrações dependentes ou uma causa comum que bloqueia todas as frentes.

Na revisão de abril de 2026, Towards a Science of Scaling Agent Systems encontrou desempenho dependente da combinação entre arquitetura, tarefa e recursos, incluindo perdas em configurações mal alinhadas. O estudo oferece uma razão empírica para tratar coordenação como escolha de engenharia. F21

Uma prática útil é definir dono de cada alteração, contratos de integração e pontos de sincronização. Worktrees ou clones separados, cada um com sua branch, e ambientes isolados reduzem colisões de arquivos e execução. Branches, sozinhas, não isolam dois processos no mesmo diretório de trabalho. A integração ainda precisa verificar a semântica do conjunto: duas mudanças podem compilar separadamente e contradizer a mesma regra de negócio.

6.8. Gerenciar continuidade e economia da execução

Trabalho autônomo prolongado exige estado persistente, critérios de parada, limites de custo e mecanismos de recuperação. O engenheiro precisa saber quando retomar uma execução, quando reiniciar com contexto melhor e quando pedir uma decisão que falta.

Em março de 2026, a Anthropic descreveu uma arquitetura com planejamento, geração e avaliação separados para desenvolvimento prolongado de aplicações. O relato também mostra que melhorias de modelos podem tornar desnecessários componentes de um harness anterior. A implicação é revisar o processo junto com a evolução das ferramentas. F07

Como regra de projeto, registre objetivo, progresso comprovado, decisões, bloqueios e próxima ação. Interrompa ciclos sem progresso observável. Um agente que repete a mesma tentativa precisa de diagnóstico, informação nova ou uma tarefa diferente.

O custo relevante inclui inferência, ferramentas, CI, espera e atenção humana. O modelo mais barato por chamada pode sair caro se exigir muitas correções. A escolha deve considerar custo por resultado aceito e qualidade no conjunto de tarefas real.