Locale: es
Nota: este artículo separa la información pública verificable a 4 de octubre de 2026 de impresiones prácticas de uso. Las capacidades públicas de Astra, Codex y Claude Opus 5.5 se contrastaron con fuentes oficiales. Frases como “Astra tiende a ampliar demasiado la exploración” o “Dot funciona bien como supervisor” describen una experiencia concreta, no un benchmark universal. “Dot” es aquí el nombre del rol supervisor.
1. Conclusión: no conviertas un solo modelo en toda la empresa
Cuando una IA es potente, resulta tentador pedirle todo:
investigar, diseñar, programar, probar, recuperarse de fallos, gestionar el progreso y explicar el resultado.
Eso son varios trabajos disfrazados de un único prompt.
Una división práctica es:
- Exploración: Astra — busca causas, alternativas, supuestos omitidos y riesgos de arquitectura
- Supervisión: Dot — limita el alcance, sigue el estado, detecta bloqueos y decide el siguiente paso
- Ejecución: Codex — modifica código y archivos, investiga y ejecuta pruebas
Si un único modelo puede cerrar el trabajo de principio a fin, no hay obligación de crear un equipo. Anthropic presenta Claude Opus 5.5 para programación agéntica, tareas complejas con varias herramientas y trabajos prolongados.[5]
La regla es simple:
un agente si cierra el trabajo; varios roles si el trabajo se dispersa.
2. Una gran capacidad de exploración también puede ampliar el alcance
Cuando la causa es desconocida, un agente explorador es excelente.
Cuestiona supuestos. Busca dependencias ocultas. Propone diseños alternativos. Sigue la causa raíz.
El problema aparece cuando una tarea rutinaria recibe el mismo tratamiento.
“Arregla este botón” puede convertirse en: “revisemos toda la arquitectura del componente”, “analicemos los servicios relacionados”, “mejoremos la extensibilidad futura”, “limpiemos dependencias antiguas”.
Y el botón sigue roto.
OpenAI describe la orquestación de agentes como la decisión de qué agente se ejecuta, en qué orden y cómo se elige el siguiente paso, distinguiendo entre orquestación dirigida por LLM y por código.[1]
Explorar no es lo mismo que terminar.
3. Dot funciona mejor como capataz que como otro genio
El supervisor necesita saber:
- qué tarea está activa
- qué terminó
- qué falló
- quién actúa después
- cuándo escalar
Si Astra propone un rediseño completo, Dot puede responder: “Bien, crea otra tarea. Primero restaura el servicio.”
Si Codex falla una prueba, Dot devuelve el log.
Si el mismo fallo aparece tres veces, se escala a Astra.
El supervisor no es glamuroso. Es quien evita que la línea se quede parada mientras todos debaten la fábrica perfecta.
4. Codex es más controlable con límites claros
Conviene darle:
- repositorio
- archivos objetivo
- síntoma
- alcance permitido
- criterio de éxito
- pruebas obligatorias
- formato de retorno
Si el objetivo real es que un PR pase, no hace falta pedir estrategia corporativa.
OpenAI presentó Symphony como un sistema donde issues y tareas son unidades duraderas de trabajo, en lugar de centrar todo en una sesión de programación.[2]
La conversación no es el trabajo. La tarea sí.
5. thread_id ayuda, pero task_id debe ser la clave principal
source_thread_id sirve para saber dónde devolver la respuesta.
Pero un hilo puede contener varias preguntas.
Separa al menos:
- task_id
- source_thread_id
- source_message_id
- manager / executor / advisor
- status
- attempt
- next_action
Estados básicos: pending, working, blocked, review, done, delivered, failed.
“Creo que ya está” no es un estado.
6. Bucle pequeño: Dot↔Codex; Astra solo cuando hay bloqueo real
Normal:
Dot → Codex → Dot → Codex
Escalado:
Dot → Astra → Dot → Codex
Ejemplos de disparadores:
- el mismo fallo tres veces
- varias causas plausibles sin forma de diferenciarlas
- cambio arquitectónico necesario
- varios repositorios implicados
- conflicto entre petición y especificación
Así Astra se convierte en especialista, no en miembro permanente de todas las reuniones.
7. Un plan premium temporal no debe convertirse en infraestructura permanente
Que una función esté disponible hoy no significa que vaya a formar parte del sistema para siempre.
Guarda el conocimiento operativo:
- estado de tareas
- prompts
- criterios de aceptación
- pruebas
- límites de reintentos
- reglas de escalado
- logs de fallo
El modelo puede ser un acelerador. No debe ser el único sitio donde vive el proceso.
8. Si Opus 5.5 hace de 0 a 10, utiliza el sistema más simple
Los diagramas multiagente son divertidos.
Supervisor, investigador, ejecutor, revisor.
Después, el humano acaba siendo Recursos Humanos de una empresa de bots.
Ese no es el objetivo.
Anthropic describe Opus 5.5 para programación agéntica, trabajo prolongado y flujos complejos con varias herramientas.[5]
Si en tu entorno pasa de objetivo a investigación, implementación, pruebas, reparación y cierre de forma fiable, usarlo directamente puede ser mejor.
No fundes IA S.A. si una sola persona cierra el ticket.
9. Arquitectura mínima
- Cada pregunta o incidente entra en una cola con task_id.
- Dot decide prioridad y siguiente acción.
- Codex ejecuta.
- Dot valida.
- Astra entra solo si se activa una regla.
- La respuesta vuelve a source_thread_id.
- Se cierra tras confirmar delivered.
- Los trabajos realmente end-to-end pueden ir directamente a Opus 5.5.
La infraestructura guarda roles:
manager executor advisor
No nombres de modelos.
10. Resumen: más IA no significa más automatización
La parte difícil no siempre es pensar más.
Es saber cuándo dejar de pensar y ejecutar.
Exploración amplía el mapa. Supervisión cierra el bucle. Ejecución mueve los archivos.
Separados:
Astra: “Encontré siete opciones.” Dot: “Prueba la segunda.” Codex: “Arreglado. Las pruebas pasan.” Dot: “Cerrado.”
De repente parece una empresa.
Keep the loop tight.
Más agentes no equivalen a más automatización.
Automatizar significa llegar a un final verificable sin que una persona tenga que rescatar el proceso continuamente.
