Ferramentas tipadas evitam pontos cegos na sua API

Um agente deve escolher o que fazer. Ele nunca deve inventar o formato que sua API espera. Essa divisão parece óbvia até um modelo enviar customer_id quando o endpoint espera accountId, transformar uma prévia em atualização ou preencher um enum desconhecido com uma palavra plausível. A solicitação pode parecer correta na transcrição e ainda ser inválida, ambígua ou perigosa.

Ferramentas tipadas tiram essa ambiguidade do prompt e a colocam em um contrato que pode ser imposto. O modelo recebe um conjunto limitado de operações, cada uma com um formato de entrada verificável por máquina. Seu aplicativo valida a chamada antes que ela toque a lógica de negócio e depois pede aprovação humana para qualquer operação que altere o estado. O modelo continua raciocinando sobre a intenção. O código controla sintaxe, autoridade e execução.

Já vi equipes tratarem um prompt de sistema detalhado como se fosse uma definição de interface. Não é. A prosa pode explicar uma política, mas não pode rejeitar um campo adicional, impor uma união discriminada, comparar um número de versão nem impedir que uma nova tentativa faça duas cobranças. Se um agente consegue acessar uma API de produção, esses controles devem estar no código.

Um prompt descreve a intenção, um contrato define a permissão

Um prompt pode dizer ao agente para atualizar um cliente somente após confirmação. Um contrato de ferramenta define exatamente qual atualização existe, quais campos ela aceita e o que significa a confirmação. Essas funções se sobrepõem na conversa, mas falham de formas diferentes. A prosa falha pela interpretação. Os contratos falham de forma visível na validação, um tipo de falha que pode ser testado e operado.

Suponha que uma API interna exponha um endpoint amplo chamado execute_action. Seus argumentos são action, resource e payload, todos strings. O prompt lista as ações permitidas e inclui exemplos. Esse desenho parece flexível porque uma nova ação não exige mudança de esquema. Ele também cria um túnel ao redor de todas as restrições que a API já aprendeu a aplicar. O modelo pode errar o nome de uma ação, enviar JSON serializado dentro de payload ou combinar um recurso com uma ação que nunca foi destinada a ele.

Uma superfície tipada deve expor operações estreitas como get_customer, preview_address_change e commit_address_change. Cada nome carrega uma capacidade. Cada esquema de entrada limita o modelo aos campos que aquela operação pode usar. Se o modelo precisar de uma ação não suportada, a chamada deve falhar como não suportada. Uma chamada rejeitada é mais segura que uma chamada adivinhada e mostra onde o catálogo de ferramentas precisa melhorar.

Também é aqui que as equipes confundem segurança de tipos com formatação do prompt. Pedir ao modelo que responda com JSON facilita a análise. Isso não torna o JSON válido para seu negócio. A sintaxe diz que as chaves correspondem. Um contrato diz que country usa um código permitido, customer_id identifica o tipo correto de registro e uma escrita exige uma proposta aprovada. Você precisa das duas camadas.

Mantenha as descrições, mas dê a elas uma função menor. Uma descrição explica quando usar uma ferramenta e o significado dos seus termos. O esquema decide o que pode atravessar a fronteira. Quando uma restrição ainda importa depois que o modelo termina de gerar texto, codifique-a onde o executor possa verificá-la.

Bons esquemas dificultam estados ilegais

Um esquema útil faz mais que rotular campos como strings. Ele codifica as escolhas que alteram o comportamento e rejeita combinações sem sentido. Se uma API aceita um endereço de entrega existente ou um endereço novo, modele isso como dois casos distintos. Não aceite doze campos opcionais esperando que o prompt explique quais seis devem aparecer juntos.

Este trecho de JSON Schema dá ao modelo uma escolha explícita e fecha o objeto para campos inventados:

{
  "type": "object",
  "additionalProperties": false,
  "required": ["customer_id", "destination"],
  "properties": {
    "customer_id": {"type": "string", "minLength": 1},
    "destination": {
      "oneOf": [
        {
          "type": "object",
          "additionalProperties": false,
          "required": ["kind", "address_id"],
          "properties": {
            "kind": {"const": "saved"},
            "address_id": {"type": "string"}
          }
        },
        {
          "type": "object",
          "additionalProperties": false,
          "required": ["kind", "line1", "city", "country"],
          "properties": {
            "kind": {"const": "new"},
            "line1": {"type": "string"},
            "city": {"type": "string"},
            "country": {"type": "string", "pattern": "^[A-Z]{2}$"}
          }
        }
      ]
    }
  }
}

