De prototipo de mensajería a MVP para iOS: el backend de Tomo AI

Mantenerse al día con el trabajo diario significaba saltar todo el día entre el correo, el calendario y una lista de tareas, y Tomo AI es la respuesta de JIA NOMADS a eso: un asistente de IA contextual que convierte la actividad del correo y de la agenda en prioridades claras y accionables, para que el usuario trabaje desde un solo lugar en vez de tres.

Un asistente así es un problema de backend antes que un problema de interfaz. El criterio que vende, qué mostrar ahora, qué posponer, qué implica un correo para el calendario, tiene que vivir en un lugar que sobreviva a la superficie con la que el usuario esté hablando. Si eso queda mal, cada pantalla nueva obliga a reconstruir el cerebro del producto.

Construimos la inteligencia como un solo backend de agentes, con una skill por dominio de flujo, en vez de como funciones cableadas dentro de una aplicación. El orquestador compone las skills de tareas, correo y calendario, y eso es lo que permite que un solo sistema lea lo que se acumula y devuelva prioridades en lugar de otra lista que administrar.

La división del trabajo siguió la misma línea. Jesús construyó el backend de orquestación de agentes; el equipo de producto del cliente construyó las aplicaciones de cara al usuario. Y el producto tomó forma en dos pasadas: primero como un asistente de mensajería con el que se podía hablar desde aplicaciones que la gente ya tenía, y después como una aplicación nativa para iOS.

Un Tomo de mensajería primero. Los usuarios se registraban en una aplicación en React: conectar Google Calendar y Contactos, compartir un número de teléfono y empezar a chatear con Tomo por Telegram o Slack. Los datos de cuenta y los tokens de OAuth vivían en Supabase, y la re-autorización de calendario más la creación de eventos sostenían el flujo de mensajería, así que un token vencido era un estado contemplado y no un callejón sin salida, y una conversación podía terminar en un evento real en un calendario real.

Un backend de orquestación de agentes. Las skills impulsan los flujos de tareas, correo y calendario. Esa es la capa que convierte la actividad del correo y de la agenda en las prioridades claras y accionables que el producto promete, y es la parte de Tomo que construyó Jesús.

Un MVP para iOS en Flutter/FlutterFlow. El equipo de producto lanzó Tomo como aplicación nativa: autenticación y registro, una pantalla principal centrada en tareas con recorridos guiados para las decisiones centrales (priorizar contra posponer), las vistas Focus, Digest y Tareas, y vista previa de correo con integraciones de Google.

Tomo pasó de prototipo a MVP para iOS con su inteligencia viviendo detrás de la interfaz y no dentro de ella: dos iteraciones construidas, tres dominios de flujo, un backend impulsándolos.

Ninguna cifra del lado del producto llegó con este proyecto, así que aquí no aparece ninguna. La franja de métricas cuenta lo que se construyó porque contar es la versión honesta de medir cuando nadie te entregó un tablero, y inventar un número de precisión o de adopción sería la mentira más fácil de contar en esta página.

Lo que el proyecto sí evidencia es la forma de la construcción. Los recorridos, las vistas y la vista previa de correo cambiaron entre iteraciones; los flujos sobre los que corre el producto no hubo que reinventarlos para sobrevivir el paso de una ventana de chat a una aplicación nativa.

Un asistente contextual vive dentro de las cuentas de su usuario, y el acceso a cuentas se degrada. Los tokens vencen, los permisos de calendario hay que volver a otorgarlos, y un producto cuya promesa entera es “deja de cambiar de aplicación” no puede responder a un token vencido expulsando al usuario a arreglarlo. Por eso la re-autorización de calendario se construyó como parte del propio flujo de mensajería: el modo de falla de la integración es un estado contemplado en este producto, no una página de error.

Convertir el correo y la agenda en prioridades también significa tomar decisiones en nombre del usuario, y esa confianza no se otorga por defecto. Los recorridos guiados del MVP para priorizar contra posponer existen porque la interacción es genuinamente nueva; un asistente que decide cosas necesita enseñar a decidir, no solo ejecutarlo.

Una limitación honesta, para quien lea esto para juzgar si se parece a su problema. Esta página describe qué se construyó y qué hace; no se registraron cifras de uso, precisión ni retención del lado del producto, y la vida del MVP después de este proyecto no es algo que este estudio pretenda saber.