SOMEP, un patrón de orquestación de agentes que reparte el trabajo y exige evidencias

Un ingeniero publicó esta semana un prompt con el que pretende que el modelo deje de comportarse como un asistente y pase a actuar como orquestador. Lo llama SOMEP (Self-Orchestrating Multi-Agent Execution Protocol) y la propuesta es que el LLM descomponga la misión, reparta el trabajo entre agentes especializados, verifique cada entrega y siga avanzando sin pedir instrucciones ni aprobaciones intermedias. El autor pide que le corrijan, se presenta como un ingeniero cualquiera y no enseña repositorio, demo ni una sola medición.

El mecanismo se apoya en tres patrones de control que se pueden anidar. Ejecución secuencial, cuando una tarea depende de la salida ya validada de otra. Ejecución condicional, cuando el siguiente paso depende de un estado observado, de un resultado de test o de una comprobación explícita. Y ejecución en bucle, cuando hay que repetir hasta cumplir una condición de salida medible. El paralelismo queda como una optimización dentro de esos tres flujos, nunca como sustituto. La regla con más carga es la de los bucles: cada uno debe declarar su condición de continuación, la de éxito, la de fallo y la evidencia necesaria para salir, y el prompt prohíbe cerrar un ciclo solo porque el agente afirme que ha terminado.

Investigar antes de decidir

El texto obliga además al modelo a desconfiar de su conocimiento previo. Si una parte del trabajo depende de información reciente, cambiante, discutida o verificable por terceros, tiene que investigar antes de tomar la decisión o de implementar nada, con prioridad en fuentes primarias: documentación oficial, especificaciones, repositorios de código, notas de versión, referencias de API o registros de primera mano. Lo que venga de la memoria se etiqueta como UNVERIFIED, y si dos fuentes fiables se contradicen, el conflicto se conserva en lugar de resolverse a ojo.

El contrato de cada agente

Para cada tarea delegada, el orquestador genera un contrato completo: identificador, rol del especialista, objetivo, estado actual, contexto y fuentes autorizadas, entradas, dependencias, restricciones e invariantes, acciones permitidas y prohibidas, ámbito de escritura, salidas esperadas, criterios de aceptación, evidencia exigida, condiciones de fallo y formato de retorno. El autor insiste en que no se inventen agentes, herramientas, permisos ni estado del sistema: si el entorno no soporta ejecución multiagente real, los roles se ejecutan en serie y hay que decirlo.

Todo se sostiene sobre un grafo de tareas vivo con estados explícitos: BLOCKED, READY, RUNNING, VERIFYING, REPAIR_REQUIRED, COMPLETE, FAILED y OWNER_REQUIRED. Buena parte de esto ya se hace a mano en cualquier pipeline de agentes que funcione, con más pegamento y menos glamour; lo que añade el texto es ponerlo por escrito como instrucciones que el modelo debe cumplir por sí mismo.

Lo que no hay es nada que demuestre que esto funcione mejor que un prompt corto. La publicación llegó cortada a mitad de frase, sin versión numerada ni ejemplos de ejecución, así que usarla como plantilla exige podarla bastante. Lo aprovechable hoy es la lista de campos del contrato de worker y los estados del grafo: sirven como checklist al diseñar un pipeline de agentes, aunque quien orqueste siga siendo una persona y no un modelo.

El caso ilustra hacia dónde va una parte de la ingeniería de prompts: menos frases ingeniosas y más disciplina de sistema distribuido metida dentro del contexto. La duda razonable es si un LLM sostiene ese nivel de rigor durante cientos de pasos o si el grafo acaba viviendo fuera del modelo, en código que sí puede garantizar los estados que aquí solo se le piden por escrito.