Limites e segurança

Quatro ajustes do LangChain Agent protegem o atendimento e o custo: Todos ficam no config do agente: mudar cria um rascunho, e vale depois de Publicar (Versões e publicação).

​

Limite de chamadas

Cada vez que o agente consulta o modelo conta uma chamada. Uma resposta simples usa uma; cada rodada de tools acrescenta outra (o modelo pede a tool, a tool roda, o modelo é chamado de novo com o resultado). Um agente que não gosta do resultado de uma tool tende a chamá-la de novo, e de novo. O limite corta isso: passando do teto, o agente para e envia ao lead uma mensagem fixa. Onde fica: menu Agente (/project) → ícone de ajustes ao lado de Tools (Comportamento das Tools) → Limite de chamadas. Ligado, exige pelo menos um dos dois tetos. Recomendação: ligue com Por mensagem do lead entre 8 e 15, conforme o número de tools que uma resposta costuma usar, e Encerrar a resposta normalmente. Deixe Na conversa inteira vazio, a não ser que você queira um teto de custo por conversa e aceite as consequências abaixo. Com Tratar como falha do agente, a resposta termina em erro antes da chamada ao modelo: o lead não recebe nem a mensagem de limite nem a mensagem da Falha do agente. O servidor tenta o lote de novo até 3 vezes e, como o limite continua atingido, grava o erro no chat e em Logs. Prefira Encerrar a resposta normalmente.

​

Proteção de dados pessoais (PII)

A proteção de dados procura dados pessoais nas mensagens e age antes que eles cheguem ao modelo (na entrada), ao lead (na saída) ou ao modelo vindos de uma tool. Cada regra tem um tipo de dado, uma ação e onde agir. Tipos prontos: email, credit_card, ip, mac_address, url. Para dados brasileiros (CPF, telefone, CNPJ), use um tipo com nome livre e um detector (uma expressão regular). Cuidados antes de ligar:

• O agente deixa de ver o dado. Com redact na entrada, o agente não consegue salvar o e-mail do lead numa propriedade, porque nunca o recebe. Proteja só o que o agente não precisa usar.
• Não tira o dado da Zatten. A mensagem original continua no chat e no histórico do painel, e na entrada registrada no LangSmith. A proteção limita o que o modelo vê, não substitui a política de dados do cliente final (LGPD).
• block deixa o lead sem resposta. Use só se for isso mesmo que você quer.

​

Filtrar tools

Com muitas tools, o modelo se perde entre elas e cada chamada fica mais cara (a descrição de todas as tools vai em toda chamada). O filtro faz uma chamada a um modelo antes de responder: ele lê a mensagem do lead e deixa visíveis só as tools que têm a ver com o pedido. Onde fica: menu Agente → Comportamento das Tools → Filtrar tools. Só pelo template:

• always_include: tools que ficam sempre visíveis, sem passar pelo filtro.
• model: o nome de outro modelo (mais barato) para o filtro. Usa o mesmo provider e a mesma chave do agente. Vazio = o modelo do agente.
• system_prompt: instrução própria para o filtro.

Quando ligar: a partir de umas dez tools. Abaixo disso, o custo da chamada extra não compensa. O risco: se o filtro esconder a tool certa, o agente responde sem ela, sem erro. Ponha em always_include as tools que não podem faltar: a de transferir para humano, load_skill (o painel já faz isso sozinho quando há skill) e write_todos se usar a lista de tarefas. O nome de uma ação de app integrado é APP_ACAO em maiúsculas (ex.: GMAIL_SEND_EMAIL).

​

Por que a aprovação humana fica desligada

O agente sabe pausar antes de uma tool e esperar alguém aprovar (human_approval e require_approval em cada tool). No WhatsApp, isso trava a conversa: a resposta fica parada esperando uma aprovação, e o painel não tem tela para aprovar. O lead fica sem resposta indefinidamente. Por isso:

• Pelo MCP e pela API de template, a aprovação é sempre gravada desligada, com uma nota quando o bloco tentava ligar (no config inteiro ou em qualquer tool).
• No chat de teste aparece um cartão de aprovação quando uma tool pede; isso não existe no atendimento real.

Para ações sensíveis, use outro caminho: a tool só registra o pedido (numa propriedade, tag ou coluna “Aguardando aprovação”) e um humano conclui pelo painel; ou mova o lead para uma coluna com transbordo.

​

Pelo MCP

Os três ajustes ficam em langchain.config.settings. A escrita cria uma versão não publicada. O config enviado substitui o config inteiro: mande o config completo do get_template com a alteração. Os trechos abaixo mostram só a parte que muda.

​

Armadilhas

• Teto por conversa atingido = conversa travada até encerrar o atendimento.
• Limite por mensagem baixo demais. Um agente que consulta agenda, reserva e confirma precisa de 4 ou 5 chamadas numa resposta. Com teto 3, ele para no meio. Teste o fluxo mais longo no chat de teste antes.
• PII com tipo de nome livre sem detector quebra o agente inteiro: nenhuma mensagem é respondida. Sempre mande o detector junto. O config passa na validação; o erro só aparece ao montar o agente, a cada mensagem.
• PII na entrada tira o dado do agente. Ele não consegue registrar o que não vê.
• Filtro de tools esconde a tool certa. Use always_include para as essenciais.
• MCP migrado do motor antigo com aprovação. Se um servidor MCP tinha “solicitar aprovação” ligado no motor antigo, confira depois da migração que require_approval ficou false na tool mcp. Ligado, ele trava a conversa.

​

Para saber mais

• Resiliência: retry, fallback e erro
• Tools: visão geral
• Servidores MCP no agente
• Referência do config do agente
• LangChain: middlewares prontos (Model call limit, PII detection, LLM tool selector, Human-in-the-loop), guardrails
• Termos para buscar: “ModelCallLimitMiddleware”, “PIIMiddleware”, “LLMToolSelectorMiddleware”, “human in the loop”, “LGPD dados pessoais chatbot”.