Contexto
Cortex es un agente de gestión de proyectos que conecta requisitos, recursos y preparación para el lanzamiento en todo un portafolio. Lo construí como capstone de la certificación Agentic Loops for PMs de Product School, en Python con OpenAI gpt-4o-mini como agente y gpt-4.1 como crítico, dirigido con Claude Code.
Problema
Los PMs pierden horas cada semana armando actualizaciones de estado a mano: revisando Slack, GitHub y Jira, conciliando lo que se entregó y depurando un backlog que nunca termina de depurarse. Una actualización manual me lleva cerca de una hora. El trabajo de criterio queda desplazado por el trabajo de mantener a todos informados.
- Lo difícil no es redactar. Este trabajo toca la comunicación con el liderazgo, un roadmap confidencial y compromisos reales.
- Un agente que se equivoca en público cuesta una confianza difícil de recuperar.
Mi rol
Product manager y constructor. Dirigí un agente de programación y no escribí código a mano. Fui responsable del planteamiento del problema, de dónde está la línea humana, los límites, las evaluaciones y la escalera de confianza.
Lo que construí
- 1.
Se activa
Con un cambio en el proyecto (hook) o un barrido matutino (cron de respaldo).
- 2.
Recopila
El proyecto, su actividad de ingeniería, actualizaciones pasadas, el roadmap y las normas del equipo.
- 3.
Redacta
Una actualización de estado para el liderazgo con riesgos, decisiones y próximos pasos, más hasta 5 historias de backlog propuestas.
- 4.
Se revisa a sí mismo
Un modelo crítico independiente revisa el borrador en fundamento, trabajo entregado, compromisos, filtraciones confidenciales y reglas de estado, y lo devuelve si falla.
- 5.
Se detiene en un punto de control humano
No se publica nada, no se compromete ninguna fecha, no se crea ningún ticket.
- 6.
Decisión: trazar la línea en el código, no en los prompts.
Clasifiqué cada acción por reversibilidad, alcance del daño y medibilidad. Publicar una actualización para toda la empresa, comprometer una fecha y decidir qué escalar quedan en manos de una persona. Cortex no tiene ninguna herramienta para publicar, así que esa línea no se puede eludir con palabras.
- 7.
Decisión: añadir un segundo modelo antes que uno más grande.
Siguiendo un enfoque Lean AI, Cortex funciona con un modelo pequeño. Cuando la evidencia mostró que el revisor se equivocaba, mejoré solo el crítico.
- 8.
Decisión: limitar cada ejecución.
Topes estrictos de 6 pasos, 60 segundos, $0.10 por ejecución y $1 por día, un límite de 5 historias en cola, un interruptor de apagado y una protección contra inyección de prompts. Cada parada termina con el borrador retenido y un motivo visible para una persona.
- 9.
Decisión: recordar solo lo que una persona aprobó.
Las actualizaciones aprobadas se vuelven memoria. Los borradores no aprobados y los registros se eliminan. Los proyectos confidenciales quedan fuera de la recuperación.
- 10.
Decisión: definir la autonomía por usuario, no por producto.
PM del proyecto: supervisado hoy, aprueba cada borrador a diario. Líder de ingeniería: autónomo con límites (planeado), necesita alertas de riesgo rápido. Ejecutivo: asistido, solo ve actualizaciones aprobadas por personas.
Resultados
En números
- 6 evaluaciones
- Más 7 ejecuciones grabadas, fallos incluidos
- $0.015
- Ciclo completo en 5 pasos, de principio a fin
- 0.07¢ a 2.2¢
- Rango de costo en ejecuciones reales
- 0 publicaciones
- Nada se publica sin una persona
Lo que mostraron las evaluaciones
- Detectado
- Ejecución completa: el crítico detectó una fecha límite inventada; la revisión pasó y se detuvo en el punto de control humano.
- Escalado
- Datos faltantes: ante un proyecto que no existe, Cortex no inventó nada y escaló.
- Protegido
- Jailbreak: sin la protección, Cortex ignoró el ataque pero aun así terminó aprobado. Con la protección en código, lo marcó y escaló, y no se publicó nada.
- Retenido
- Tope alcanzado: con el límite de pasos reducido, el ciclo se detuvo por el límite, no por éxito, y retuvo el borrador.
- Abierto
- Fallos honestos: la recuperación a veces trae datos de otros proyectos, y el crítico una vez aprobó una historia de trabajo ya entregado. Ambos están registrados como requisitos para más autonomía.
Qué aprendí
- Parecer aprobado no es lo mismo que ser seguro. Una ejecución impecable no probó nada hasta que una evaluación intentó romperla.
- Los límites van en la infraestructura. Lo que un agente no puede hacer importa más que lo que se le dice que no haga.
- Escalar es un estado de éxito. Un borrador retenido con un motivo es mejor que una respuesta segura y equivocada.
- La próxima vez, las evaluaciones primero. Antes de la primera línea de la construcción.
Lo que aún no es
- No es autónomo. Cortex está en modo supervisado: cada borrador espera a una persona.
- Para pasar a autónomo con límites (solo alertas de riesgo para líderes de ingeniería), debe superar 4 semanas y más de 20 ejecuciones: evaluación de jailbreak al 100%, evaluaciones de proyecto correcto y finalización de tareas al 95% o más, cero filtraciones confidenciales y 90% o más de borradores aprobados sin correcciones de hechos. El operador lo aprueba por escrito. El primer incidente lo baja un escalón.
- El ROI aún no se ha medido. El objetivo es pasar de una hora por actualización a 15 minutos de revisión, por menos de 3¢ por ejecución. La hora de referencia es mi propia estimación.