O que os agentes nunca devem fazer sozinhos.

A pergunta que mais ouvimos a quem gere operações não é “o agente consegue fazer isto?”. É “o que o impede de fazer asneira?”. Um prompt melhor não chega. Precisas de uma lista curta de regras, escrita por quem responde pelo risco, que o agente não consegue contornar com conversa.

Escrever essas regras dá menos trabalho do que parece. Quase tudo o que deve ficar com uma pessoa cabe em três tipos de decisão.

Três tipos de decisão

Dinheiro. Reembolsos, créditos, descontos, preços, pagamentos. Tudo o que faz entrar ou sair dinheiro do negócio, ou muda o que um cliente paga.

Promessas. Uma data de entrega, uma substituição, uma exceção à política. Tudo o que compromete a empresa com um cliente ou um fornecedor. Uma resposta errada corrige-se. Uma promessa errada tens de a cumprir ou de a quebrar.

Tudo o que não se pode desfazer. Apagar registos, enviar para toda a base de clientes, cancelar ou alterar uma encomenda que já vai a caminho. Se o erro não se desfaz com um clique, decide uma pessoa.

O resto costuma ser seguro para um agente fazer sozinho, desde que fique à vista depois: ler, classificar, preparar rascunhos, consultar, resumir, encaminhar.

Preparar, depois executar

A distinção mais útil nas regras de aprovação é entre preparar uma ação e executá-la. Um agente pode fazer todo o trabalho de um reembolso: encontra a encomenda, confirma a política, calcula o valor, escreve a resposta. Depois para, e uma pessoa executa-o com um toque.

Assim ficas com quase toda a poupança de tempo e quase nenhum risco. A pessoa não está a fazer o trabalho. Está a verificar uma proposta acabada, com a encomenda, a política e o valor no mesmo ecrã.

Com o tempo, alguns rascunhos ganham o direito de se executarem sozinhos. Quando uma pessoa já aprovou o mesmo tipo de ação vezes suficientes sem mexer em nada, podes passá-lo para baixo do limite. Essa decisão é da equipa que responde por ela, não do agente.

Limites, não intuições

“Pergunta-me quando for importante” não é uma regra. O agente não sabe o que te parece importante. Uma regra precisa de um número, de uma categoria ou de uma lista:

• Um número. Os reembolsos até um limite são executados; acima dele, vão para o responsável de operações.
• Uma categoria. Qualquer alteração a um contrato vai para o jurídico, seja qual for o valor.
• Uma lista. Novos fornecedores, contas-chave e tudo o que chegue à imprensa vão sempre para uma pessoa.

Cada regra diz quem decide e onde lhe perguntam: no Slack, no Teams ou por email, onde essa pessoa já trabalha. Se a regra manda aprovações para um painel que ninguém abre, é o negócio que para.

Um exemplo concreto

Este é o formato de um conjunto de regras para os agentes de suporte e de vendas de uma loja online. Os limites defines tu. O que importa é a estrutura.

Começa pela coluna da direita. É a lista do que a tua equipa decidiu guardar para si. Tudo o que está à esquerda é trabalho que ela deixa de ter de fazer.

Se não se pode desfazer, quem o faz é uma pessoa.

O veto que não é um modelo

Há regras demasiado importantes para as deixares a um modelo de linguagem, mesmo a um que está a ser verificado. A margem é o caso mais claro.

No sistema de marketplace que construímos, nenhum agente escreve um preço. Os agentes podem propor um desconto ou uma liquidação, mas cada proposta passa primeiro por um travão de margem. Esse travão é código simples, não um modelo. Calcula o mínimo daquele produto depois de devoluções, comissões e envio, e veta tudo o que fica abaixo. Não há ninguém para convencer nem prompt para errar.

Usamos este padrão sempre que uma regra cabe numa conta ou numa consulta. O modelo propõe, o código determinístico verifica, e uma pessoa aprova o que as regras mandam uma pessoa aprovar. Cada camada faz aquilo em que é boa. Nenhuma fica sozinha como última linha de defesa.