Aislar instancias sin tocar el software de otro
Aislamiento de instancias de escritorio: por qué levanté N instancias desde fuera en vez de parchear la aplicación original, y qué me costó esa decisión.
- arquitectura
- msix
- escritorio
- orquestacion
- producto
- windows
Una instancia por máquina contra N agentes en paralelo
Hay aplicaciones de escritorio diseñadas con un supuesto razonable: un usuario, una ventana, una instancia por máquina. El supuesto se rompe en cuanto el patrón de uso real cambia.
El mío cambió cuando dejé de usar un cliente de IA como chat y empecé a usarlo como puesto de trabajo de orquestación: un contexto por proyecto, un contexto por entorno, varios agentes trabajando a la vez en frentes distintos. Con una sola instancia disponible, eso no se puede hacer. Cierras un contexto para abrir otro y pierdes el primero, con todo lo que llevaba dentro. No es una molestia de interfaz: es un cuello de botella que se paga varias veces al día en trabajo rehecho.
En términos de negocio el problema es de capacidad: la máquina y la licencia permiten hacer más trabajo del que la aplicación deja hacer. En términos de sistema, el enunciado es más estrecho y más difícil: levantar varias instancias aisladas de una aplicación que no fue construida para ello, sin modificarla, y sin pedirle al usuario que edite el registro del sistema ni ejecute scripts.
Las dos restricciones del final son las que hacen el problema interesante. Sin ellas hay solución en media tarde, y es una solución que se rompe sola.
Cuatro decisiones y lo que costó cada una
Aislamiento por instancia, no multi-cuenta dentro de una instancia. Cada instancia tiene su propio espacio de estado y su propia sesión, gestionados desde fuera del proceso. La alternativa —"pestañas de perfil" dentro de una única instancia, con un selector de cuenta— es mejor experiencia sobre el papel y exige modificar la aplicación original.
Trade-off aceptado: N procesos completos en la máquina, con N veces el consumo de memoria y sin nada compartido entre ellos, a cambio de no depender de los internos de software de terceros. Todo lo que se apoya en parchear software ajeno se rompe en su siguiente actualización. No es un riesgo, es un calendario: construyes una herramienta con fecha de caducidad desconocida y en manos de otro.
El usuario no ve la mecánica. Sin configuración manual, sin scripts que copiar y pegar, sin edición de registro, sin variables de entorno. Toda la complejidad de la solución vive dentro del empaquetado y se resuelve en la instalación.
Trade-off aceptado: me quedo con toda esa complejidad dentro del producto —y con la superficie de soporte que genera, porque cuando algo falla ahí dentro falla en el equipo de otra persona y sin tutorial que culpar— a cambio de que el usuario no tenga que aprender nada. La regla que aplico: si una herramienta que existe para eliminar fricción exige un tutorial, no ha eliminado la fricción, la ha movido de sitio.
Distribuir por el mismo canal que la aplicación original. Empaquetada y firmada como aplicación de escritorio normal en la tienda oficial, no como script, no como parche, no como descarga directa.
Trade-off aceptado: el ciclo de certificación de la tienda, sus plazos y sus restricciones sobre lo que un paquete puede hacer —para una utilidad que manipula el arranque de otra aplicación, esas restricciones no son teóricas— a cambio de procedencia verificable. Para una herramienta de esta clase, la firma y el canal oficial no son burocracia: son la única prueba que el usuario puede comprobar antes de instalar. Un script sin firma que toca el arranque de tu cliente de IA no lo instala nadie sensato, y hace bien.
Construir para el propio flujo de trabajo antes de pensar en el mercado. El producto nació de un cuello de botella diario mío. No hubo estudio de mercado, ni encuestas, ni landing de validación.
Trade-off aceptado: cero evidencia de demanda antes de invertir el tiempo, a cambio de un usuario cero con el problema todos los días y criterio para decidir qué sobra. La validación llegó después y llegó rápido, pero no era garantía de nada cuando empecé. Esta decisión funcionó; no la presento como método infalible, porque el mismo procedimiento aplicado a un problema que solo tengo yo produce una utilidad con un usuario.
En el diagrama solo hay que mirar el contraste: arriba, un contexto activo y el resto perdido; abajo, un gestor y N instancias con estado y sesión propios. Nada del bloque de arriba se modifica para llegar al de abajo.
Antes · una instancia
Después · instancias aisladas
Qué descarté y por qué
Modificar la aplicación original para soportar perfiles internos. El camino elegante. Descartado por la única razón que importa en este tipo de decisión: la siguiente actualización del software de terceros lo rompe. El aislamiento desde fuera es menos bonito y sobrevive a las actualizaciones. Cuando construyes sobre algo que no controlas, la pregunta no es qué solución es mejor hoy, sino cuál sigue existiendo dentro de tres versiones.
Entregar la solución como script o instrucciones. Era la vía rápida: un .ps1, cuatro pasos en un README y listo. Descartada dos veces. Primero porque traslada al usuario la parte difícil, que es exactamente lo que el producto viene a eliminar. Segundo porque un script sin firma que interviene en el arranque de otra aplicación es indistinguible de algo malicioso, y no puedo pedirle a nadie que confíe en mi palabra.
Multi-cuenta como sustituto del aislamiento. No es lo mismo y se confunde a menudo. Varias cuentas dentro de un proceso comparten estado de aplicación; lo que hacía falta era separar el estado, no la identidad. Resolver el problema equivocado con más elegancia sigue siendo no resolverlo.
Una pantalla de configuración para dar control sobre la mecánica. Descartada por la misma razón que el script: cada opción expuesta es una decisión que el usuario no quería tomar. Habría quedado mejor en la ficha de tienda y habría sido peor producto.
Estado real
El producto es MultiInstanceClaudeDesktop, publicado en la tienda oficial, empaquetado MSIX, versión actual 1.8.5.
La métrica del primer mes: 52,84% de conversión de visita a instalación (Partner Center, Acquisitions, último mes del periodo gratuito), con cero presupuesto de marketing y cero campañas. Dos precisiones necesarias sobre esa cifra. La primera: es conversión de ficha de tienda a instalación, no de instalación a uso sostenido. La segunda, y es la importante: esa métrica corresponde al periodo en que la aplicación era gratuita. El 3 de agosto de 2026 pasó a 4,99 USD de pago único, con versión de prueba gratuita. Atribuir un 52,84% a un producto de pago sería falsear el dato: el embudo con precio delante es otro embudo, y todavía no tengo un mes de datos con él.
Lo que sí sostiene la cifra del periodo gratuito es la lectura cualitativa. Una conversión así, sin campañas, no mide la calidad de la ficha: mide que había un problema real desatendido y gente buscándolo activamente.
Lecciones transferibles
No construyas encima de los internos de otro. Sirve igual para una aplicación de escritorio, para una API sin contrato público o para el DOM de una web que no es tuya. Si tu solución depende de que el software ajeno no cambie, ya sabes cuándo deja de funcionar: en su siguiente versión. Prefiere siempre envolver desde fuera, aunque salga menos elegante y consuma más recursos.
Aislar estado es más útil que multiplexar identidad. Cuando algo se comporta como cuello de botella de concurrencia, mira qué estado compartido hay debajo antes de diseñar el selector de perfiles. Casi siempre el problema es el estado, y casi siempre la solución vistosa ataca la identidad.
La procedencia verificable es parte del producto, no del empaquetado. Cuanto más íntimo es lo que tu herramienta toca —el arranque de otra aplicación, el portapapeles, las credenciales—, más de tu valor está en poder demostrar de dónde viene. Es la misma disciplina que aplico en Copy-on-Select, donde la propiedad que vende el producto es que no existe código de red.
Y la incómoda: la utilidad estuvo construida y sin publicar durante semanas. Llegué a escribir siete documentos de planificación para una aplicación que ya funcionaba. Los planes no aportaban información nueva; aplazaban el momento de exponerla. Planificar puede ser una forma sofisticada de no publicar, y es más difícil de detectar que la procrastinación normal porque se parece mucho a trabajar.
Relacionado
- Ocho agentes para repaquetizar software legacy sin que ninguno firme su propio trabajo — el tipo de orquestación paralela que esta utilidad hace posible en una sola máquina.
- Una utilidad de sistema con cero superficie de red — la misma disciplina de empaquetado y firma llevada al extremo de eliminar la red entera.
Versión corta en LinkedIn: 52,84% de conversión de visita a instalación en el periodo gratuito (linkedin.com/in/carlosdelatorre-ai).