Crear una aplicación es más fácil. ¿Qué sigue?

    Daniel N., CEO of Navixy
    AutorDaniel N., CEO of Navixy
    October 24, 2026
    Código listo. ¿Qué sigue? Un espacio de trabajo con chats, un agente y cambios en el código fuente.

    Me gusta que los agentes de IA permitan probar ideas que antes se dejaban para después. Una persona conoce bien su trabajo, identifica algo que podría simplificar y ahora puede crear una pequeña herramienta en menos tiempo. Un reporte para un cliente, una aplicación para el monitorista, una integración con el sistema de un almacén. Más ideas tienen la oportunidad de llevarse a la práctica.

    Eso también cambia lo que espero de una plataforma. Quien tiene una idea debería poder probarla pronto y seguir mejorándola: ponerla en manos de los usuarios, ver qué funciona y hacer ajustes. Contar con una plataforma confiable permite dedicar más atención al problema que se busca resolver. Con esa visión estamos construyendo Navixy V4.

    La primera versión de su aplicación ayuda a entender el problema y validar el enfoque

    Supongamos que creó con un agente una aplicación para el monitorista. Muestra las entregas y avisa de posibles retrasos. Ya puede revisarla con la persona que la usará y ver si le ayuda en su trabajo.

    En esa conversación aparecen detalles difíciles de prever. El monitorista sabe que en cierto almacén suele haber fila. En otro, necesita llamar al destinatario antes de que llegue la unidad. Y algunos avisos los ignora: llegan demasiados y no requieren ninguna acción.

    Ahora tiene una base para la siguiente versión. Puede ajustar los avisos y comprobar si resulta más fácil detectar las entregas que realmente necesitan atención.

    Después surgen tres preguntas que determinan el funcionamiento diario de la aplicación: en qué datos se basa, cómo darle mantenimiento y qué se puede delegar a los agentes.

    Datos en los que se apoya la aplicación y en los que confían sus usuarios

    «¿La unidad llegó tarde?» parece una pregunta sencilla hasta que hay que elegir el evento para el cálculo. La entrada al almacén y la recepción de la mercancía pueden ocurrir con media hora de diferencia. La consulta se ejecutará en ambos casos, pero las respuestas significarán cosas distintas.

    Conviene definir una sola vez la regla acordada con el cliente y usarla en todas sus aplicaciones. Así, el reporte de la mañana y el asistente del monitorista usarán la misma definición de llegada. Si el cliente modifica la regla, quedará claro desde cuándo aplica la nueva versión y si sus resultados se pueden comparar con los anteriores.

    También influyen aspectos que parecen más sencillos. Los dispositivos envían datos en distintos formatos, los mensajes llegan con retraso y hay huecos en el recorrido registrado. «La unidad no llegó» y «no recibimos datos de su llegada» son situaciones distintas. La aplicación necesita diferenciarlas; de lo contrario, un dato faltante puede confundirse con un retraso del operador.

    Por eso pensamos en todo el recorrido de los datos: cómo conservar los registros originales, normalizarlos y relacionarlos con unidades, personas y tareas. Sobre esa base se pueden definir eventos e indicadores útiles. Y si un cliente cuestiona una cifra del reporte, será posible revisarla: estos son los datos originales, esta es la regla y así se obtuvo el resultado. Ese es el enfoque que estamos incorporando a la plataforma.

    Después del lanzamiento, toca mantener y mejorar la aplicación para sus usuarios

    Supongamos que el monitorista recibe un reporte al inicio de cada turno. Un día no llega. ¿Se retrasaron los datos, no terminó el cálculo o la aplicación nunca arrancó?

    El historial de ejecución ayuda a entenderlo: qué pasos se completaron, cuánto tardó un script o una consulta y dónde se detuvo el proceso. Un mensaje de error sirve cuando explica qué pasó y en qué paso. En el caso de un agente, también importa el estado actual: sigue trabajando, terminó con un error o espera la autorización de una persona. Esperar una decisión y fallar requieren respuestas distintas.

    Nuestro enfoque es que ese historial esté disponible para su análisis. Revisar el flujo de datos en Inspector de IoT Logic, consultar los registros de IoT Query y relacionarlos con la ejecución de la aplicación. Así, una persona o un agente que ayude con el análisis tendrá información concreta para buscar la causa. Eso facilita corregir el problema, probar la nueva versión y volver a la anterior si hace falta.

    Pero una herramienta puede funcionar sin errores y aun así resultar incómoda. Si después de una actualización el monitorista recibe el doble de avisos, conviene revisar si le ayudan a detectar las entregas importantes o solo lo distraen. Los datos sobre el funcionamiento de la aplicación permiten evaluar el cambio con el usuario: qué cambió y si mejoró su trabajo.

    Cuando otro cliente necesite la aplicación, podrá adaptar la solución a sus ajustes y mantener separados sus datos y permisos. En nuestro enfoque, un entorno compartido ayuda al socio a desarrollar una solución para varios clientes sin mantener una colección de copias independientes.

    Autenticación y autorización para agentes

    Un asistente que prepara un resumen solo necesita leer datos. Un agente encargado de modificar las tareas de los operadores necesita otros permisos. Esa diferencia define su acceso: qué datos puede leer y qué acciones puede realizar.

    Aplicamos el mismo criterio que con las personas: cada participante tiene un rol y una responsabilidad. Cuando un agente hace una solicitud, hay que identificar en nombre de quién actúa, con qué cliente trabaja y si tiene permiso para esa acción concreta. Esos límites deben mantenerse tanto si la solicitud pasa por una aplicación como si viene directamente del agente.

    Si cambia una tarea del operador, resulta útil saber quién la modificó y cuándo. Si un agente no pudo completar un encargo, hay que entender qué permiso le faltó. Ese historial facilita revisar los resultados y decidir qué delegar después. Se puede empezar con acceso de lectura y agregar acciones conforme crece la confianza en su trabajo.

    Quiero que nuestros socios tengan más tiempo para resolver los problemas de sus clientes. Que una primera aplicación útil sea el inicio de un trabajo que puedan seguir mejorando, ofrecer a otros clientes y adaptar a nuevas necesidades. Ese es, para mí, el sentido de una plataforma confiable.

    Compartir artículo