O campo kind é um discriminador. Ele impede que o identificador de um endereço salvo apareça no caso de endereço novo e dá aos erros de validação uma localização útil. additionalProperties: false importa porque os modelos costumam produzir extras que parecem úteis. Ignorar esses campos silenciosamente ensina todos a aceitar uma diferença entre a transcrição e a ação realmente executada. Rejeite-os.

Não codifique como enums estáticos fatos que exigem dados atuais. Uma lista de IDs de depósito, usuário ou plano vigente fica desatualizada. Coloque no esquema vocabulário estável como draft, approved e cancelled. Resolva identificadores variáveis por uma ferramenta de leitura e depois valide-os contra o sistema de registro durante a execução.

Datas, dinheiro e quantidades merecem representações explícitas. Use uma string de data ISO quando a API se refere a uma data de calendário, não um timestamp com fuso horário implícito. Represente dinheiro como um inteiro na menor unidade suportada mais um código de moeda, a menos que o modelo de domínio existente determine outra representação exata. Adicione mínimos, máximos, comprimentos de string e padrões quando o domínio os tiver. Cada limite omitido se torna um valor que o agente pode tentar de forma razoável.

O versionamento do esquema deve ser tedioso. Dê a cada ferramenta uma versão no registro, mantenha as versões antigas disponíveis enquanto execuções ativas ainda puderem chamá-las e faça alterações incompatíveis em uma nova versão. Tornar obrigatório no mesmo lugar um campo antes opcional pode transformar uma repetição comum do agente em um erro de validação misterioso.

Valide antes e depois da lógica de negócio

A validação na fronteira precisa de duas passagens. Primeiro valide os argumentos do modelo contra o esquema publicado da ferramenta. Depois valide fatos do domínio dentro do serviço que os controla. A primeira passagem pega chamadas malformadas. A segunda pega chamadas bem formadas que já não são verdadeiras.

Uma solicitação com customer_id: "C-1842" pode satisfazer todas as regras de JSON e apontar para um registro excluído ou para um cliente fora do tenant do operador. Uma quantity positiva pode superar o estoque disponível. Uma proposta approved pode ter expirado. O adaptador da ferramenta não deve tratar sucesso no esquema como autorização nem como validade do domínio.

Retorne erros como resultados tipados, não como parágrafos que o modelo precisa reinterpretar. Um envelope de erro estável dá ao planejador informação suficiente para se recuperar sem expor stack traces:

{
  "ok": false,
  "error": {
    "code": "VERSION_CONFLICT",
    "message": "Customer changed after the proposal was created",
    "retryable": false,
    "field": "expected_version"
  }
}

O código serve para o fluxo de controle. A mensagem serve para a transcrição e para o operador. O indicador de repetição diz ao ambiente se repetir a mesma chamada poderia ajudar. Mantenha esses significados estáveis entre as ferramentas. Se cada adaptador inventar sua própria prosa de erro, o modelo vira por acidente seu analisador de erros.

Valide também as saídas. Autores de ferramentas mudam código, APIs anteriores retornam dados parciais e serializadores vazam campos. Um esquema de saída pode impedir que uma ferramenta devolva credenciais, notas internas ou um megabyte inesperado de texto ao contexto do modelo. Ele também detecta o caso desagradável em que a execução deu certo, mas o formato do resultado mudou e o agente passou a raciocinar com campos ausentes.

Registre o resultado da validação com nome da ferramenta, versão do esquema, ID da execução e código de erro. Não registre argumentos brutos por padrão. Entradas de ferramentas muitas vezes contêm exatamente os dados pessoais ou operacionais que você pretende controlar. Registre hashes ou campos seguros selecionados quando eles fornecerem prova suficiente.

Leituras e escritas pertencem a conjuntos de capacidades diferentes

Classifique as ferramentas pelo efeito antes que o modelo as veja. Uma leitura retorna informação sem alterar um estado durável. Uma escrita cria, atualiza, exclui, envia, publica, paga, implanta ou aciona outro sistema que faz uma dessas coisas. O verbo HTTP não é um classificador confiável. Um endpoint GET pode marcar uma mensagem como lida e um endpoint POST pode executar uma busca pura. Classifique o efeito no negócio.

