El problema que nadie me pidió resolver

Hay una tentación muy concreta cuando uno domina las herramientas: construir algo porque puede. Jarvis V2 nació en ese borde. No había un cliente esperando, no había una métrica de negocio que justificara el esfuerzo. Había una pregunta que me incomodaba: ¿puedo construir un asistente de IA que no dependa de que alguien más tome las decisiones de arquitectura por mí?

La respuesta terminó siendo más compleja que la pregunta.

Lo que el sistema hace, en serio

Jarvis V2 es un asistente personal que corre localmente sobre GPU propia. No es un wrapper de la API de OpenAI con un chat bonito encima. Es una pila completa: modelos ejecutándose con vLLM sobre CUDA, un sistema RAG con ChromaDB y embeddings BGE-M3, procesamiento de voz en ambas direcciones, y una interfaz web construida sobre FastAPI que el README describe como "tipo ChatGPT" — oscura, responsiva, sin logs técnicos visibles al usuario.

Lo que me interesaba de verdad era el ModelOrchestrator: el componente que decide qué modelo usar según la dificultad estimada del query. Qwen2.5-14B para lo cotidiano, LLaMA 3.1 70B para las tareas complejas, DeepSeek 14B cuando el problema es de código. La selección automática no era un capricho estético; era la pregunta de fondo expresada en código: ¿cómo decide un sistema cuánta inteligencia aplicar a cada problema?

Esa pregunta tiene una respuesta filosófica y una respuesta de ingeniería, y durante meses intenté que coincidieran.

La ilusión del asistente universal

Hay una promesa implícita en el nombre "Jarvis". Viene de la ciencia ficción, del asistente omnisciente de Stark, de la fantasía de tener una inteligencia siempre disponible que entiende contexto, intención y matiz. Esa promesa es una trampa.

Cuando uno construye el sistema desde adentro — eligiendo modelos, tuneando parámetros de inferencia, midiendo throughput en tokens por segundo (5.6 tok/s con el Qwen-14B-AWQ, 3.2 con el 32B-GPTQ sobre una RTX 5070 Ti) — la ilusión se disuelve rápido. Lo que queda es algo más honesto: un orquestador de probabilidades. El sistema no entiende nada. Selecciona tokens con alta verosimilitud dado un contexto. Eso es todo. Y sin embargo, en la práctica, funciona.

Esa tensión es lo que más me enseñó el proyecto. La distancia entre lo que un sistema parece y lo que un sistema es puede ser enorme, y esa distancia importa. No para deprimirse con el mecanismo, sino para no confundir el mapa con el territorio cuando uno diseña.

Orquestación como problema de filosofía

La arquitectura de Jarvis V2 sigue un flujo lineal simple en papel: Usuario → FastAPI → ModelOrchestrator → vLLM/Transformers → RAG → Respuesta. Pero la decisión crítica vive en el segundo paso. El orquestador tiene que estimar complejidad sin saber la respuesta. Es una especie de meta-razonamiento: razonar sobre cuánto razonamiento se necesita.

Eso no es trivial. En filosofía de la mente hay un problema parecido que aparece cuando uno intenta formalizar la metacognición — el pensamiento sobre el pensamiento. ¿Cómo sé que no sé algo? ¿Cómo estimo el costo de averiguarlo? Los sistemas de IA actuales no resuelven esto; lo aproximan con heurísticas. Y las heurísticas, descubrí, son buenas hasta que no lo son. Hay queries aparentemente simples que requieren modelos grandes. Hay queries que parecen complejas y que el modelo pequeño maneja con elegancia. La clasificación automática falla en los bordes, exactamente donde es más necesaria.

Por qué importaba construirlo antes de que existiera el protocolo

Jarvis V2 llegó a noviembre de 2025 antes de que yo adoptara el paradigma MCP — el Model Context Protocol que cambia la forma de pensar la integración entre agentes y herramientas externas. En ese entonces, la coordinación entre el asistente y el mundo exterior era manual, ad hoc, incrustada en el código de los módulos. Había conectores para audio, para embeddings, para texto, para la interfaz web. Cada uno hablaba su propio dialecto interno.

Construir así tiene un valor que no siempre se aprecia: te obliga a entender el problema sin la abstracción que lo resuelve. Cuando más adelante apareció una forma mejor de estructurar esa comunicación, la entendí de inmediato porque había vivido el dolor de su ausencia. La segunda generación de un sistema enseña algo que la primera no puede: dónde estaban los límites reales, no los supuestos.

Lo que quedó

Jarvis V2 está marcado como producción en su README. Hay benchmarks reales, una estructura de carpetas pensada, un Dockerfile. Tiene una estrella en GitHub — probablemente mía. No era un proyecto para el mundo; era un proyecto para entender.

Y lo que entendí es que la inteligencia orquestada — varios modelos, varios módulos, varios modos de interacción — no es simplemente más de lo mismo. Es una clase diferente de problema. No se trata de hacer que un modelo sea más listo. Se trata de diseñar el sistema que decide cuándo usar qué, cómo integrar los resultados, cómo mantener coherencia a través de componentes que no se conocen entre sí.

Eso es, en el fondo, lo que estudia la filosofía de los sistemas: cómo emerge el comportamiento global de partes locales que no tienen acceso al todo. Jarvis V2 fue mi primer intento serio de construir ese tipo de emergencia desde adentro.

No fue el último.