Plataforma Universal de Orquestación con IA

Un motor de orquestación agnóstico al dominio, con MCP como prioridad.

Describe el objetivo, no el flujo de trabajo. Dale un objetivo y decide cuál es el trabajo, cómo descomponerlo, qué capacidades necesita, qué puede ejecutarse en paralelo, cómo se validan los resultados, qué hacer cuando algo falla y si el objetivo se cumplió realmente.

No contiene suposiciones sobre tu dominio. Sin roles de agente incluidos, sin flujos de trabajo de dominio incluidos, sin proveedor fijo, sin herramientas fijas.

pip install -e ".[all]"
orchestrator init .
orchestrator run "Accomplish this objective."

Qué lo hace diferente

El modelo propone; el software dispone. El estado, la planificación, los permisos, los reintentos, la persistencia, la validación y los límites de recursos son código determinista. Un modelo se utiliza para razonar, planificar, ejecutar el trabajo y evaluar resultados subjetivos — y para nada más.

Esa división es lo que permite que la plataforma haga promesas firmes en lugar de probabilísticas:

• Una validación obligatoria fallida no puede producir COMPLETED.

• Una ejecución cancelada no puede continuar silenciosamente.

• Un agente no puede llamar, ni siquiera ver, una herramienta que no se le haya concedido.

• Cada bucle — reintentos, replanificaciones, rondas de refinamiento, iteraciones de agentes — tiene un límite impuesto.

• Una herramienta MCP descubierta no es de confianza; las anotaciones de un servidor solo pueden aumentar su riesgo evaluado, nunca reducirlo.

"Hecho" significa algo. La finalización requiere evidencia. Cuando no existe una verificación determinista, la plataforma informa UNCERTAIN en lugar de suponer. Un modelo puede alcanzar LIKELY; nunca puede certificar CONFIRMED.

El núcleo tiene cero dependencias. Todo lo demás — CLI, API REST, proveedores de modelos HTTP, YAML — es opcional. MCP sobre stdio funciona en una instalación mínima, porque el cliente de protocolo está implementado de forma nativa.

Related MCP server: agentloop

Postura de seguridad

Esta plataforma ejecuta herramientas con argumentos que un modelo eligió. Ese único hecho define el diseño de seguridad, y los controles se aplican en código en lugar de pedirse al modelo.

Declara un perfil de despliegue. Omitirlo significa production.

profile: production   # development | internal-pilot | production

Lee antes de desplegar:

• SECURITY.md — modelo de amenazas, qué se defiende y qué no

• docs/security.md — cada control, con su prueba

• docs/production-readiness.md — lista de verificación de 108 elementos, cada uno marcado como completo / incompleto / responsabilidad del operador

• deployment/runbook.md — tres formas de despliegue

• docs/configuration.md — cada ajuste

Alcance de la afirmación

Admite despliegue controlado en producción detrás de un proxy con TLS/autenticación: ya sea de instancia única sobre SQLite, o de múltiples instancias sobre PostgreSQL (storage.backend: postgres).

Explícitamente no admite: múltiples instancias sobre SQLite, aislamiento forzado de contenedores/sandboxes/remoto, validación OIDC JWT en proceso ni ninguna identidad reenviada por proxy (los tokens de portador son el único mecanismo de identidad), ejecución de procesos sin un límite de aislamiento externo, ni ninguna garantía de corrección de la salida de IA.

Verificado en dos réplicas en la pila Compose incluida: estado compartido de PostgreSQL, revocación distribuida de tokens, limitación de tasa distribuida, salida forzada a través de un proxy y un límite TLS que elimina las cabeceras de identidad proporcionadas por el cliente. La plataforma proporciona validación basada en evidencia, informes de confianza, un revisor adversarial, compuertas de aprobación humana y una prueba de regresión determinista — nada de lo cual hace que la salida del modelo sea correcta; hacen que la base para confiar en ella sea inspeccionable.