Dê ferramentas de leitura aos agentes exploratórios por padrão. Adicione ferramentas de escrita somente à execução que precisa delas, sob uma identidade com permissões equivalentes no servidor. Esconder ferramentas de escrita no prompt não controla permissões. Se o ambiente ainda pode despachar uma chamada pelo nome, uma injeção de prompt ou um erro de planejamento pode encontrá-la. O despachante deve rejeitar qualquer ferramenta ausente do conjunto de capacidades da execução.

As escritas também precisam de formatos mais estreitos. Uma ferramenta genérica update_record pede que o agente entenda todas as tabelas e colunas alteráveis. Exponha operações de negócio como suspend_invoice_delivery ou change_shipping_address. O serviço pode então impor invariantes, produzir uma prévia útil e anexar uma política de aprovação àquele efeito exato.

Algumas operações parecem reversíveis, mas não são. Não dá para recolher um e-mail enviado com confiança. Publicar um evento pode iniciar vários trabalhos posteriores. Excluir um registro recém-criado talvez não desfaça a notificação já enviada sobre ele. Trate comunicação externa e acionadores posteriores como escritas mesmo quando seu banco local não muda.

Para um fluxo misto, separe planejamento e execução. O agente pode ler registros, calcular uma alteração proposta e pedir a uma ferramenta de prévia que estime ou valide essa alteração. A ferramenta final de confirmação aceita um identificador de proposta, não uma nova carga livre. Essa única escolha de projeto impede que a operação aprovada mude entre a tela e a escrita.

A aprovação deve vincular uma escrita proposta exata

Um botão de aprovação sozinho oferece pouco controle. O registro de aprovação deve dizer quem aprovou o quê, contra qual versão do alvo e até quando. Caso contrário, um modelo pode receber aprovação para uma carga e executar outra, ou executar a carga aprovada depois que o registro subjacente mudou.

Use um objeto de proposta criado por código confiável. O agente fornece argumentos candidatos a uma ferramenta de prévia. O serviço os valida, resolve padrões, calcula consequências e retorna uma proposta canônica. O usuário vê o efeito canônico, não o resumo conversacional do modelo. Um registro de aprovação prático pode ter esta forma:

{
  "proposal_id": "p_7f31",
  "tool": "commit_address_change.v2",
  "arguments_sha256": "8be7...a91c",
  "target": {"type": "customer", "id": "C-1842", "version": 17},
  "effect": "Replace the shipping address for customer C-1842",
  "expires_at": "2026-08-14T16:30:00Z",
  "approved_by": "user_291"
}

O endpoint de confirmação carrega esse registro, verifica a autoridade de quem aprovou, confere a expiração, compara a versão do alvo e calcula novamente o hash dos argumentos canônicos. Ele não deve aceitar argumentos substitutos do agente. Se qualquer coisa for diferente, a execução para e o sistema cria uma proposta nova.

A política de aprovação deve acompanhar a consequência, não a quantidade de ferramentas. Um rascunho de baixo risco salvo em uma área isolada pode dispensar decisão humana. Enviar esse rascunho a um cliente não pode. Uma alteração em massa, pagamento, exclusão, rotação de credenciais, implantação em produção ou mensagem externa deve receber um nível de aprovação compatível com seu alcance. Mantenha a regra em uma tabela de políticas que o ambiente possa avaliar. Não a enterre nos prompts.

A tela de aprovação deve mostrar diferenças concretas: campos antes e depois, destinatários, valor e moeda, ambiente, quantidade de registros afetados e qualquer consequência irreversível. Não peça a alguém que aprove run tool call. A fadiga de aprovação começa quando a tela esconde o efeito e obriga o operador a confiar no resumo do agente.

Aprovações devem expirar, e a maioria deve valer uma só vez. Registre também a negação, incluindo uma justificativa curta que o agente possa usar ao refazer o plano. Nunca transforme silêncio, aba do navegador fechada ou tempo esgotado em consentimento.

Uma falha de escrita pode parecer sucesso por vários minutos

