Hexa
Una plataforma donde diseñás, entrenás y lanzás agentes de IA conectando hexágonos en un canvas, sin escribir código. El reto real no fue el modelo: fue el orquestador.
- Rol
- Diseño de producto y arquitectura
- Año
- 2026
- Estado
- En producción
- Stack
- React · Node · PostgreSQL · LLMs · Docker
Hexa nació de una frustración concreta: cada empresa con la que hablábamos quería "usar IA", pero ninguna sabía por dónde empezar. No les faltaba modelo —GPT estaba a una API de distancia— les faltaba una forma de describir su proceso y conectarlo a algo que lo ejecutara.
Así que no construimos otro wrapper de chat. Construimos un editor de procesos.
El problema que nadie nombra
Cuando una empresa dice "quiero automatizar la atención al cliente", en realidad está describiendo unas quince decisiones encadenadas: clasificar el mensaje, buscar en la base de conocimiento, decidir si hay suficiente contexto, escalar a un humano si no lo hay, redactar la respuesta en el tono de la marca, registrar el ticket.
Un prompt largo puede simular eso. No puede garantizarlo. En el momento en que una de esas quince decisiones falla, no tenés forma de saber cuál fue.
La diferencia entre un demo y un producto es que el producto te dice dónde se rompió.
La decisión de arquitectura
Separamos tres capas que casi todo el mundo mezcla:
- El grafo — la definición declarativa del proceso. Es un JSON, versionado, diffeable, que no sabe nada de modelos ni de proveedores.
- El orquestador — un motor que recorre el grafo, resuelve dependencias, maneja reintentos y deja traza de cada paso.
- Los ejecutores — adaptadores finos por tipo de nodo: llamada a LLM, consulta SQL, webhook, transformación.
Esa separación costó tiempo al principio y lo devolvió multiplicado. Cambiar de proveedor de modelo pasó a ser configuración, no refactor. Y el día que un cliente preguntó "¿por qué el agente respondió esto?", pudimos mostrarle los siete pasos con sus entradas y salidas.
La interfaz: hexágonos, no cajas
El canvas usa hexágonos por una razón que no es estética. Un rectángulo tiene cuatro lados útiles; un hexágono tiene seis. En grafos densos —y los procesos reales son densos— eso reduce bastante el cruce de conexiones y hace que el flujo se lea sin esfuerzo.
También forzamos una regla incómoda: ningún nodo puede tener configuración oculta. Si algo afecta el comportamiento, está visible en el panel. Perdimos elegancia visual y ganamos usuarios que entienden lo que armaron.
Lo que haría distinto
- Versionado desde el día uno. Lo agregamos en el mes cuatro y migrar los grafos existentes fue doloroso.
- Evaluación antes que features. Tardamos demasiado en construir el set de pruebas automáticas. Sin eso, cada cambio de prompt era una apuesta.
- Menos nodos, mejor documentados. Cuarenta nodos suena a potencia; en la práctica, los usuarios usan ocho y los otros treinta y dos generan parálisis.
Estado actual
Hexa corre en producción con clientes reales en atención al cliente, calificación de leads y procesamiento de documentos. La parte que más me enorgullece no es el canvas: es que cuando algo falla, el usuario puede ver exactamente dónde, sin llamarnos.