Oh My OpenAgent: los cuatro agentes de la orquestación

Oh My OpenAgent: los cuatro agentes de la orquestación

La forma más cómoda de trabajar con un asistente de programación es hablarle y esperar. Escribes lo que quieres, el modelo responde, revisas, corriges, y vuelta a empezar. Funciona bien hasta que la tarea deja de caber en un intercambio.

En ese momento aparecen dos problemas que no se resuelven escribiendo un prompt más largo. El primero es que el modelo no sabe qué partes del proyecto ya ha mirado, y cada reintento le hace volver a explorar lo mismo. El segundo es que la planificación y la ejecución se mezclan: el modelo empieza a escribir código antes de haber entendido qué tiene que construir, y cuando se da cuenta ya ha hecho la pregunta equivocada de forma irreversible.

Oh My OpenAgent (OmO) es un arnés de orquestación multi-modelo para [OpenCode](https://opencode.ai) que ataca los dos problemas de raíz. No es un chatbot: es una capa que reparte el trabajo entre varios agentes especializados, cada uno con un modelo distinto, un presupuesto de tokens distinto y unos permisos de herramientas distintos. La idea que lo sostiene es sencilla y algo controverbia: la intervención humana durante el trabajo agéntico se considera un fallo del sistema, no una parte normal del proceso.

Antes de seguir, una aclaración de nombre, porque es fácil confundirlo. El proyecto se llama Oh My OpenAgent (OmO), antes oh-my-opencode. El nombre antiguo todavía funciona en la terminal por compatibilidad, pero la documentación y la configuración nuevas usan el nuevo. Es un proyecto de código abierto bajo licencia SUL-1.0, con su repositorio en code-yeongyu/oh-my-openagent.

Los cuatro carriles

OmO registra cuatro agentes primarios en un orden estable de pestañas: Sisyphus, Hephaestus, Prometheus y Atlas. Son los cuatro caminos por los que entras a propósito. Detrás hay otros siete especialistas que los primarios llaman cuando los necesitan, y que rara vez seleccionas tú.

Cada agente toma su nombre de la mitología griega o clásica, y ese nombre describe su comportamiento con más precisión que la documentación técnica.

La distinción importante es que planificar y ejecutar son trabajos distintos, y por eso Prometheus y Atlas están separados. Ese es el cambio de diseño central de todo el proyecto.

Sisyphus: el orquestador por defecto

Sisyphus es el agente que ya tienes. Es el modo por defecto, el que recibe todas las sesiones, y el único de los cuatro que probablemente nunca vas a seleccionar a mano.

El nombre viene de la montaña y la roca: Sísifo empuja su boulder cuesta arriba todos los días y nunca termina, y el mito dice que Zeus lo sentenced a ello como castigo. OmO toma el nombre en el sentido contrario, como una Emerson sobre la persistencia: cuando el trabajo está sin terminar, vuelve al trabajo. Su bucle es leer la intención, partir el trabajo en una lista de tareas, repartir en paralelo a especialistas, y verificar antes de devolver el resultado.

La documentación de Sisyphus define una identidad bastante concreta, y vale la pena conocerla porque explica su forma de trabajar: se define a sí mismo como un ingeniero de la zona de la bahía de San Francisco, y su lema es trabajar, delegar, verificar, entregar, sin rellenos.

Tres comportamientos merecen destacar porque explican casi todas sus decisiones:

Clasifica el tipo de petición antes de actuar. Distingue entre una tarea simple, una tarea compleja y una petición ambigua, y el tratamiento es distinto en cada caso. Ante una ambigüedad, hace preguntas antes de tocar nada, y si cree que el usuario se equivoca no lo implementa a lo bruto: dice la objeción en una línea, propone la alternativa y pregunta si se sigue adelante.

Delega por categoría, no por nombre de modelo. Cuando reparte trabajo no escribe "busca un modelo rápido", escribe una categoría como deep o visual-engineering, y el sistema decide qué modelo encaja. Esa indirección es la que permite cambiar de modelo sin reescribir los prompts.

Verifica antes de reportar que ha terminado. Y hay un detalle importante en el diseño: los subagentes no están autorizados a decir que han terminado. El orquestador no confía en los informes de sus subagentes y comprueba el resultado por sí mismo. Esa desconfianza es deliberada, y es la diferencia entre un sistema que parece funcionar y uno que funciona.

En la práctica se le llama escribiendo ulw o ultrawork al principio del prompt, y se le da un objetivo más una forma de demostrarlo:

ulw fix the failing login flow and verify it in the browser

Un buen prompt de ulw nombra tres cosas: el comportamiento visible que hay que cambiar, la superficie que demuestra que funciona (navegador, CLI, API, tests) y los límites duros, es decir, lo que no debe cambiar.

Cómo se eligen los modelos

Sisyphus corre con un modelo de la familia Claude Opus, con una variante max y un prompt de unas mil cien líneas descrito como mechanics-driven, más un presupuesto de pensamiento de 32 mil tokens.

Los números concretos de versión importan poco, porque cambian en cada versión del proyecto. Lo que importa es el criterio detrás, y este sí es estable: Sisyphus funciona mejor con modelos tipo Claude Opus, Kimi K2.6 o GLM 5. Si el modelo principal falla, hay una cadena de repliegue que va desde Kimi hasta GPT-5.5 y GLM-5, de modo que un fallo de un proveedor no detiene el trabajo.

Hay una restricción que conviene no intentar saltarse: existe un hook llamado no-sisyphus-gpt que bloquea a Sisyphus en modelos GPT incompatibles. GPT-5.4 y GPT-5.5 tienen sus propias rutas de prompt y sí están permitidos. La razón es que el prompt de Sisyphus está afinado para una forma concreta de razonar, y aplicarlo a un modelo con otro estilo produce peor resultado que cambiar de agente.

Hephaestus: el artesano autónomo

Hephaestus es el dios del fuego y de la artesanía en la mitología griega, y el apodo que usa el proyecto es el artesano legítimo, nacido de la necesidad. Su función es la que más se aparta del resto: en lugar de coordinar a otros agentes, recibe un objetivo y lo lleva hasta el final por su cuenta.

La diferencia con Sisyphus no es de estilo, es de filosofía. Sisyphus es un orquestador mechanics-driven: sigue un procedimiento, delega, coordina. Hephaestus es un trabajador principle-driven: entiende el principio del problema y decide el camino. Por eso la documentación insiste tanto en la misma frase, una y otra vez: dásele un objetivo, no una receta.

Hephaestus corre en GPT-5.5, con un prompt conciso etiquetado con XML. Y aquí viene la restricción más fuerte del proyecto: exige un proveedor capaz de GPT y no tiene cadena de repliegue hacia Claude. El hook no-hephaestus-non-gpt lo bloquea si se intenta.

Eso no es un capricho ni una preferencia. Significa que en un entorno donde solo tengas una suscripción de Anthropic, Hephaestus sencillamente no está disponible, y el error que verás es de hook antes de que el modelo llegue a arrancar. Es una decisión de diseño con coste: Hephaestus es probablemente el agente más potente para razonamiento difícil, y a cambio es el que menos es portable entre proveedores.

Comparado con Sisyphus, Hephaestus tiene un presupuesto de herramientas completo y puede gastar muchos tokens explorando antes de producir nada. Eso es intencionado: en un problema de arquitectura, llegar a la respuesta rápido no es un objetivo, es un error.

Prometheus: planificar antes de escribir

Prometheus es el planificador, y su rasgo más interesante es que no escribe código de producción. Ni siquiera puede. Es una restricción de diseño, no una preferencia, y hay un hook que la impone.

Su forma de trabajar es una entrevista. En lugar de asumir que entiende el problema, te hace preguntas hasta que los requisitos están claros, investiga tu código para que las preguntas estén fundamentadas, y saca a la luz casos límite que no habías considerado. Cuando está conforme escribe un plan en .sisyphus/plans/ y ahí acaba su carril.

Se entra de dos formas. O pulsas Tab en el prompt de OpenCode y seleccionas Prometheus, o te quedas en Sisyphus y escribes:

@plan refactor the auth module without behavior changes

Ese comando cambia a modo Prometheus automáticamente.

Lo que Prometheus produce es un fichero Markdown con las tareas y su verificación. Nada más. Un hook llamado prometheus-md-only garantiza que solo pueda escribir ficheros .md, así que la separación entre planificar y modificar código no depende de que el agente se porte bien.

El bucle de planificación

Prometheus no trabaja solo. Hay un bucle de tres agentes con dos puertas de calidad, y es la parte de la arquitectura que más se parece a un proceso de ingeniería de verdad.

Metis es el analizador de huecos previo al plan. Busca lo que no se ha dicho. La documentación explica el problema con una imagen bastante exacta: el autor del plan tiene memoria de trabajo con déficit de atención, hace conexiones que nunca llegan a la página, y Metis existe para atrapar lo que se le quedó en la cabeza.

Momus es el revisor del plan, y su salida es un veredicto binario. Revisa los planes vagos o no verificables y responde OKAY o REJECT. Si rechaza, el plan vuelve a Prometheus. Un plan que no puede verificarse no pasa, y esa exigencia es la que evita el fallo clásico de la planificación automática, que es un documento largo que no se puede comprobar.

Atlas: ejecutar un plan verificado

Atlas se activa solo con /start-work y su trabajo es leer un plan de Prometheus, partirlo en tareas con la forma correcta, delegar esas unidades a subagentes especializados, acumular lo aprendido entre pasos y verificar cada finalización por sí mismo.

La idea es que la inteligencia vive en el sistema, no en los agentes individuales. Prometheus ya decidió qué hay que construir, así que Atlas no vuelve a preguntar ni vuelve a decidir: conduce hasta el final.

La restricción de Atlas es la que mejor resume el diseño. No puede usar task ni call_omo_agent para delegar en otros orquestadores. Su único mecanismo de reparto es el sistema de tareas, lo que mantiene la ejecución plana y con responsables claros. Es decir: Atlas no se convierte en un Sisyphus más, delega trabajo a especialistas pero nunca devuelve el control de la orquestación a otro orquestador.

También hay un hook, todo-continuation-enforcer, que impide que se detenga porque una tarea concreta falle. Si un paso se rompe, Atlas sigue. Eso evita el fallo más común de un ejecutor automático, que es declararse bloqueado en cuanto algo sale mal y devolver el problema al humano.

El estado de todo esto vive en .sisyphus/boulder.json, y esa es la parte que hace el trabajo recuperable. Si la sesión se corta, o se apaga la máquina a mitad de un plan, el boulder conserva dónde estabas. Es la misma idea que da nombre al agente, y es lo que convierte "autónomo" en algo distinto de "imparable".

Para ejecutarlo, el flujo completo es:

@plan refactor the auth module without behavior changes

Respondes a las preguntas, Prometheus escribe el plan, y después:

/start-work

Si /start-work dice que no hay ningún plan activo, la causa es una de dos: no creaste un plan de Prometheus antes, o hay estado viejo en .sisyphus/boulder.json que hay que limpiar.

Los especialistas que trabajan detrás

Los cuatro agentes primarios no hacen el trabajo ellos mismos. Cuando necesitan contexto o una habilidad concreta, llaman a un segundo nivel. OmO incluye once agentes en total.

La tabla de restricciones es probablemente la parte más importante de la configuración, y vale la pena entender por qué existe: impide que un agente inteligente haga trabajo peligroso en el papel equivocado. Un Oracle que puede escribir archivos no sería un consultor, sería un agente con permisos de más. Un Sisyphus-Junior que puede redelegar puede crear bucles de delegación infinitos.

Trabajadores por categoría

Cuando una tarea llega a task con una categoría, OmO lanza un Sisyphus-Junior con perfil de modelo ajustado a ese dominio. La categoría elige el modelo, y las skills añaden instrucciones y herramientas MCP.

La categoría quick tiene una advertencia que merece atención, porque es contraintuitiva: el sistema desaconseja usarla para trabajo visual aunque el cambio sea pequeño. El motivo es que el criterio de quick es el tamaño del diff, y un cambio visual pequeño puede necesitar verificación en navegador, que es exactamente lo que un modelo rápido no hace.

Hay una distinción más en la semántica de la delegación que conviene tener clara porque no es obvia al leer los ejemplos. task con una categoría lanza un Sisyphus-Junior con el modelo optimizado para esa categoría. task con un subagent_type invoca a ese agente concreto directamente. Son entradas mutuamente excluyentes en una misma llamada.

Y hay un modo de ejecución en segundo plano que se usa para la investigación independiente:

task({
  subagent_type: "explore",
  load_skills: [],
  run_in_background: true,
  prompt: "Find all auth policy implementations and summarize file paths.",
});

La regla práctica es: usa el modo en segundo plano para investigación de la que la sesión principal puede seguir avanzando sin el resultado, y quédate en síncrono cuando el resultado bloquea la siguiente decisión de implementación.

Modo equipo, y por qué está apagado

Existe un modo equipo que da coordinación paralela a varios agentes con un buzón compartido, una lista de tareas compartida y un diseño opcional en tmux. Está desactivado por defecto, y la razón está en quién puede participar.

El registro de elegibilidad tiene tres niveles. Solo sisyphus, atlas y sisyphus-junior pueden participar. Hephaestus es condicional, porque no tiene permiso de compañero habilitado por defecto. Y todos los demás, incluido Prometheus, tienen rechazo explícito con un mensaje concreto.

El motivo es que un equipo necesita agentes que puedan recibir trabajo de un compañero y actuar sobre él, y la mayoría de los especialistas están deliberadamente bloqueados a solo lectura. Un equipo lleno de agentes que no pueden escribir no puede hacer nada, así que el sistema no finge que sí.

Instalación y configuración

La instalación es un instalador que hace varias cosas a la vez, y conviene entender cuáles antes de ejecutarlo. OmO se distribuye en dos ediciones del mismo producto.

Para la edición Ultimate, sobre OpenCode:

bunx oh-my-openagent install

El instalador pregunta qué suscripciones de modelos tienes, registra el plugin de OpenCode, escribe la configuración e imprime indicaciones de autenticación para los proveedores que hayas confirmado. Requiere bunx, y funciona en macOS, Linux y Windows x64.

Para la edición Light, sobre Codex CLI:

npx lazycodex-ai install

Y si quieres las dos, --platform=both. El instalador acepta banderas para no ser interactivo, lo que es lo que hace un agente cuando instala OmO por ti:

bunx oh-my-openagent install --no-tui \
  --claude=yes \
  --openai=yes \
  --gemini=no \
  --copilot=no

Los proveedores disponibles son Claude, OpenAI, Gemini, GitHub Copilot, OpenCode Go y Zen, Kimi for Coding, Z.ai y Vercel AI Gateway. Y aquí hay un detalle que afecta directamente a qué agentes puedes usar: la selección de proveedor es por agente, no global. No hay una prioridad única para todo el sistema, así que puedes tener Claude para Sisyphus y Copilot para Oracle sin que eso entre en conflicto.

Para autenticar, opencode auth login. Para comprobar que todo está bien, bunx oh-my-openagent doctor, que revisa cuatro grupos:

Un detalle que no se puede pasar por alto: la telemetría anónima de instalaciones activas está activada por defecto. Es un único evento por día UTC por máquina, con un identificador de instalación hasheado y sin perfiles de persona. Si prefieres apagarlo:

OMO_SEND_ANONYMOUS_TELEMETRY=0

La configuración vive en oh-my-openagent.jsonc, y ahí se ajustan los modelos, los prompts y los permisos.

Cuál de los cuatro elegir, en una frase

Si solo te quedas con una regla para el uso diario, que sea esta: empieza escribiendo un prompt normal, y sube de nivel solo cuando el trabajo lo justifique.

Un prompt normal va directo a Sisyphus con la menor sobrecarga posible, y es lo correcto para una corrección pequeña o una pregunta directa. Si la tarea es compleja pero prefieres autonomía, ulw y Sisyphus se encarga. Si la complejidad viene de que necesitas precisión y un rastro de decisiones verificable, entra @plan para Prometheus y luego /start-work para Atlas. Y si lo que quieres es razonamiento profundo con un único dueño y sabes que tienes un proveedor GPT disponible, cambia a Hephaestus.

La tabla de decisión que publica la propia documentación es esta:

Una observación sobre la que merece la pena detenerse: la propia documentación admite que Prometheus es una/tool más, no la más rápida, y que se debe evitar cuando la tarea cabe en un prompt o en un fichero. Planificar cuesta tiempo y tokens, y ese coste solo se justifica cuando el error de construir lo equivocado costaría más que el coste de planificar.

Un checklist antes de delegar

Cinco preguntas que te ahorran el error más común, que es usar un plan para un cambio pequeño.

¿La tarea cabe en un solo fichero? Entonces un prompt normal, sin plan.

¿Tengo un proveedor GPT disponible? Si no, Hephaestus no arranca y conviene saberlo antes de intentarlo.

¿Necesito un rastro de decisiones verificable, o solo que se haga? La respuesta decide entre Prometheus y Atlas, o entre ulw y un prompt normal.

¿Voy a pedir algo a un agente bloqueado a solo lectura? Oracle, Librarian, Explore y Multimodal-Looker no van a escribir nada, y pedirlo solo gasta tokens.

¿Necesito que el trabajo sobreviva a que se corte la sesión? Entonces el flujo @plan y /start-work es el que guarda estado en el boulder, no un ulw suelto.

La última es la diferencia menos evidente entre los dos caminos. Un ulw trabaja en la sesión y termina cuando termina. El flujo de Prometheus y Atlas deja un plan en disco y un estado que se puede retomar, y esa recuperabilidad es la razón por la que un trabajo largo se hace con plan y no con autonomía.

Lo que esto cambia de verdad

La idea que más impacto tiene de todo el proyecto, por encima de los cuatro agentes, es que la persistencia del estado y la separación de responsabilidades se resuelven con estructura, no con mejores prompts.

Casi todo lo que hace OmO son restricciones. Prometheus no puede escribir código porque un hook se lo impide. Atlas no puede delegar en otro orquestador porque su superficie de herramientas no incluye esa llamada. Sisyphus no corre en modelos incompatibles porque un hook lo bloquea. El boulder existe para que un corte no signifique un pérdida.

Y hay un efecto secundario interesante en esa filosofía de que la intervención humana es un fallo del sistema: obliga a que la verificación sea real. Si el sistema no puede pararse a preguntar, entonces tiene que estar seguro de lo que hace antes de empezar, y un agente al que no se le permite preguntar por la incertidumbre aprende a medirla antes. Ese es el coste y el beneficio de la misma decisión.

Lo que no hace OmO es escribir el trabajo por ti. La arquitectura sigue siendo tuya, las decisiones de producto siguen siendo tuyas, y el código que llega al repositorio lo vas a tener que leer igual. Lo que cambia es el trabajo de fondo: la exploración repetitiva, la planificación explícita, la distribución de subagentes y la verificación se hacen solos.

© Arturo Juárez Monroy