Considere um agente alterando um endereço de entrega. Ele lê a versão 17 do cliente, propõe um endereço novo e recebe aprovação. A solicitação de confirmação chega ao serviço, que grava o endereço e confirma a transação. Antes de a resposta chegar ao agente, a conexão cai. O ambiente vê um tempo esgotado. Ele não sabe se a escrita ocorreu.

Uma nova tentativa ingênua envia a mesma alteração lógica outra vez. Se o endpoint acrescentar endereços ou emitir um evento de processamento, a segunda solicitação pode duplicar trabalho. Se o ambiente informar uma falha, o operador pode repetir a alteração manualmente. A transcrição diz que a ferramenta falhou embora a produção tenha mudado. Esse resultado ambíguo é um problema normal de sistemas distribuídos, não uma peculiaridade do modelo.

Toda chamada de escrita precisa de uma chave de idempotência gerada fora do modelo. Vincule-a à execução, à proposta e à operação. Quando possível, o serviço armazena a chave com o resultado final no mesmo limite transacional da escrita. Uma repetição com a mesma chave retorna o resultado armazenado. Uma chamada que reutiliza a chave com argumentos diferentes deve falhar.

O ambiente deve tratar o tempo esgotado em uma sequência fixa:

1. Consultar o status da operação pela chave de idempotência.
2. Se o serviço registrou sucesso, retornar esse resultado tipado ao agente.
3. Se o serviço registrou uma falha terminal, retornar o erro armazenado.
4. Se o status é desconhecido, pausar e escalar em vez de inventar um resultado.

Concorrência otimista fecha outro buraco. A proposta acima aponta para a versão 17. Se uma pessoa alterar o endereço antes da confirmação, a versão atual passa a 18 e a confirmação falha com VERSION_CONFLICT. O agente deve ler o estado novo e criar uma proposta nova. Reutilizar a aprovação antiga aplicaria uma decisão tomada com fatos que já não existem.

Repetições automáticas são adequadas para leituras que se declaram seguras e escritas protegidas por idempotência com um protocolo de status conhecido. Não deixe uma biblioteca genérica de repetição decidir isso somente por erros de rede. A definição da ferramenta deve publicar sua classe de repetição e o executor deve aplicá-la.

Resultados precisam de provas, não de uma frase vitoriosa

Uma resposta bem-sucedida da ferramenta precisa de provas estruturadas suficientes para a próxima decisão. Done não basta. Retorne o identificador do recurso, sua versão nova, o ID da operação, os campos alterados e qualquer estado seguinte do qual o fluxo dependa. Mantenha o texto de exibição separado dos campos de controle.

Para a alteração de endereço, um resultado útil poderia ser:

{
  "ok": true,
  "operation_id": "op_a812",
  "customer_id": "C-1842",
  "previous_version": 17,
  "new_version": 18,
  "changed_fields": ["shipping_address"],
  "committed_at": "2026-08-14T16:22:11Z"
}

Essa resposta permite ao agente informar o que aconteceu sem inventar. Também permite que uma etapa posterior passe new_version a outra proposta. Se o serviço retornar uma mensagem para pessoas, trate-a como texto de exibição, nunca como única prova de sucesso.

Limite o tamanho do resultado de propósito. Uma ferramenta de busca deve retornar uma página limitada e um cursor, não todas as linhas correspondentes. Uma ferramenta de arquivo deve retornar metadados e uma referência quando o conteúdo ultrapassar a necessidade de trabalho do modelo. Resultados grandes sem tipo aumentam o custo e dificultam isolar injeções de prompt dentro dos dados recuperados. Marque dados de ferramentas como conteúdo não confiável no ambiente, mesmo quando vêm do seu próprio banco; um texto armazenado pode ter vindo originalmente de um invasor.

Remova dados no adaptador antes que o resultado entre no contexto do modelo. Permissão para chamar get_customer não implica permissão para revelar todas as colunas do cliente. Defina uma visão de resultado para a tarefa e deixe segredos, indicadores internos e dados pessoais sem relação fora do esquema. A validação de saída protege essa visão contra regressões.

Para operações longas, retorne um recurso de operação com um enum de estado finito como queued, running, succeeded, failed ou cancelled. Consulte-o por uma ferramenta de leitura. Não mantenha uma chamada de modelo aberta enquanto uma implantação ou migração roda e não deixe o agente inferir sucesso pelo tempo decorrido.

Repetição, cancelamento e concorrência precisam de semântica declarada

