El motor y la neutralidad
Neutralidad como capacidad actual
El motor coordina encargos y ejecuta contratos de agente. Su núcleo no presupone un proveedor de modelos ni una herramienta concreta: los runners son adaptadores intercambiables. Claude, OpenAI y Kimi Code son las vías vigentes, todas por suscripción. Ninguna herramienta concreta es una dependencia necesaria del arnés.
El contrato estable de un agente define qué puede hacer, qué no puede hacer y qué entrega. El runtime solo aporta la ejecución efímera de ese contrato. Cambiar de modelo o de runner no cambia la identidad del agente ni obliga a reescribir el motor.
Protección frente a la propia operación
Contención del alcance de escritura
Cada encargo declara su ámbito de trabajo. El motor limita la escritura al proyecto y las rutas permitidas; además compara el árbol antes y después de la ejecución. Las reglas, los secretos y los proyectos declarados inmutables quedan fuera del ámbito. Una escritura fuera de alcance se detecta y el resultado no se acepta como entrega válida.
Como la comparación del árbol también ve lo que otra sesión escribe a la vez, el motor solo imputa al agente un cambio en otro proyecto si el agente llegó a nombrar esa ruta en sus herramientas. Las rutas protegidas, los proyectos cerrados y lo que queda fuera del árbol se imputan siempre.
Un solo motor vivo
El motor toma un cerrojo de proceso al arrancar: un segundo arranque sobre el mismo arnés se niega y dice quién tiene el cerrojo. Solo el titular del arnés arranca, detiene o relanza el motor; ninguna sesión ni ningún agente lo hace «para desatascar».
Rechazo por contrato
Si cumplir un encargo obligaría a un agente a infringir una regla firme de su contrato, el agente no entrega una aproximación. Deja un rechazo explícito con el motivo y lo necesario para desbloquearlo; el motor devuelve el encargo a Dirección para su corrección o reenrutado. Rechazar por contrato es una señal operativa, no una entrega parcial.
Precondiciones antes de invocar
Antes de despertar a un agente, el motor comprueba las condiciones verificables del encargo: destinatario, proyecto, alcance y dependencias declaradas. Si falta una condición, lo devuelve tempranamente sin invocar un modelo. Así se evita gastar una ejecución en descubrir un bloqueo que el sistema podía detectar de antemano.
Un permiso denegado no cierra el turno
Cuando la herramienta de un agente pide un permiso que nadie puede conceder en ejecución desatendida —por ejemplo, trabajar en un directorio fuera de su árbol—, el rechazo vuelve al modelo como error de esa herramienta y el turno continúa. Antes cerraba la sesión entera sin entregar nada.
A quién se avisa
Los avisos que Dirección puede resolver —un encargo que terminó sin entregables, uno devuelto por contrato, una escritura en otro proyecto— llegan a la Dirección como encargo en su propia cola. A la persona solo se le escribe cuando hace falta una persona: cuando se agotan todas las vías de modelo, cuando un agente toca una ruta protegida o un proyecto cerrado, o cuando el que falla es la propia Dirección.
Continuidad con calidad
La política de modelos aplica una cadena ordenada por agente. Si se agotan las vías adecuadas, el motor espera a que vuelva la cuota y reintenta con la misma cadena; si tampoco entonces hay vía, se detiene, conserva la trazabilidad y avisa; no sustituye una revisión o un sello por una salida de calidad inferior. Consulta la tabla completa en Modelos por agente.