Quiero contarte por qué existe Nami y cuál es su propósito: no la versión pulida, la real.
Hace varios meses, justo cuando la empresa para la que trabajaba empezaba a tener problemas y el panorama se veía complicado, empecé a trabajar en un producto que pensé me ayudaría a acelerar el desarrollo de Pruebas de Concepto (POCs). La idea era simple: mapear procesos de negocio, convertirlos en un flujo de trabajo a través de una máquina de estados, y exponerlos como APIs para solo tener que trabajar en la UI y listo. La meta era crear el backend tan rápido como fuera posible para armar una POC en horas, no semanas. La idea surgió un día viendo el batch de empresas de YCombinator.
Siempre fui muy fan de YC y constantemente entraba a ver los batches pensando "yo podría hacer eso". Recuerdo incluso una startup de lavado de autos que nunca pensé pudiera entrar a YC, no porque el producto fuera malo, sino porque un autolavado tiene muy poco de sexy e innovador. Pero eso es tema para otro post.
Lo importante es que empecé a querer desarrollar productos: tomar la experiencia y el conocimiento que tenía y crear tantos como fuera posible, algo útil que la gente pudiera usar. Y ahí cometí el error clásico: empezar por la tecnología e intentar después que encajara en un problema, en vez de al revés.
En algún momento desarrollando Nami me di cuenta de que las capacidades técnicas eran suficientes para mí, pero solo para mí. Ser mi único cliente no es un buen plan de negocios. Tenía un producto sin problema, sin propósito: una pieza de ingeniería que sí resolvía algo, pero solo resolvía mis problemas. Dejé de inventarme escenarios y empecé a buscar respuestas en otra dirección.
Hay un video de Steve Jobs que me marcó mucho, donde habla de trabajar primero con la experiencia del cliente y recién después ir hacia la tecnología: no puedes empezar por la tecnología e intentar venderla después. Es un error común, y aunque sientas que tienes un problema "real", muchas veces es real solo para ti y tu experiencia.
Con esto en mente, el tiempo siguió pasando y empecé a tomar proyectos que hoy desarrollo de forma personal y con mi equipo en Empulse.dev, un equipo pequeño pero con mucho potencial. De los varios proyectos en los que colaboramos, dos fueron los más importantes para esta historia: ambos sobre implementar IA en el negocio. Los nombres son ficticios por razones obvias, pero los hechos son reales.
El Proyecto Alfa era uno donde se prometió la IA como esa herramienta que resuelve todo: el Jarvis que sabe hacer de todo, con Tony Stark incluido.
El Proyecto Beta es uno donde, aunque la operación funciona, opera con herramientas muy básicas que son silos de información: sin estructura, sin control, sin visibilidad para los demás equipos. Cada equipo sabe cómo opera, pero la información no es transversal a nadie.
Lo que ambos tenían en común: detrás de cada uno había un sponsor empujando la implementación de IA porque "todo el mundo lo está haciendo": el FOMO de perderse la ola es real. E implementar un agente en 5 minutos no es el problema. El problema viene después. Y en ambos casos llevó al mismo lugar.
No necesitas un agente, necesitas un sistema
Eso es lo más valioso que puedo dejar en este post.
Y no me refiero a un sistema desde la perspectiva técnica, ni a un framework, ni a un lenguaje de programación. Un sistema no es más que la automatización de un proceso. Proceso es la palabra clave. Para crear un sistema hacen falta dos cosas:
automatización + proceso = sistema. Así de simple.
La automatización viene del agente. El proceso es 100% del usuario o la empresa que lo implementa. Un agente sin proceso no llega muy lejos, y a diferencia de los sponsors de Alfa y Beta, que querían aventarle el problema directo al agente, lo correcto es detenerte a pensar primero en tus procesos. Son la materia prima con la que instruimos a los agentes para que ejecuten acciones con propósito, con sentido, y sobre todo con accountability.
De la experiencia de Alfa y Beta salió la tarea de ayudar a las empresas a entender la mejor forma de automatizar. Una excompañera experta en procesos siempre me decía que los procesos existen: documentados o no, están en la operación. Es curioso: muchas áreas tienen procesos que aprendieron de forma empírica y ejecutan como algo natural, parte del día a día, sin que nadie los haya escrito nunca.
Nami, que había empezado como un backend as a service para armar POCs rápido, ya tenía la capacidad técnica de mapear procesos de negocio y crear entidades al vuelo para guardar información estructurada y no estructurada. Es decir: podía crear las herramientas que un agente necesita para operar, y flujos de trabajo que funcionan como rieles sobre los cuales el agente se mueve sin desviarse del objetivo.
Solo le faltaba resolver primero el proceso, antes de construir el agente.
Esa fórmula, automatización + proceso = sistema, es literalmente cómo está construido Nami hoy. Cuando creas un proyecto, el Agente de Proceso conversa contigo primero para mapear tu operación completa: actores, sistemas, traspasos, datos de referencia que se repiten. Ese mapeo queda documentado antes de que exista un solo workflow: es el "proceso" de la fórmula, resuelto antes de tocar la parte de automatización.
Un proceso real casi nunca es un solo flujo. Ese mapeo se subdivide en varios workflows, cada uno con sus propios actores y sus propias interacciones con sistemas distintos, y todo queda documentado como una sola unidad, no como piezas sueltas. Solo después, el Agente de Workflows usa ese mapeo para construir los workflows que modelan tu operación real: los rieles sobre los que cada agente puede operar sin desviarse, uno por cada parte del proceso.
Y para saber si el sistema completo (proceso + automatización) realmente está funcionando, Nami observa sesiones: qué se propuso lograr cada colaborador al usar esas herramientas, y si lo logró. No es intuición ni una demo bonita: es evidencia real de que el sistema funciona, o de qué le falta.
Esta vez tengo pensado hacerlo diferente: no partir de la tecnología hacia un producto, y tampoco ser mi propio cliente. Quiero encontrar empresas y personas que quieran explorar cómo resolver estos problemas de automatización, y trabajar en conjunto para resolverlos.
Si quieres saber más sobre cómo pienso lograr esto, o sobre lo que podemos hacer juntos, escríbeme a gio@empulse.dev. Nada me gustaría más que mostrarte el avance que tengo y construir juntos.
Acceso temprano y prioridad en el roadmap a cambio de una conversación inicial y feedback real mientras el producto madura.
Postularme como design partner