La atención al cliente vive una paradoja cada vez más común: nunca ha habido tantas herramientas para medir tiempos de respuesta, categorizar incidencias o automatizar notificaciones… y, aun así, los equipos siguen atrapados entre tickets repetidos, documentación dispersa y el eterno “¿dónde estaba la solución de esto?”. En ese contexto aparece TenTix, un proyecto open source que se presenta como una plataforma de soporte nativa de Inteligencia Artificial y que promete acelerar la resolución de incidencias con un enfoque centrado en agentes, bases de conocimiento y automatización operativa.
El repositorio, publicado por labring, define Tentix como un sistema pensado para reducir intervención humana, mejorar la satisfacción del usuario y recortar los tiempos de resolución. El mensaje es ambicioso, pero la arquitectura que propone resulta, cuanto menos, coherente con lo que hoy se está imponiendo en el soporte moderno: construir un “cerebro” consultable (RAG) a partir de tickets, conversaciones y documentación, y dejar que un agente guíe el proceso de respuesta.
Un “cerebro” de soporte: de conversaciones estrella a tickets históricos
En el corazón de Tentix está su constructor de base de conocimiento. La plataforma plantea alimentar un repositorio unificado con varias fuentes:
- Conversaciones o mensajes marcados como relevantes (starred).
- Tickets históricos (con foco en los resueltos y de calidad).
- Documentación general (manuales, FAQs, procedimientos internos).
La idea no es solo “guardar texto”, sino convertirlo en conocimiento recuperable mediante embeddings y búsqueda semántica. Para ello, Tentix propone una base vectorial montada sobre PostgreSQL con la extensión pgvector, un enfoque cada vez más habitual porque evita introducir una base de datos adicional si ya se trabaja con Postgres.
Un detalle interesante es que el diseño contempla una prioridad de conocimiento con pesos (por ejemplo, 1,0 para conversaciones destacadas, 0,8 para histórico y 0,6 para documentación general). Eso permite algo clave en soporte: que el sistema “confíe” más en lo que el equipo validó como oro (resoluciones probadas) que en documentación genérica que a veces se queda vieja.
Agentes con flujo controlado: LangGraph como columna vertebral
Tentix organiza su “ciclo de respuesta” como un flujo de trabajo: analizar, refinar consulta, recuperar información y generar respuesta. Para esto integra LangGraph, un marco que se ha popularizado para construir workflows de agentes con pasos explícitos y transiciones controladas.
En términos prácticos, esto suele traducirse en algo que el soporte agradece: menos respuestas “creativas” y más respuestas auditables, con un rastro claro de qué se consultó y por qué. Tentix describe un esquema en el que los mensajes del usuario y la información del ticket se usan para refinar la búsqueda, recuperar contexto en la base vectorial y, finalmente, redactar la respuesta.
Además, el proyecto menciona compatibilidad con MCP (Model Context Protocol) mediante extensiones, una señal de hacia dónde se está moviendo la industria: agentes que no viven aislados, sino que se conectan a herramientas, fuentes de datos y flujos de trabajo de forma estandarizada.
Una plataforma pensada para desplegarse “de verdad”: requisitos, contenedores y variables críticas
Más allá del discurso, Tentix se construye con una lista de requisitos bastante clara para equipos técnicos:
- Bun (≥ 1.2.16) como runtime y toolkit.
- PostgreSQL con pgvector.
- MinIO (o almacenamiento compatible con S3) para objetos como imágenes o adjuntos.
- Credenciales para OpenAI u otras alternativas compatibles (el proyecto menciona también FastGPT como opción).
El despliegue propuesto sigue el patrón actual de muchos productos open source: construir imagen Docker, configurar base de datos, lanzar migraciones y levantar el servicio en un puerto estándar (por defecto, 3000), con endpoint de health check.
También llama la atención el tratamiento de seguridad operativa básica: se exige una clave de cifrado en Base64 para proteger ciertos datos, y se separan variables relacionadas con modelos (modelo de resumen, embeddings, chat, límites de respuestas por ticket) de las de infraestructura (URL de base de datos, credenciales de MinIO, etc.). Dicho sin marketing: Tentix parece diseñado para que un sysadmin o un SRE lo pueda llevar a producción sin improvisar demasiado.
Integraciones y “vida real”: notificaciones, panel de administración y orientación a equipos
Tentix no se queda en un bot. La propuesta incluye:
- Sistema de chat de soporte.
- Notificaciones multicanal, con mención explícita a Feishu (y otras integraciones por módulos).
- Diseño de autenticación unificada con integraciones enchufables.
- Panel de administración con configuración de parámetros del agente (temperatura, TopP, tokens, etc.).
- Exploración de base de datos y gestión de conocimiento (y una hoja de ruta extensa para analítica y visualización).
En su roadmap aparecen puntos que, si se ejecutan bien, suelen marcar la diferencia en soporte: métricas de handoff (cuándo se deriva a humano), evolución del hit rate de la base de conocimiento, distribución de tickets por categoría, o pruebas de calidad de recuperación sin necesidad de abrir un ticket real. Es decir, Tentix apunta no solo a “responder”, sino a gestionar el soporte como un sistema medible.
El trasfondo: por qué el soporte se está moviendo hacia modelos pequeños y agentes especializados
Aunque Tentix no lo plantea como debate filosófico, su enfoque encaja con una tendencia clara: el soporte no necesita siempre el modelo más grande del mercado, sino un sistema capaz de recuperar la información correcta, con buen contexto, y responder con consistencia.
El valor suele estar en el “pipeline”: ingestión de conocimiento, limpieza, priorización, embeddings, recuperación y respuesta. En otras palabras, la ventaja competitiva no es que el agente sea brillante, sino que tenga memoria útil y controlada.
En ese terreno, una plataforma como Tentix compite en un punto delicado: debe demostrar que puede convertirse en la “capa de middleware” del soporte (donde confluyen tickets, docs y conversaciones), sin convertirse en otro sistema más que mantener. Su arquitectura, al menos sobre el papel, va en la dirección correcta.
Preguntas frecuentes
¿Qué es Tentix y para qué tipo de empresas tiene sentido?
Tentix es una plataforma de atención al cliente nativa de Inteligencia Artificial, orientada a organizaciones que gestionan tickets y quieren construir una base de conocimiento consultable con agentes. Tiene sentido en equipos de soporte técnico, SaaS, IT interno o empresas con alto volumen de incidencias repetidas.
¿Cómo funciona una base de conocimiento vectorial con PostgreSQL y pgvector en un sistema de soporte?
El contenido (tickets resueltos, documentación, conversaciones) se convierte en embeddings y se guarda en Postgres con pgvector. Luego, ante una consulta, el sistema realiza búsqueda semántica para recuperar los fragmentos más relevantes y generar una respuesta con ese contexto.
¿Qué hace LangGraph en un “ticketing” con agentes de IA?
LangGraph permite diseñar el flujo del agente como pasos controlados (analizar, refinar consulta, recuperar, responder). Eso ayuda a construir agentes más previsibles y depurables, algo clave cuando la respuesta afecta a clientes o procesos internos.
¿Qué se necesita para desplegar Tentix en producción con Docker?
Según la documentación del proyecto: Bun (para el stack), PostgreSQL con pgvector, un almacenamiento compatible con S3 como MinIO para adjuntos, y credenciales para un proveedor de modelos (OpenAI u opciones compatibles). Además, hay que configurar variables sensibles como la clave de cifrado y la URL de base de datos.
