Un método para gestionar agentes de IA
Operchief
Project Method
Dos postulados Operchief«Los sistemas de IA han cruzado el umbral de la capacidad cognitiva humana».«Un agente de IA basado en LLM es un sistema probabilístico altamente erudito en el que la pérdida de contexto y la fabricación plausible son modos de operación intrínsecos, no fallos».Operchief Project Method se deriva de estos dos postulados. Es una forma de trabajar con un agente de IA para que el proyecto sea dirigido por una persona, no por el flujo de mensajes de un chat.
Operchief Project Method (OPM) es un método para personas no profesionales que trabajan con agentes de IA en proyectos personales y de afición de cualquier tipo. Los profesionales usan disciplinas parecidas, pero suelen ajustarlas a un tipo de trabajo, un agente o un entorno concreto. OPM es más simple y más general: funciona con cualquier IA moderna y en cualquier entorno de trabajo, desde un chat en el navegador hasta Cursor, Codex, Claude Code o Antigravity.
En el fondo, OPM es un conjunto de reglas estrictas para el agente: no cambiar archivos del proyecto sin autorización, planificar el trabajo en detalle y registrar los resultados en logs. Su objetivo es convertir el trabajo con un agente en un sistema de proyecto manejable: simple, barato y utilizable por no profesionales.
En ese sentido, OPM va contra la corriente principal del vibe coding. No es «hazme un buen proyecto con un solo prompt». Es trabajo cuidadoso entre una persona y un agente: dividir el trabajo en etapas, mantener el control en cada etapa y hacer que el resultado sea verificable.
OPM no sirve solo para programar. Sirve para cualquier trabajo asistido por IA que requiera iteración: escribir un artículo, construir un prototipo con Arduino, traducir un libro o llevar un proyecto personal por varias rondas de revisión.
También abarata el trabajo con IA. Los chats largos obligan a los modelos a releer contexto antiguo; la gente evita abrir un chat nuevo por miedo a perder el hilo, y miles de tokens se gastan en historial viejo. Si te alejas del ordenador, la caché del servidor puede expirar y el modelo vuelve a leer la misma historia a tu coste. OPM mueve el contexto a archivos del proyecto, por lo que resulta más fácil iniciar sesiones nuevas, incorporar varios modelos y separar la planificación de la ejecución.
Cuatro apoyos de OPM
- I
La autoridad permanece en la persona
La persona es la única fuente de decisiones en el proyecto. En OPM, ese papel se llama Operchief: el director de operaciones del proyecto (chief operating officer, COO). El agente analiza, planifica, propone y ejecuta lo que aprueba el Operchief. El agente no tiene autoridad propia.
- II
El PIN separa las palabras de la acción
El agente trabaja en dos modos, y la frontera entre ellos es absoluta. El guardián de esa frontera es el PIN: un código numérico escrito explícitamente por el Operchief. El modo de discusión y análisis es el modo por defecto: leer, analizar, planificar, revisar riesgos, preguntar y aclarar está permitido, pero cambiar cualquier archivo está prohibido. El modo de ejecución empieza solo después del PIN y solo dentro del plan aprobado.
- III
Los logs son la memoria externa del proyecto
Las decisiones, los planes y la historia del trabajo se guardan en documentos y logs del proyecto. Un chat nuevo recupera el contexto desde esos archivos, de modo que la persona no tiene que volver a explicar a cada agente nuevo las reglas, el sentido del proyecto o la tarea actual desde cero.
- IV
StepLoop convierte el control en trabajo
Toda acción que cambia archivos del proyecto pasa por el ciclo: planteamiento de la tarea, análisis de los archivos relacionados, plan, registro del plan en el log, ejecución, informe, revisión, vuelta a la planificación si la revisión falla, o registro del resultado y archivo si el resultado se acepta. El ciclo no se acorta.
La persona está presente en cada etapa, pero no siempre en el mismo papel: a veces como especialista en la materia, a veces como coordinador entre agentes y a veces simplemente como guardián del protocolo.
Incluso cuando el Operchief no puede juzgar personalmente el código, puede traer otro agente para revisarlo, apoyarse en una tarea bien especificada y mantener al agente ejecutor bajo la suposición de que su resultado será comprobado. Esa suposición por sí sola ayuda a prevenir errores y comportamientos extraños.
El ciclo StepLoop para resolver cualquier tarea con un agente de IA
Un StepLoop es la unidad básica de cualquier trabajo que cambia archivos del proyecto. No es una "unidad de planificación" ni una "tarea" genérica; es un orden fijo que el agente debe seguir para cada cambio. Acortar el ciclo porque una tarea parece pequeña es exactamente el punto en el que el agente deja de ser ejecutor.
Un PIN se interpone entre las palabras del agente y sus acciones. En su forma más simple, StepLoop requiere tres PIN.
El primero autoriza escribir el plan en el log. Puede parecer excesivo, pero cuando un plan está aprobado y escrito, el Operchief puede abrir un chat nuevo y soltar el contexto antiguo, traer un agente consultor o entregar el plan registrado a un agente ejecutor más simple y barato.
El segundo PIN autoriza la ejecución: el Operchief ha completado las consultas necesarias y está listo para que el agente lleve a cabo el plan. El tercer PIN cierra el StepLoop: el Operchief ha verificado que el trabajo se hizo correctamente y cierra la tarea.
Si el resultado no se acepta, el ciclo vuelve al plan y empieza de nuevo.
Plantillas y documentación
Las plantillas son la forma operativa del método. Son texto plano, Markdown, sin paso de build y sin dependencias. El bootstrap prompt despliega el núcleo en un proyecto limpio: pide el briefing, genera Node IDs y coloca los archivos en su sitio.
Download OPM_template_en.zip| № | Archivo | Plantilla | Rol |
|---|---|---|---|
| 01 | AGENTS_TEMPLATE_en.md | Protocolo principal | La constitución del proyecto: autoridad, modos de trabajo, StepLoop, PIN y prioridades de conflicto |
| 02 | AGENT_BRIEF_TEMPLATE_en.md | Brief del agente | Entrada rápida del agente: navegación por documentos, reglas de trabajo y términos del proyecto |
| 03 | PROJECT_BRIEF_TEMPLATE_en.md | Brief del proyecto | Sentido del proyecto: audiencia, MVP, métricas, aceptación, restricciones y riesgos |
| 04 | AGENT_LOG_TEMPLATE_en.md | Log de trabajo | TODO, StepLoops abiertos, commits y encabezados de los últimos ciclos cerrados |
| 05 | AGENT_LOG_ARCHIVE_TEMPLATE_en.md | Log de archivo | Historia del proyecto: StepLoops de primer nivel cerrados y TODO completados |
| 06 | BRIEFING_SOURCE_TEMPLATE_en.md | Cuestionario bootstrap | Respuestas estructuradas que el bootstrap prompt usa para crear el núcleo del proyecto |
| 07 | PROMPT_0_IDE_en.md | Prompt bootstrap (IDE) | Instrucciones para un agente con acceso directo a archivos: Cursor, Codex, Claude Code, Antigravity |
| 08 | PROMPT_0_CHAT_en.md | Prompt bootstrap (chat) | Instrucciones para un agente sin acceso a archivos; Operchief aplica los cambios manualmente |
| 09 | HUMAN_NOTE_en.md | Nota humana | Una nota para Operchief sobre el sentido y uso del método |
| 10 | README_en.md | Instrucciones del archivo | Contenido de OPM_template_en.zip y orden de despliegue |
La plantilla OPM se distribuye como un único archivo ZIP en inglés. El despliegue lo gestiona el bootstrap prompt: la versión IDE es para un agente con acceso a archivos, y la versión chat es para trabajar mediante conversación. Los archivos individuales de plantilla no se publican como descargas separadas.