Jarvis es un asistente al que se le habla por Telegram y que vive en un servidor administrado por mí. Consulta, ejecuta, escribe en mis notas y recuerda conversaciones anteriores. Está en uso diario desde febrero de 2026, que es la razón de que este proyecto hable tanto de mantenimiento como de arquitectura.
Empieza por dónde vive. Un servidor pequeño de arquitectura ARM, del tipo que las nubes ofrecen en su capa gratuita, y esa restricción condicionó el resto: obliga a elegir piezas que quepan ahí y descarta de entrada las que solo funcionan a base de recursos. Instalarlo, cerrarlo y mantenerlo actualizado forma parte del proyecto, no es un paso previo.
No tiene interfaz propia, y es una decisión, no una carencia. Telegram ya resuelve notificaciones, historial, buscador y movilidad. Una aplicación web equivalente habría supuesto mantener una interfaz más durante años a cambio de nada.
La parte que exigió más cuidado es que este asistente puede ejecutar comandos en el servidor. Eso es justo lo que lo hace útil y también lo que lo haría peligroso expuesto al exterior. Por eso no lo está: el servidor no publica ningún puerto por el que se le pueda hablar desde internet. Vive dentro de una red privada de malla que conecta únicamente mis dispositivos, de modo que el móvil, el portátil y el servidor operan como si estuvieran en la misma sala.
Un asistente que ejecuta comandos no debería ser alcanzable desde internet. Tampoco con contraseña.
La alternativa habitual —dejar el acceso abierto tras una clave larga— habría sido más cómoda. Pero una clave se filtra, y al otro lado hay una terminal con permisos de administrador: el coste de equivocarse es demasiado alto para aceptarlo a cambio de comodidad. Lo que sí queda expuesto tiene delante las defensas de rigor: bloqueo automático de intentos repetidos y servicios que arrancan con el sistema de ficheros en solo lectura salvo las carpetas concretas donde necesitan escribir.
Dentro no hay un modelo, hay tres, y cada uno atiende un tipo de tarea. El que conversa y decide es el más capaz y el más caro. El que escribe código es intermedio. El que resume datos de salud es el más pequeño, porque resumir no exige el mismo músculo que razonar sobre una arquitectura. Los tres tienen modelo de reserva.
Hay ahí una corrección que dice más que el diseño original: llegué a tener siete agentes especializados y bajé a tres. La especialización funcionaba sobre el papel y en la práctica añadía coordinación, latencia y contexto perdido cada vez que una consulta simple pasaba por dos manos. Retirar cuatro fue mejor decisión que la que los puso ahí.
La memoria funciona en dos capas, también a propósito. Una recupera por significado y sirve para contexto y preferencias. La otra busca por texto y por fecha y sirve para rastrear el origen de una afirmación. Concentrarlo todo en la primera resulta más cómodo hasta el día en que hay que demostrar de dónde salió algo. Ambas se apoyan en un modelo que corre en el propio servidor: la memoria es personal y no sale de ahí.
Y luego está la parte que no aparece en ningún diagrama. Tras una actualización rutinaria, el sistema dejó de arrancar. El registro de errores señalaba a un comando de reparación automática que, en ese caso concreto, no reparaba nada: conservaba a propósito los ficheros antiguos, que eran justamente el problema. Localizarlo llevó su tiempo, y la lección no fue el arreglo sino lo que vino después: dejar escrito el procedimiento, con la señal exacta que hay que buscar en el registro para reconocerlo en dos minutos en lugar de en una hora.
Ese cuaderno de incidencias es lo más representativo del proyecto. Construir algo que funciona el primer día está al alcance de mucha gente. Sostenerlo meses después, saber por qué se rompió y dejarlo documentado para la próxima vez es un trabajo distinto.
Ninguna de estas decisiones se tomó por preferencia técnica. Telegram en lugar de interfaz propia evita un compromiso de mantenimiento a años vista. Tres modelos en lugar de uno es control de coste por tarea. Pasar de siete agentes a tres es reconocer que se había optimizado un problema inexistente. Son decisiones de producto tomadas sobre piezas técnicas, que es exactamente el trabajo cuando el sistema no es propio.