Diário do Projeto
Atendus

O construtor de agentes, ou por que um campo de texto não basta

"O agente responde bem, mas não fala como a gente" foi a reclamação número um do MVP. A resposta não foi um prompt melhor: foi transformar personalização em controle fino, configurável pelo cliente e sem uma linha de código.

O MVP tinha um formulário com meia dúzia de campos e uma caixa grande de texto para “descreva seu negócio”. Funcionava o suficiente para demonstrar e o suficiente para irritar.

O agente acertava a informação e errava o resto: falava formal demais para uma loja de streetwear, casual demais para uma clínica, prolixo onde o cliente queria objetividade. E não havia como consertar — a única alavanca era reescrever a caixa de texto e torcer.

Por que “escreva um prompt melhor” não resolve

A tentação era investir em engenharia de prompt do nosso lado: escrever um template melhor, com mais instruções, e injetar a descrição do cliente ali no meio.

Isso falha por dois motivos.

Não escala com o número de clientes. Cada negócio tem uma exigência de tom diferente, e ajustar prompt por cliente é consultoria disfarçada de produto. Com 12 clientes já era insustentável.

O cliente não sabe escrever prompt, e não deveria precisar. Pedir para um dono de imobiliária descrever o tom de voz da marca em linguagem que um modelo entenda é transferir para ele um problema que é nosso.

A conclusão foi que personalização precisa virar interface — controles específicos, cada um com efeito previsível, que a plataforma traduz em instrução para o modelo.

O que o construtor expõe

Cada agente passou a ter dimensões separadas e configuráveis:

Identidade — nome, papel, como se apresenta, se usa emoji, se trata por você ou senhor.

Tom e formalidade — em escala, não em texto livre. É a diferença entre “tente ser mais informal” e um controle que produz o mesmo resultado toda vez.

Objetivo da conversa — informar, qualificar lead, agendar, vender, dar suporte. Muda o que o agente persegue quando a conversa abre.

Limites — o que ele nunca pode fazer. Não dar desconto, não dar orientação médica, não prometer prazo, não falar de concorrente. Foi o controle mais pedido depois do tom.

Regras de escalonamento — quando parar e chamar um humano. Cliente irritado, assunto fora do escopo, pedido de cancelamento, valor acima de um limite.

Conhecimento vinculado — quais bases aquele agente enxerga. É o que permite o mesmo cliente ter um agente de vendas e um de suporte com informações diferentes.

Canal — e aqui está a parte que eu não tinha previsto.

Um agente por canal

A descoberta veio de um cliente que vendia no Mercado Livre e no WhatsApp. O mesmo agente atendia os dois, e ia mal nos dois.

No Mercado Livre, pergunta de anúncio é curta, objetiva e sobre um produto específico. No WhatsApp a conversa é longa, informal, com contexto que atravessa dias.

Tom, tamanho de resposta e objetivo são diferentes por canal — mesmo negócio, mesma marca. Forçar um agente só a servir os dois é garantir mediocridade nos dois.

Então o agente virou uma entidade vinculada ao canal, não à conta. O cliente configura quantos quiser, e cada canal aponta para o seu.

A configuração vira dado, não código
// Simplificado: a forma da configuração que o cliente monta no painel.
$agente = [
    'nome' => 'Sofia',
    'canal' => 'whatsapp',

    'identidade' => [
        'papel' => 'consultora de vendas',
        'tratamento' => 'voce',
        'usa_emoji' => true,
    ],

    'tom' => [
        'formalidade' => 2,   // 1 informal … 5 formal
        'concisao' => 4,      // 1 detalhista … 5 direto ao ponto
    ],

    'objetivo' => 'qualificar_lead',

    'limites' => [
        'Nunca oferecer desconto sem aprovação',
        'Nunca prometer prazo de entrega',
        'Nunca comentar sobre concorrentes',
    ],

    'escalonamento' => [
        'sentimento_negativo' => true,
        'pedido_explicito_humano' => true,
        'fora_do_escopo' => true,
    ],

    'bases_de_conhecimento' => ['catalogo', 'politicas', 'faq-vendas'],
];

A plataforma compila isso num prompt de sistema. O cliente nunca vê o prompt, e é assim que tem que ser: ele mexe em controles que fazem sentido no vocabulário dele, e a tradução para o modelo é nossa responsabilidade.

O princípio que ficou

Este módulo é onde o princípio de dezembro — “configuração é do cliente, não nossa” — ficou mais caro de sustentar e mais valioso.

Caro porque cada controle novo exige pensar como ele se traduz em instrução, o que acontece quando conflita com outro, e como testar. Valioso porque é o que separa produto de consultoria: o número de clientes deixou de ser limitado pelo meu tempo.

Um cliente novo entra sozinho, configura o próprio agente e começa a atender. Isso é o requisito para a plataforma existir como negócio.

Inteligência ArtificialProdutoEngenharia de Prompt