Um registro de ferramentas deve descrever o comportamento operacional junto aos esquemas de entrada e saída. No mínimo, registre se a ferramenta lê ou escreve, se chamadas idênticas podem ser repetidas com segurança, se ela suporta idempotência, qual política de aprovação se aplica e como funciona o cancelamento. Essas são regras do executor, não dicas em prosa para o modelo.

O cancelamento exige precisão. Cancelar uma execução do agente pode impedir chamadas futuras, mas não desfaz automaticamente uma solicitação já aceita por outro serviço. Um endpoint de cancelamento deve retornar se a operação foi interrompida, já terminou ou não pode ser interrompida. Se houver compensação, exponha-a como uma escrita separada com sua própria prévia e aprovação. Não chame a compensação de rollback quando ela cria outro evento de negócio.

Limites de concorrência pertencem a vários níveis. Limite chamadas por execução para que um ciclo de planejamento não inunde uma API. Limite chamadas por tenant para que um fluxo ocupado não prive os outros. Adicione serialização por recurso quando duas escritas aprovadas no mesmo registro entrarem em conflito. O serviço existente continua responsável por transações e bloqueios; o ambiente do agente não substitui a correção do banco de dados.

Os tempos limite devem refletir o comportamento da ferramenta. Uma consulta de dois segundos e uma conversão numérica longa não devem compartilhar um prazo arbitrário. A plataforma de agentes da CodeHero lê bases de código legado inteiras em paralelo, enquanto a paridade é verificada contra tráfego de produção gravado; esse tipo de carga precisa de operações limitadas e estado explícito de conclusão, não de palpites conversacionais.

Erros de limite de taxa devem dizer quando outra tentativa pode funcionar, mas o ambiente ainda precisa respeitar o prazo da execução e a validade da aprovação. Se uma proposta aprovada expirar durante a espera, a próxima chamada deve falhar e pedir nova aprovação. A conveniência não supera a fronteira do consentimento.

Testes de contrato encontram falhas que prompts não veem

A avaliação do prompt pode dizer se o modelo geralmente escolhe a ferramenta certa. Testes de contrato provam que a chamada errada não pode ser executada. Você precisa dos dois, mas o segundo conjunto protege produção quando modelo, prompt ou descrição da ferramenta mudam.

Crie fixtures a partir de casos de fronteira reais. Para cada ferramenta, teste a menor solicitação válida, campos desconhecidos, campos obrigatórios ausentes, ramos errados de uma união, limites, versões antigas, aprovação expirada, alguém sem autoridade, chaves de idempotência duplicadas e uma chave válida reutilizada com argumentos diferentes. Confira a validação de saída e a remoção de dados com a mesma disciplina.

Um teste de contrato compacto pode ser assim:

GIVEN proposal p_7f31 targets customer C-1842 version 17
AND the current customer version is 18
WHEN commit_address_change.v2 executes with idempotency key run9:p_7f31
THEN no address is changed
AND the result code is VERSION_CONFLICT
AND the proposal remains unconsumed

A última asserção importa. Se um conflito consumir a aprovação, o fluxo precisará de nova aprovação após refazer o plano, o que pode estar correto. Se sua política permite que a mesma aprovação sobreviva a uma falha temporária do serviço, defina isso separadamente. Os testes obrigam a equipe a resolver a distinção em vez de descobri-la durante um incidente.

Teste o despachante como uma fronteira hostil. Peça uma ferramenta não registrada, uma ferramenta de escrita em uma execução somente de leitura, uma versão antiga de esquema, um objeto de argumentos grande demais e strings contendo instruções para o ambiente. O despachante deve analisar dados, impor limites e chamar apenas um manipulador registrado. Ele nunca deve avaliar código gerado pelo modelo nem construir dinamicamente um nome de método.

Mantenha também um conjunto pequeno de rastros completos. Registre o catálogo de ferramentas, a solicitação do modelo, chamadas propostas, decisões de validação, aprovações, resultados do serviço e resposta final sem valores sensíveis. Reproduza esses rastros depois de mudar esquemas. A redação exata pode variar, mas efeitos permitidos e invariantes devem continuar fixos.

