Tres asistentes de IA, un solo negocio: cómo conectamos Claude Code, Codex y OpenCode sin perder el control

Te cuento cómo terminamos con tres asistentes de inteligencia artificial distintos -Claude Code, Codex de OpenAI y OpenCode- trabajando sobre el mismo negocio, la misma memoria y las mismas reglas, repartidos en dos computadores. Ninguno depende del otro. Ninguno mezcla mi vida personal con los datos de mis clientes. Y si uno falla, el negocio no se detiene.

El problema que casi nadie resuelve bien

Si usas más de un asistente de inteligencia artificial para trabajar -Claude Code, Codex, Cursor, cualquier combinación- seguramente ya chocaste con esto. Le explicas algo a uno, y el otro actúa como si nunca lo hubiera escuchado. O peor: uno hace algo que contradice lo que le dijiste al otro, porque cada asistente vive en su propia burbuja de memoria.

• Cada asistente tiene su propia memoria y sus propias reglas. Le explicas lo mismo dos veces, o uno contradice lo que ya le dijiste a otro.
• Mezclar cuentas y credenciales entre proyectos es un riesgo de seguridad silencioso. Un asistente que usa la sesión que tiene a mano para trabajar en el proyecto de un cliente puede dejar todo firmado con la identidad equivocada.
• Depender de un solo proveedor de inteligencia artificial es un riesgo de negocio, no solo técnico. Si mañana ese proveedor sube el precio, cambia las reglas o tiene una caída, tu negocio entero se para con él.

Aterrizando en la realidad: el segundo punto no es teoría. Nos pasó de verdad, dos veces, con dos clientes distintos, en la misma semana.

Qué construimos, en términos simples

No hicimos magia. Construimos un conjunto de reglas y mecanismos que los tres asistentes leen por igual, en las dos máquinas.

• Un solo manual de reglas que leen los tres asistentes: cambias una regla una vez y la ven todos, no una versión distinta por asistente.
• Memoria compartida: documentos, notas y estado del trabajo viven en un solo sitio que ambas máquinas ven casi en tiempo real.
• Separación real entre lo personal, el negocio y cada cliente: lo personal nunca llega a los asistentes de cara al negocio, ni a ninguna copia externa.
• Un guardián mecánico, no una promesa: cuando un asistente trabaja en el repositorio de un cliente, algo obliga por software (no por buena voluntad) a que quede firmado con la identidad de ese cliente.
• Revisión cruzada obligatoria: ningún asistente mete código directo a producción. Rama propia, solicitud de cambio, y otro asistente distinto revisa antes de aprobar.

Piénsalo así: no es un cartel de por favor no pases, es un torniquete. Esa es la diferencia entre confiar en que el asistente se porte bien, y que sea imposible que no se porte bien.

Cómo leen las instrucciones cada uno de los tres

Antes de diseñar nada conviene saber qué hace cada herramienta con las reglas que le das, porque ahí empieza o se rompe la coherencia. Los tres asistentes cargan un fichero de instrucciones al arrancar, pero no usan exactamente el mismo. Esto es lo que dicen sus documentaciones oficiales a día de hoy.

La consecuencia práctica es que no hace falta mantener tres manuales. AGENTS.md es un formato abierto en Markdown, descrito como un «README para agentes», y su propia web lista a Codex y a OpenCode entre las herramientas compatibles. Claude Code no aparece en esa lista, pero su documentación indica que puede leer ese mismo fichero. Si tu negocio ya tiene reglas escritas, lo razonable es escribirlas una vez y dejar que cada herramienta las encuentre.

Hay un matiz de precedencia que importa. Según la guía de AGENTS.md, gana el fichero más cercano al archivo que se está editando, y lo que le escribes tú en el chat prevalece sobre cualquiera de ellos. Codex, por su parte, concatena los ficheros de la raíz hacia abajo, de modo que los más cercanos van al final y pesan más. Es decir: una regla global puede quedar matizada por una regla de un subdirectorio, algo útil para separar un cliente de otro, pero que obliga a saber qué fichero manda en cada carpeta.

