A maioria das experiências com agentes começa da mesma forma.
Escrevemos um prompt. Testamos. Ajustamos. Ligamos uma ferramenta. Voltamos a testar. O resultado parece bom e alguém pergunta: “podemos pôr isto a correr automaticamente?”
É precisamente aí que o prompt deixa de chegar.
Um prompt consegue explicar ao agente como deve pensar ou responder. Mas não resolve sozinho perguntas como:
- quem é responsável pelo agente;
- que dados pode consultar;
- que propriedades pode alterar;
- que ações exigem aprovação;
- quanto pode gastar;
- quando deve desistir e escalar;
- como medimos qualidade;
- como o desligamos sem partir o processo.
Essas perguntas já não pertencem apenas ao prompt. Pertencem ao desenho operacional.
Tese RevOpsHubs
Um agente em produção precisa de um contrato operacional: uma definição explícita do trabalho, contexto, autonomia, risco, economia e responsabilidade sob os quais pode operar.
O que é um Agent Operating Contract?
O Agent Operating Contract é um framework RevOpsHubs. Não é um contrato jurídico, nem um documento técnico de dezenas de páginas.
É uma ficha operacional, idealmente de uma página, que acompanha cada agente que passa de experiência para piloto ou produção.
Serve para transformar uma coisa vaga — “temos um agente que ajuda Sales” — numa unidade de trabalho governável.
O contrato deve conseguir ser lido por RevOps, pelo owner do processo e por quem administra a tecnologia. Se só o builder do agente o consegue compreender, ainda está demasiado técnico.
As 10 decisões do contrato
Propomos dez blocos. A ordem é deliberada: o prompt aparece depois de sabermos que trabalho estamos realmente a delegar.
Objective — que resultado deve produzir?
Não “ajudar vendas”. Algo observável: preparar um briefing antes da reunião, classificar um pedido de entrada, identificar risco numa oportunidade, atualizar dados específicos.
Owner — quem responde pelo desempenho?
Uma pessoa concreta deve decidir qualidade aceitável, rever falhas e aprovar mudanças relevantes. O builder técnico pode não ser o owner do resultado.
Context — que informação pode usar?
Defina sistemas e fontes: CRM, notas, emails, documentos, knowledge base, web, ERP. Contexto disponível não significa contexto permitido.
Tools — que capacidades tem?
Pesquisar, criar tarefa, atualizar propriedade, enviar email, chamar API, usar MCP. Ferramentas são poder operacional; devem ser listadas explicitamente.
Permissions — onde pode ler e escrever?
Objetos, propriedades, sistemas e âmbitos. “Acesso ao HubSpot” é demasiado genérico. Ler Deals e alterar Deal Stage são capacidades muito diferentes.
Approval — onde tem de pedir autorização?
Defina ações autónomas, ações com aprovação e ações proibidas. OpenAI suporta pausas para human review em tool calls sensíveis; o princípio é mais importante do que a tecnologia escolhida.
Budget — quanta capacidade pode consumir?
Runs, créditos, tokens, tempo de computação ou chamadas externas. Com pricing por consumo, o orçamento faz parte do design do agente e não apenas da compra de software.
Quality — como sabemos que está a funcionar?
Defina métricas de resultado e de qualidade. Não apenas “número de execuções”. Precisão, aceitação sem correção, retrabalho, tempo poupado, conversão ou custo por resultado.
Escalation — quando deve parar e passar a um humano?
Dados em falta, regras em conflito, baixa confiança, exceções comerciais, número máximo de tentativas ou ações de risco. Um agente fiável também sabe quando não deve continuar.
Rollback — como voltamos atrás?
Como desativar, revogar ligações, retirar escrita, restaurar dados ou voltar à versão anterior? A saída deve existir antes da entrada em produção.
Então o prompt deixa de ser importante?
Não. Torna-se mais importante porque deixa de carregar responsabilidades que não lhe pertencem.
As próprias ferramentas de agentes estão a separar estas camadas. Na OpenAI, uma definição de agente pode incluir instruções, ferramentas, guardrails, MCP, handoffs e outputs estruturados. Os mecanismos de aprovação podem interromper uma execução antes de uma ação sensível. A HubSpot, por sua vez, permite configurar ferramentas MCP, simular execuções e definir limites mensais.
O prompt é uma parte do contrato. Não é o contrato.
Prompt engineering diz ao agente como trabalhar. Operating design decide que trabalho pode existir e sob que limites.
Exemplo: agente de qualificação inbound em HubSpot
Imagine uma empresa B2B com HubSpot que recebe pedidos de contacto pelo site. O objetivo é reduzir o trabalho manual de pesquisa e preparar melhor a primeira resposta comercial.
Um contrato operacional simples poderia ser assim:
Repara no que não está aqui: uma descrição de 200 linhas sobre personalidade, tom ou estilo.
Isso pode existir. Mas o que transforma este agente em parte confiável do Revenue System são sobretudo os limites operacionais.
Nem todos os agentes precisam do mesmo nível de governance
Um contrato de uma página não deve transformar-se em burocracia universal. A profundidade deve acompanhar a superfície de risco.
Pesquisa e recomendação
Consulta contexto e produz sugestões, sem escrever em sistemas nem contactar clientes. Contrato leve, logs e owner continuam necessários.
Altera trabalho interno
Atualiza propriedades, cria tarefas, notas ou tickets. Exige permissões explícitas, simulação, auditoria e rollback.
Age sobre clientes ou dinheiro
Envia, publica, elimina, compromete preço, altera estados críticos ou executa ações difíceis de reverter. Aprovação e guardrails devem ser muito mais fortes.
Esta classificação liga diretamente ao nosso Shadow Agent Risk Model: quanto maior a superfície de contexto, ferramentas, escrita e custo, mais explícito precisa de ser o contrato.
O contrato também define como testar
Um erro frequente é testar apenas se o agente produz uma boa resposta.
Em produção, precisamos de testar o sistema completo:
- selecionou a ferramenta certa?
- recusou uma ação que estava fora do âmbito?
- pediu aprovação quando devia?
- escalou quando faltava contexto?
- manteve-se dentro do orçamento e do número de runs?
- o resultado melhorou o processo ou apenas criou mais revisão?
A OpenAI recomenda avaliações de workflows através de traces, tool calls, guardrails e handoffs, em vez de avaliar apenas a resposta final. A HubSpot permite simular agentes sem executar alterações no CRM e sem consumir créditos, o que torna possível testar o comportamento antes de escalar.
O contrato fornece precisamente os critérios contra os quais o teste deve ser feito.
O orçamento passa a ser uma propriedade do agente
Esta parte ainda é nova para muitas equipas de RevOps.
Até agora, o custo de um workflow era muitas vezes invisível depois de comprada a licença. Com agentes, começa a haver uma relação mais direta entre trabalho executado e consumo.
No caso da HubSpot, o novo modelo EMEA já torna os créditos uma unidade explícita de capacidade. A própria plataforma recomenda simular execuções para estimar custo e definir limites mensais.
Isto significa que “budget” deixa de ser um campo administrativo. Passa a ser parte do comportamento permitido.
Um agente que pode correr 500 vezes por dia não é operacionalmente igual a um agente limitado a 20 casos prioritários.
O que faria na segunda-feira de manhã
Escolha um agente que já esteja em teste ou que alguém queira colocar em produção.
- Escreva o objetivo numa frase que tenha um resultado observável.
- Nomeie um owner de negócio.
- Liste as fontes de contexto e elimine as que não são necessárias.
- Liste todas as tools e marque read/write.
- Defina três colunas: autónomo, requer aprovação, proibido.
- Defina um limite de utilização para o piloto.
- Escolha duas métricas: uma de qualidade e uma de resultado.
- Escreva as condições de escalamento.
- Teste 20–50 casos representativos, incluindo exceções.
- Documente como desligar ou recuar.
Se não conseguir preencher estes pontos, ainda não tem um problema de prompt. Tem um problema de desenho operacional.
Os agentes precisam de liberdade. Mas liberdade delimitada.
Um agente que pede autorização para tudo não é particularmente útil. Um agente que pode fazer tudo também não é particularmente governável.
O espaço interessante está no meio.
Dar autonomia suficiente para retirar trabalho humano, mas tornar explícitos contexto, permissões, risco, economia e responsabilidade.
É isso que o Agent Operating Contract tenta resolver.
Não coloque um agente em produção porque o prompt ficou bom. Coloque-o em produção quando o sistema à volta dele estiver claro.