Navegue neste artigo
Um modelo que responde bem ainda precisa de uma estrutura para trabalhar. Veja como desenhar essa base usando uma consulta de pedidos como exemplo.
Comece por uma tarefa, não por um agente
Imagine uma equipe de atendimento que precisa consultar pedidos e preparar uma resposta ao cliente. O objetivo não é dar acesso completo ao sistema: é reduzir o tempo de consulta sem permitir que uma conversa altere pagamentos ou exponha dados de outra conta.
Este exemplo é didático. Antes de implementar algo semelhante, você precisa conhecer o processo, identificar quem pode consultar cada dado e ter um ambiente de teste com registros fictícios.
O que o harness faz
Harness é o sistema de execução ao redor do modelo: entrega contexto, disponibiliza ferramentas, aplica permissões e registra o que aconteceu. O modelo pode propor uma ação; o sistema decide se ela é válida e autorizada. Um prompt dizendo ‘não altere pagamentos’ não substitui uma restrição no backend.
Harness Engineering é o trabalho de projetar, testar e manter essa estrutura. Pode apoiar quem desenvolve software, mas também equipes de atendimento, comercial, financeiro e operações. O processo muda; a necessidade de limites e rastreabilidade permanece.
- Contexto: instruções, referências e dados relevantes para a tarefa.
- Ferramentas: operações pequenas, com entrada validada e retorno previsível.
- Permissões: identidade, escopo e isolamento aplicados fora do modelo.
- Execução: limites de tempo, custo, tentativas e condições de parada.
- Avaliação: testes de comportamento, registros e revisão humana.
Desenhe a ferramenta antes de escrever o prompt
Uma ferramenta chamada consultar_pedido é mais fácil de limitar do que uma conexão que executa qualquer SQL. Ela recebe um identificador, valida a identidade autenticada e retorna apenas os campos necessários. A empresa autorizada vem da sessão no servidor, nunca de um valor escolhido pelo modelo.
O contrato abaixo descreve uma política; não é uma configuração pronta de SDK. A implementação precisa garantir cada regra no serviço que executa a ferramenta.
tool: consultar_pedido
input: { pedido_id: string }
identity: authenticated_session
scope: session.company_id
permissions: [orders.read]
output: [status, estimated_delivery]
limits: { timeout_ms: 3000, max_attempts: 2 }
audit: [actor_id, tool, outcome, duration]Consultar, preparar e executar são permissões diferentes
A consulta pode ser automática quando autorizada. Uma mensagem para o cliente pode começar como rascunho. Um reembolso exige outra ferramenta e uma decisão explícita de uma pessoa habilitada. Aprovar um texto não deve autorizar ações futuras sem limite.
Vincule a aprovação à ação exata, aos parâmetros e à identidade do aprovador. Se a proposta mudar, peça nova aprovação. Documentos, páginas e mensagens retornados pelas ferramentas são dados externos, não instruções confiáveis para mudar essas regras.
- Atendimento: localizar o pedido e sugerir resposta, sem alterar a compra.
- Comercial: preparar uma proposta, sem conceder desconto fora da política.
- Financeiro: comparar registros, sem autorização para efetuar pagamentos.
- Operações: classificar uma solicitação e encaminhá-la ao responsável.
Teste também quando a resposta deve ser não
Monte casos com pedido inexistente, usuário sem permissão, pedido de outra empresa, ferramenta indisponível e uma mensagem tentando mudar as regras. Verifique a resposta ao usuário e os efeitos no sistema. Uma resposta educada não compensa uma consulta indevida.
Compare o fluxo assistido com o processo atual usando os mesmos casos. Observe tempo até a resolução, correções humanas, falhas de ferramenta e custo por tarefa concluída. Defina critérios de aceite antes de avaliar; não transforme uma única demonstração em promessa de qualidade.
Logs também podem expor dados. Registre o necessário, remova segredos e defina acesso, retenção e descarte.
Crie uma base que outras áreas consigam usar
Uma base compartilhada pode oferecer autenticação, catálogo de ferramentas aprovadas, modelos de avaliação e registro de versões. Cada área descreve seu processo, propõe uma melhoria e testa dentro desses limites. A equipe de engenharia mantém a fundação; quem conhece a operação participa dos critérios de qualidade.
Comece com uma tarefa pequena em modo de consulta ou rascunho. Faça a equipe revisar os resultados, ajuste o contrato e amplie a autonomia somente quando houver evidência. Vários agentes não são requisito: uma execução simples pode resolver o problema com menos pontos de falha.
Fontes e leituras relacionadas
Material educativo. Valide os exemplos em um ambiente de teste e adapte as decisões ao contexto, aos riscos e às responsabilidades do seu projeto.
Compartilhar