Contexto técnico
Me encantan estos casos no por el efecto sorpresa, sino porque se puede ver una arquitectura de IA adecuada, no otro chat improvisado con un prompt. El esquema es simple y potente: una base de conocimientos compartida en Obsidian, un Claude Code dedicado para cada proyecto, un orquestador en la cima y subagentes debajo para tareas específicas.
Me gusta especialmente que la base de conocimientos esté externalizada en Markdown. Es una medida muy práctica para la integración de IA: el conocimiento, las instrucciones, el contexto del proyecto y el enrutamiento de tareas se encuentran en un formato legible, no incrustados en el código del orquestador. Modificas el Markdown, no rediseñas todo el sistema.
Aquí es donde se pone interesante. Si un agente de proyecto llega a un callejón sin salida, no se queda atascado en un bucle infinito, sino que escala el problema hacia arriba. El orquestador decide qué hacer a continuación: gestionar el caso él mismo, pasar la tarea a otro agente o dividir el trabajo en subtareas.
Esto ya se parece mucho a un pipeline de desarrollo de producción. Reconozco patrones familiares aquí: sesiones aisladas, roles dedicados, transferencias entre agentes, una capa de memoria compartida y gestión de tareas largas a través de un coordinador. En esencia, es la base para la implementación de la inteligencia artificial en equipos de ingeniería, donde un proceso estable es más importante que un único agente inteligente.
También me llamó la atención que tanto Claude Code como Codex puedan actuar como orquestadores de alto nivel. Aquí, definiría cuidadosamente los límites de responsabilidad para evitar que compitan por el control del pipeline. Pero la idea en sí es sólida: un modelo es más fuerte en ciertos tipos de tareas, el otro en diferentes, y esto puede usarse como una capa de enrutamiento en lugar de una batalla de modelos.
Qué cambia esto para el negocio y la automatización
El primer efecto es obvio: el coste del cambio de contexto se reduce. Cuando cada proyecto tiene su propio agente y memoria, no paso medio día volviendo a explicar la arquitectura, los errores y los acuerdos. Para los equipos, esto ya no es un juguete, sino una automatización real con IA.
El segundo punto al que le daría un gran visto bueno es la escalada. En lugar de fallar en silencio, el agente levanta la mano, el orquestador interviene y la tarea no muere. Esto es crucial para plataformas internas, soporte de desarrollo y refactorizaciones a gran escala.
Pero aquellos que lanzan esto sin disciplina están destinados a perder. Sin aislamiento del worktree, registros, límites de tiempo y un esquema de transferencia claro, la multiagencia se convierte rápidamente en un caos costoso alimentado por tokens.
Estas son exactamente el tipo de cosas que me encanta analizar a fondo: dónde usar un solo agente, dónde construir una orquestación y dónde no tocar lo que ya funciona. Si su equipo ya está atascado en la coordinación manual, en Nahornyi AI Lab podemos desarrollar una solución de IA a medida de su flujo de trabajo real, para que los agentes se encarguen de las tareas rutinarias y las personas puedan finalmente centrarse en la ingeniería, no en la gestión de tareas.