Reglas escritas no son lo mismo que reglas aplicadas

Un manual compartido resuelve la coherencia, no la seguridad. La propia documentación de Claude Code lo dice sin rodeos: trata el contenido de CLAUDE.md como contexto, no como configuración que se haga cumplir, y recomienda un hook PreToolUse cuando lo que quieres es bloquear una acción pase lo que pase.

Ese hook se ejecuta antes de que la herramienta actúe y puede denegar la llamada, por ejemplo devolviendo un código de salida 2 o una decisión explícita de denegar con su motivo. Aquí está la diferencia entre el cartel y el torniquete de la que hablábamos arriba: una instrucción en lenguaje natural la puede interpretar mal un modelo cansado de contexto, mientras que un control que se ejecuta fuera del modelo no depende de su interpretación.

Conviene ser honesto con una limitación: un hook que se agota por tiempo no bloquea la acción, sino que la deja seguir por el flujo normal de permisos. Por eso recomendamos que cualquier control mecánico se pruebe con un caso real que debería fallar, y no solo con uno que debería pasar. Sobre esa idea de verificar en lugar de suponer escribimos más en supervisar tu IA sin paranoia.

Lo que no es perfecto (y por qué te lo cuento igual)

Esto no es instalar y listo. Exige disciplina real de documentación y de revisión: sin eso, se degrada rápido a lo mismo que intenta evitar. La sincronización de documentos tampoco es una base de datos de verdad; tuvimos que construir un mecanismo aparte para que dos máquinas no se pisaran al escribir al mismo tiempo. Y uno de los tres asistentes, OpenCode, todavía no tiene trabajo real completado con él. Está conectado y configurado, pero honestamente, cero tareas de producción resueltas hasta hoy. No lo vendo como maduro porque no lo es todavía.

Lo que se rompió de verdad (y por qué eso no es un problema)

Aquí no te voy a vender que todo salió perfecto a la primera. Sería justo lo contrario de lo que este sistema representa. Durante la construcción se identificaron problemas reales que afectaban al trabajo: configuraciones que se sobrescribían solas, un caso donde un asistente estuvo a punto de usar la identidad equivocada, credenciales antiguas apareciendo donde ya no debían estar. Ninguno se quedó escondido. Cada uno se detectó, se corrigió y quedó documentado el mismo día que se encontró.

Y esa es, de verdad, la parte que más confianza me da de todo el sistema: no que nunca falle, sino que cuando falla, algo o alguien lo atrapa antes de que haga daño real. Un modelo puede alucinar una regla. Un permiso del sistema, no.

Qué hacer en tu negocio

No necesitas nuestra arquitectura para aplicar la idea de fondo. Si hoy usas dos o más asistentes, esta secuencia, de menor a mayor esfuerzo, es la que recomendamos.

• Haz un inventario de dónde vive cada instrucción. Anota qué ficheros de reglas existen, en qué máquina y qué asistente los lee. Lo normal es descubrir duplicados que ya se contradicen.
• Elige una única fuente de reglas y escríbela en AGENTS.md o en el fichero que tu herramienta principal lea. Mantenla corta: lo que no cabe en una página suele ser documentación, no reglas.
• Separa por ámbito. Reglas generales del negocio arriba, reglas de cada cliente o proyecto en su carpeta, y nada personal en un sitio que los asistentes del negocio puedan leer.
• Convierte en control mecánico lo que no puedes permitirte que falle: identidad con la que se firma, comandos destructivos, despliegues. Si dependen de que el modelo se acuerde, todavía no están resueltos.
• Exige revisión cruzada. Que quien revisa un cambio sea una herramienta o una persona distinta de quien lo escribió, y que nada llegue a producción sin pasar por ahí.
• Decide de antemano qué ocurre si un proveedor cae o cambia sus condiciones: qué trabajo puede asumir otro asistente y qué información necesitas poder sacar sin depender de nadie.

El último punto enlaza con algo más amplio que el código: de quién es la memoria sobre la que trabajan tus asistentes. Lo desarrollamos en vendor lock-in y portabilidad de datos, y conviene leerlo antes de elegir dónde guardas tu contexto.

