Why is Your Chatbot Saving "Good Morning" as the Customer's Name? 🤖🤦‍♂️

Ricardo Carneiro — Tue, 26 May 2026 11:25:39 +0000

The classic struggle of chatbot data extraction, why your complex regex is failing, and how to fix it in 30 seconds using semantic NLU.
tags: webdev, ai, chatbots, javascript

We've all been there. You spend days building a sleek WhatsApp chatbot or a customer service agent. You write what you think is the perfect prompt or input validation.

Then, your bot asks:

"Hi! What is your full name?"

And the user replies:

"Good morning! I'm John Doe."

Your traditional validation or naive regex captures the input, and boom—your CRM database now has a new client officially named "Good morning!" or "Good morning! I'm John Doe."

Even worse, you ask for a Brazilian postal code (CEP) and the user types: "It is 01310-100". Your strict regex fails because it's not strictly digits, or your lazy regex fails to extract it.

Traditional chatbot validation is broken. Relying on complex regex patterns is a maintenance nightmare, and raw LLM prompts are slow, expensive, and prone to hallucinations.

Enter NaLU AI: Semantic NLU Validation in 30 Seconds

I got tired of these universal chatbot struggles, so I built NaLU AI. It’s a lightweight API and MCP Server designed specifically to clean, structure, and validate conversational data in real-time.

NaLU combines a fast deterministic layer with semantic LLM validation in multiple languages (English, Portuguese, Spanish). Instead of processing raw strings, it understands context.

Let's see it in action.

The Code 🛠️

Here is how you can easily validate and extract a clean full name from a conversation using a simple JavaScript fetch (or standard cURL):

const response = await fetch('https://api.naluai.dev/v1/extract/name', {
  method: 'POST',
  headers: {
    'Authorization': 'Bearer YOUR_TOKEN',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    agent_input: 'Good morning! Whats your name?',
    user_input: 'Good morning!',
    language: 'pt-BR'
  })
});

const result = await response.json();
console.log(result);

The JSON Response:



{
  "obtained": false,
  "extracted_value": "",
  "confidence": "high",
  "certain": false,
  "reasoning": false,
  "suggestion_to_agent": "Good morning again! Could you please tell me your name?",
  "validator_used": "validate_name",
  "engine": "llm"
}

Notice that:

It automatically filtered out the greeting ("Good morning isn´t a valid name").
It suggest a "try-again-message".

13 Built-in Semantic Validators
NaLU AI comes with 13 ready-to-use validators:

validate_name (extracts clean proper names, ignores titles and greetings)
validate_cpf / validate_cnpj (validates Brazilian documents using mod 11 check)
validate_cep (extracts postal codes and returns enriched address data)
validate_handoff (detects if the user wants to speak to a human, measuring urgency from 1 to 3)
validate_reply (analyzes conversational context like counter-proposals or indirect answers)
Built for n8n, Make, Cursor & Claude Code
Since it is a standard REST API, it integrates out of the box with no-code tools like n8n and Make.

Even cooler, it exposes itself as an MCP Server, allowing you to add it directly to Cursor or Claude Code to perform semantic tasks locally!

Give it a try! 🚀
NaLU AI is free to start. The free tier gives you 3,000 free credits per month (no credit card required), and paid plans start at less than a fraction of a cent per validation (R0,0058/ 0.001 USD).

Stop losing clients to bad chatbot regex. Clean your database and make your agents truly smart in 30 seconds.

👉 Test it out in the playground: naluai.dev

Let me know in the comments how you are currently handling user data extraction in your chatbot webhooks!

Como estruturei um clone do Linktree (mais simples) multi-domínio e resiliente usando .NET 8 e MongoDB

Ricardo Carneiro — Tue, 26 May 2026 11:19:51 +0000

Fala, pessoal! 👋

Recentemente enfrentei o desafio de criar uma plataforma de agregador de links profissionais do zero (estilo Linktree), mas com foco em resolver dois problemas que as ferramentas tradicionais de mercado deixam de lado: SEO de nicho de verdade e limpeza contra links de spam/phishing.

O resultado desse projeto foi o BCards, e hoje quero compartilhar um pouco das decisões de arquitetura e tecnologia que tomei para colocá-lo de pé.

🛠️ A Stack Escolhida

Para garantir velocidade de entrega, robustez e performance de busca, escolhi uma stack moderna e muito sólida:

Backend: ASP.NET Core MVC com .NET 8 (C#)
Banco de Dados: MongoDB (com drivers oficiais para .NET)
Armazenamento de Arquivos (PDFs/Imagens): MongoDB GridFS
Pagamentos: Stripe (com webhooks)
Autenticação: OAuth 2.0 (Google e Microsoft)
Envio de E-mail: SMTP Resend

🧠 Desafios e Soluções de Arquitetura

1. Sistema de Multi-Tenant e Multi-Domínio

Um agregador de links precisa suportar várias marcas e domínios. No código do BCards, configurei para responder a múltiplos hosts (como bcards.page, bcards.site, spicylinks.site) de forma dinâmica a partir das configurações de Tenant do appsettings.json.

Isso permite que a aplicação seja modular, entregando interfaces customizadas de acordo com o domínio que o usuário acessa, usando o mesmo núcleo do backend.

2. SEO Otimizado com Server-Side Rendering (SSR)

Muitos criadores de link na bio pecam no SEO por renderizarem tudo no cliente (Client-Side Rendering) com frameworks SPA pesados. No BCards, optei por SSR puro via Razor Views.
O robô do Google recebe o HTML limpo, completo, com meta-tags dinâmicas e marcação Schema.org otimizada por nicho de mercado.

3. A Luta Contra o Spam (Moderação Humana)

Ferramentas de links são alvos constantes de spammers, esquemas de pirâmide e phishing. Para proteger o domínio e manter nossa autoridade no Google sempre alta, desenvolvi um Dashboard de Moderação Humana.
Cada página criada passa por uma fila onde validamos critérios estritos de conteúdo (conteúdo suspeito, links quebrados e segurança de links) antes de torná-la 100% ativa para o público.

4. Stripe Integration & Efeito Decoy

Adotei 3 planos estratégicos integrados nativamente com Stripe Webhooks. O sistema escuta os eventos checkout.session.completed e atualiza instantaneamente as limitações da página do usuário no banco (como permitir upload de PDFs no plano Premium e habilitar até 15 páginas).

🚀 Conclusão e Próximos Passos

O projeto está ativo e rodando muito bem. A combinação de .NET 8 e MongoDB se provou extremamente veloz para leitura de dados e flexível para modificações de schema à medida que novas features de links são adicionadas.

Gostaria muito de ouvir a opinião técnica de vocês sobre esse modelo arquitetural!

Se quiserem ver como ficou a interface final e criar uma página de testes, o link é: https://bcards.page

Fico à disposição nos comentários para trocar ideias sobre o código, integrações do Stripe ou a estrutura do MongoDB! 💬

DEV Community: Ricardo Carneiro