Un vendedor que toma pedidos por chat — sin sueldo, sin horario.
Yerbi es un agente de pedidos B2B para una yerbatera. Lee lenguaje natural, cotiza desde el catálogo en vivo, arma el pedido, pide confirmación y lo escribe directo en el CRM — todo dentro de Telegram.
Los pedidos llegan por chat — dispersos y a cualquier hora.
- →Los mensajes fuera de hora se acumulan de noche, fines de semana y feriados.
- →La ventana que importa son minutos — mientras el cliente todavía está decidiendo.
- →Pasar cada pedido al CRM a mano es lento y pierde trazabilidad.
- →Un bot de menú ("marcá 1") se siente robótico y lo abandonan.
Siete nodos, una respuesta limpia.
El flujo es event-driven. Cada fragmento de Telegram se bufferea; una ventana de silencio corta los une antes de que el agente corra — así tres mensajes rápidos producen una única respuesta pensada.
Telegram Trigger
Cada mensaje entrante golpea el webhook del bot y arranca una ejecución. Todavía no se responde nada.
Agregar al buffer de mensajes
El fragmento se guarda en un buffer por chat (Redis / MongoDB) con timestamp. Esto es lo que permite tratar varios mensajes como uno.
Esperar, y la compuerta de silencio
La ejecución espera unos segundos. Si llegó un fragmento más nuevo mientras tanto, esta corrida aborta — solo sobrevive la última. Eso garantiza exactamente una respuesta por ráfaga.
¿Quién es este cliente?
Una búsqueda en Salesforce matchea el chat de Telegram con una Cuenta. Los clientes desconocidos van primero a un flujo de registro multi-paso.
El agente Claude
El mensaje unificado más el contexto del cliente se le pasan al agente. Razona sobre la intención y decide qué herramienta llamar — con memoria de conversación entre turnos.
Las herramientas pegan a Salesforce
Tres herramientas hacen el trabajo real: leer el catálogo, leer pedidos anteriores y crear un pedido. La creación pasa por un endpoint Apex, así es una transacción atómica.
Una respuesta de vuelta
La respuesta del agente se envía a Telegram y el intercambio se loguea. Si el modelo alguna vez falla, una rama de fallback igual responde — al cliente nunca se lo deja en visto.
La parte difícil no fue cablear la IA. Fue hacerla confiable.
Algunas de las decisiones y callejones sin salida en el camino:
Mensajes fragmentados
Responder cada fragmento rompía la conversación. Mi primer buffer hacía un read-modify-write y, con mensajes casi simultáneos, a veces dejaba pasar dos corridas — una race condition real.
Frenar la alucinación
Un bot que inventa un precio o un número de stock es peor que no tener bot. Al principio improvisaba sin drama.
Pedidos que no pueden existir a medias
Un pedido creado por la mitad en el CRM es data corrupta. Tiene que ser todo o nada.
El backend desapareció
La dev org gratuita de Salesforce se desactivó sola tras inactividad, llevándose toda la capa de datos justo antes de una demo.
Nunca dejar a un cliente en visto
Si el proveedor del modelo tiene un hipo, el cliente igual merece una respuesta.
Sacar las reglas de negocio del prompt
Estados internos, confirmación explícita antes de crear, nunca exponer IDs internos — demasiado importante para dejárselo a un modelo de lenguaje.
El stack, y qué hace cada parte.
| Servicio | Rol | Costo |
|---|---|---|
| Telegram Bot API | Recibe y envía mensajes por webhook | Gratis |
| Anthropic · Claude | Razonamiento del agente y tool-calling | Pago |
| Salesforce REST + Apex | Catálogo, pedidos, creación atómica | Dev org |
| MongoDB Atlas | Broker de debounce + historial de conversación | Free M0 |
| n8n | Orquesta todo el flujo | Self-host |