Testes de contrato também devem fixar o próprio catálogo. Salve uma lista esperada de nomes, versões, classes de efeito e políticas de aprovação para cada função do ambiente. Uma nova escrita registrada falha na revisão se alguém esquecer a política, e uma função supostamente de leitura falha se seu catálogo ganhar uma operação de confirmação. Isso detecta deriva de permissões antes que um prompt de avaliação escolha a ferramenta nova.

Gere casos inválidos de forma sistemática, mas mantenha o gerador dentro de limites de esquema que você entende. Para uma string obrigatória, tente omissão, texto vazio, valor grande demais e tipo primitivo errado. Para uma união, combine campos dos dois ramos e forneça um discriminador desconhecido. Para números, teste os limites exatos e o valor mais próximo fora de cada um. O objetivo é provar que toda fronteira declarada tem um caminho executável de rejeição.

A telemetria de produção deve responder perguntas concretas sem armazenar cargas sensíveis. Conte chamadas por ferramenta e versão, falhas de validação por código e campo, decisões de aprovação, conflitos, resultados ambíguos, repetições por classe declarada e falhas de saída. Um aumento súbito de campos desconhecidos geralmente significa que um prompt ou cliente avançou além do registro. Conflitos de versão repetidos podem indicar propostas que vivem demais ou um fluxo que lê cedo demais. Esses sinais mostram se é preciso mudar esquema, descrição ou sequência.

Trate erros de validação como retorno do produto, não como texto a ser contornado automaticamente. Se o modelo fornece repetidamente email para uma ferramenta que aceita apenas customer_id, decida se a busca pertence a uma ferramenta de leitura separada ou se a escrita deve aceitar um identificador alternativo estável. Não adicione campos opcionais silenciosamente até as chamadas passarem. Cada campo novo amplia a operação e exige decisões próprias de autorização, remoção e teste.

Injete falhas ao redor do executor. Derrube a conexão depois do commit do serviço, retorne um corpo de sucesso malformado, atrase uma aprovação até ela expirar, coloque duas propostas disputando a mesma versão e torne o endpoint de status indisponível por algum tempo. Confirme que o ambiente relata resultado desconhecido quando faltam provas. Uma resposta inventada de sucesso pode parecer boa na avaliação, então compare com o estado registrado no serviço, não apenas com a frase final.

Por fim, teste se a tela de aprovação e a confirmação compartilham a mesma proposta canônica. Renderize a aprovação a partir de dados canônicos armazenados, aprove-a e altere todas as cópias de argumentos controladas pelo agente antes da confirmação. O efeito executado deve permanecer idêntico ao efeito exibido. Se esse teste for difícil de escrever, a fronteira de aprovação provavelmente depende do estado da conversa, exatamente onde ela não deve ficar.

O padrão seguro é uma superfície menor de ferramentas

Comece com o catálogo mais estreito que conclua um fluxo real. Uma ferramenta merece seu lugar quando sua entrada pode ser limitada, sua saída pode ser validada, seu efeito pode ser classificado e suas falhas podem ser representadas sem pedir ao modelo que adivinhe. Se você não consegue definir essas partes, a API ainda não está pronta para virar ferramenta de agente.

Resista ao conselho popular de expor todos os endpoints internos e deixar o modelo planejar livremente. As equipes gostam dele porque a primeira demonstração aparece rápido. Em produção, ele transfere arqueologia de API, escolha de permissões e interpretação de erros para um componente probabilístico. O modelo então gasta tokens redescobrindo regras que seus serviços já conhecem, e um erro plausível pode atravessar a fronteira de escrita.

Um catálogo estreito não torna o agente menos capaz. Ele torna a capacidade explícita. Adicione uma ferramenta quando os registros mostrarem uma operação ausente, não quando um prompt ganhar outro parágrafo explicando como passar uma ação sem relação por um endpoint genérico. Versione o contrato, anexe a política e dê ao executor um resultado tipado.

O padrão para uma escrita é mais alto. Exija uma proposta canônica, uma aprovação vinculada ao hash e à versão do alvo, um protocolo de idempotência e um resultado que prove o que mudou. Torne resultados desconhecidos visíveis para um operador. Um fluxo pausado é inconveniente; um agente que informa com confiança o estado errado da produção custa caro.

Ferramentas tipadas são o ponto em que um agente deixa de ser uma interface de chat ao redor de credenciais privilegiadas e se torna um componente de software controlável. Mantenha o raciocínio no modelo. Mantenha permissão e verdade na fronteira.