python -m pytest tests/ -q        # 699 with PostgreSQL
orchestrator validate             # effective posture and migration notices
orchestrator evaluate             # 31 deterministic regression cases
orchestrator migrate              # schema status

Una ejecución, de principio a fin

objective
   → goal analysis        structured requirements, provenance-tagged
   → pattern selection    deterministic complexity scoring
   → planning             validated task DAG (or a deterministic fallback)
   → scheduling           dependency-aware, parallel, resource-locked
   → per task             capability-routed agent, least-privilege scope,
                          bounded loop, independent validation gate
   → recovery             classify → strategy ladder → retry/swap/re-plan/ask
   → objective gate       success criteria, checked
   → review               structural precondition on completion
   → COMPLETED

Cualquier fase puede detenerse y esperar a un humano, pausarse o cancelarse — y reanudarse desde el estado persistido posteriormente, incluso después de que el proceso muera.

orchestrator inspect <id>    # the task graph, validations, failures
orchestrator audit <id>      # every decision, in order

Patrones de orquestación

Fragmentos de grafo componibles, no modos. Un abanico paralelo cuyo paso de fusión es un bucle evaluador-optimizador es simplemente un grafo.

single agent · sequential · parallel · router · orchestrator-worker · evaluator-optimizer · hierarchical · handoff · dynamic DAG

Un router materializa cada rama y poda las que no eligió. Una tarea puede entregar su trabajo restante a un especialista diferente, con límites para que los pares no puedan pasárselo en un círculo. Y una tarea puede ser una ejecución orquestada completa por sí misma, con su presupuesto extraído del de su padre en lugar de añadido a él.

La plataforma elige uno a partir de la estructura del objetivo. Un objetivo trivial consigue un agente y una verificación — no diez agentes y cuatro revisores. Anula con --pattern cuando quieras.

Capacidades, no roles

Nada se enruta por nombre. Una tarea declara lo que requiere; un agente anuncia lo que proporciona; la selección es una puntuación determinista que prefiere el menor privilegio excesivo. Cuando nada cubre un requisito, se crea un especialista efímero con alcance limitado — y cuando la deficiencia no es real, la selección falla ruidosamente en su lugar.

El núcleo no incluye capacidades, agentes ni habilidades. Estos provienen de la configuración, los plugins o el planificador. Eso es lo que lo mantiene neutral respecto al dominio.

Las habilidades son la tercera pieza: conocimiento reutilizable, como contenido en lugar de código. Una habilidad le dice a un agente cómo abordar un trabajo que ya estaba autorizado a hacer, y no le concede nada más.

MCP

De primera clase en ambas direcciones, implementado de forma nativa sobre JSON-RPC 2.0 sin dependencia de SDK. Los versiones de protocolo se negocian, no se asumen.

Como cliente: los servidores se descubren, se describen, se verifican según la política, se autorizan, y solo entonces se registran — de modo que un agente llama a una herramienta MCP exactamente igual que llama a cualquier otra cosa.

orchestrator mcp    # health, negotiated version, registered tools, refusals

Como servidor: orchestrator mcp-serve expone la orquestación a otros sistemas de agentes. Las operaciones de control permanecen detrás de --allow-control.

Documentación

Estado

701 pruebas. 699 pasan cuando hay una instancia de PostgreSQL accesible; sin ella, 659 pasan y 42 pruebas respaldadas por PostgreSQL se omiten. Cada subsistema se ejercita contra almacenes reales, un subproceso de servidor MCP real e inyección deliberada de fallos. Los controles de múltiples réplicas — revocación compartida de tokens, limitación de tasa compartida, aplicación de la política de salida y el límite TLS — se verifican contra la pila Compose de producción en ejecución mediante deployment/smoke-test.sh, no solo en pruebas unitarias.

Las limitaciones conocidas se registran honestamente en docs/production-readiness.md y docs/research/ORCHESTRATION_RESEARCH.md en lugar de dejarse para que se descubran.

Apache-2.0.