Errores frecuentes al juntar varios asistentes

• Copiar y pegar contexto a mano entre chats. Funciona una semana y después nadie sabe qué versión de la regla es la buena.
• Confiar en que un asistente use la cuenta correcta porque se le ha dicho. Si el repositorio de un cliente está abierto, el asistente usará lo que tenga configurado en esa máquina.
• Dar a todos los asistentes los mismos permisos. Una herramienta que redacta borradores no necesita acceso a producción.
• Medir solo la velocidad. Si el sistema escribe más código pero nadie revisa, has movido el cuello de botella al lugar donde es más caro.
• Declarar madura una herramienta que aún no ha resuelto trabajo real. Nosotros mismos lo decimos de OpenCode en este artículo, y es una buena regla para tus propias decisiones.

Si lo que te preocupa es el lado humano de estos errores, tiene mucho que ver con el riesgo del Shadow AI: herramientas que alguien de tu equipo usa sin que exista una norma ni un registro.

Y si tu duda es más básica, es decir, si merece la pena que un dueño de negocio se meta en esto, te sirve Claude Code para dueños de negocio. Para ver cómo lo aplicamos nosotros sobre un panel propio, está la página del Centro de Mando.

Mi punto de vista

Si me preguntas para dónde va esto, te digo lo que veo en la realidad: cada vez más negocios van a depender de más de un asistente de inteligencia artificial, no de uno solo. Y casi nadie está pensando en cómo hacer que trabajen juntos sin perder el control. La mayoría va pegando contexto a mano entre chats, cruza los dedos, y espera que no se le mezcle algo sensible.

No creo que la solución sea desconfiar de la inteligencia artificial. Creo que la solución es dejar de confiar solo en que el modelo se porte bien, y empezar a construir los mismos guardianes mecánicos que ya usamos en cualquier sistema serio: permisos, identidad forzada, revisión cruzada. Eso es lo que venimos construyendo en IA & Negocios desde el primer colaborador digital: no reemplazar personas, darle a tu negocio una estructura que aguanta cuando algo falla, en vez de romperse.

Preguntas frecuentes

¿Se puede usar Claude Code y Codex en el mismo proyecto?

Sí, siempre que ambos lean el mismo conjunto de reglas y memoria compartida. Sin eso, cada uno trabaja con su propio contexto y terminan contradiciéndose. La clave no es la herramienta, es la gobernanza compartida entre ellas.

¿Es seguro dar acceso a varios asistentes de IA a los datos de un negocio?

Es seguro cuando la seguridad no depende de que el modelo se acuerde de una regla, sino de permisos reales del sistema: identidad forzada por software, separación de credenciales por cliente, y revisión cruzada antes de que un cambio llegue a producción.

¿Qué pasa si un proveedor de IA sube de precio o deja de funcionar?

Si tu negocio depende de un solo asistente de IA, un cambio de precio o una caída del servicio te para por completo. Un sistema con más de un asistente trabajando sobre la misma memoria reduce ese riesgo: ninguno es un punto único de fallo.

¿Hace falta un fichero de reglas distinto para cada asistente?

No necesariamente. AGENTS.md es un formato abierto que Codex y OpenCode leen, y Claude Code puede usarlo en lugar de su CLAUDE.md. Lo recomendable es escribir las reglas una vez y comprobar en cada herramienta que realmente las ha cargado.

¿Basta con escribir las reglas de seguridad en el fichero de instrucciones?

No. Un fichero de instrucciones es contexto que el modelo interpreta, y la documentación de Claude Code lo reconoce así. Para lo que no puede fallar, usa controles que se ejecuten fuera del modelo, como un hook que bloquee la acción antes de que ocurra.

Si ya usas más de un asistente de inteligencia artificial para trabajar y sientes que vas pegando las piezas a mano, no eres el único. La pregunta que vale la pena hacerte es esta: si hoy uno de esos asistentes tuviera acceso a algo que no debía, ¿te enterarías a tiempo? Cuéntame en los comentarios cómo estás resolviendo tú ese problema, o si es la primera vez que lo piensas.