Muchos agentes, una fábrica
Coordina varios agentes/sesiones bajo un Chair por proyecto: el primer asiento que abre. Bus de mensajes, locks compartidos, proyectos y shared que tú declares.
Orchemax
Gobierna equipos multi-agente de IA sin destrozar el repo ni el presupuesto
Los agentes en paralelo necesitan un chair, reglas y trabajo en equipo — no otra pestaña de chat. Fábrica local + mirador del CTO; tus CLIs siguen nativos bajo el asiento.
“Como founder o CTO, tu trabajo es sacar apps y facturar: no construir la infraestructura para cuidar IAs. Por el costo de una semana del ingeniero más barato, obtén una línea de montaje local auditada y 100% en tu hardware.” — Comprar vs construir (pitch del producto)
Trabajo multi-agente: con gobernanza
Realidad diaria: varios agentes, varias sesiones, un solo codebase. Orchemax existe para que el caos tenga chair, locks, reuso compartido y un mirador gerencial: no otro autocomplete.
Trabajo en equipo sin pisarse
Los agentes hacen handoff en disco, buscan en shared antes de inventar y toman lock antes de editar código común: así las sesiones paralelas no reescriben el mismo helper tres veces.
Alto al desastre duplicado
Las reglas de reuso compartido mantienen la arquitectura mientras el piso corre caliente. El código queda en tus máquinas; el SaaS nunca ve el source.
Cómo trabajas
Solo el flujo del día a día: lo que haces en tu máquina. Sin la receta secreta; orch deja el cableado bajo el asiento.
1. Instala y enlaza
Pon orch en su propia carpeta. Corre orch setup y elige un workspace aparte para tu código. La instalación del cliente no es el hogar del taller.
2. Abre un asiento
Entra a una carpeta de proyecto registrado y corre orch opencode, orch claude, orch commandcode o tu agente. El primer asiento interactivo es el Chair. Un segundo Chair en el mismo proyecto se bloquea.
3. Chair vs workers
Por qué un solo Chair: si cada agente actúa como director, se pisan los mismos archivos, inventan helpers duplicados y el trabajo se enreda. Los workers son para tareas secundarias: dirigidas por ese Chair: no una segunda orquesta en el mismo proyecto. El orden de llegada elige el Chair; no lo nombras en el chat. ¿Más manos? Spawnea workers; no abras otro Chair.
4. Código shared
Antes de editar rutas comunes, toma un lock. Edita. Suéltalo al terminar para que los compañeros vean el refresco. No edites shared sin lock.
5. Habla por el bus
Los asientos dejan notas cortas y handoffs entre sí (inbox / notices). Usa la mensajería de orch: no un chat paralelo del vendor entre agentes.
6. Nube opcional
Vincula una cuenta Orchemax cuando quieras topes, visibilidad de gasto y el mirador del CTO. El source se queda local; la nube ve metadatos, no tu repo.
Orchemax vs otros orquestadores de agentes
Los pares son orquestadores (Orca, Traycer, OpenClaw, Hermes, Prime Agent…): no Claude ni Cursor. Mapa de capacidades: donde otros van delante, cerramos el gap. Sin trofeos: solo hechos.
Desliza de lado para ver todas las columnas.
| Capacidad | Orca | Traycer | OpenClaw / Hermes | Prime Agent | Orchemax |
|---|---|---|---|---|---|
| Trabajo | ADE / IDE de agentes en paralelo | Host + tasks alrededor de BYO | Gateway personal multi-canal | Harness de coding / research que se mejora | Taller gobernado + mirador CTO |
| UI nativa del agente | Paneles / terminales en ADE | Chat / Terminal Host | Su propia cara de runtime | TUI / daemon propio | orch debajo de CLIs BYO |
| Un director por proyecto | Modelo coordinator / Run (ADE) | Host centrado en tasks | Suele ser un cerebro personal | Puede spawnear peers; riesgo multi-director | Un Chair; workers solo para tareas secundarias |
| Evitar que se pisen en shared | Aislamiento por worktree (ley de taller delgada) | Artifacts / reviews: sin locks de shared | No es fábrica de repo | Sin locks / ley de símbolos de taller | Locks de shared + reglas de reuso |
| Bus agente↔agente | Mensajes / gates de orquestación | A2A con gates de capacidad | Canales a humanos / tools | Mensajería por roles + roster | Bus en disco + roles parent/child/sibling |
| ADE desktop / companion móvil | ADE desktop + companion móvil | App Host / Sync | Apps de canal, no ADE | Foco CLI / daemon | Consola + mirador en browser primero |
| TG / WA comando + approve | Steer móvil (ruta de producto) | Limitado vs bots de canal | Bots personales maduros de Telegram / WhatsApp | No es el wedge central | Plan Team · HITL Telegram (en shipping) |
| Harness largo que se auto-mejora | No es el headline | No es el headline | Continuidad de sesión | RLM + Continual Harness /refine | Memory/brief + orch refine MVP (sin RLM Python) |
| Chair en CLI BYO spawnea workers | Coordinator / Run dentro del ADE | Host + tasks (cara propia) | No es fábrica de repo multi-CLI | Puede spawnear peers (riesgo multi-director) | MCP dispatch_worker / task_* bajo cualquier CLI nativo Chair (orch opencode|claude|commandcode|…); un Chair; ledger+policy |
| Overlook org + planes visibles | Comercial opaco en el pitch | BYOA + tiers de pago | Personal / self-host, no SaaS org | Harness OSS, no overlook FREE→TEAM | FREE→TEAM + overlook de metadatos |
| ¿El source sale de tu máquina? | ADE local (tu hardware / SSH) | Host local; cloud sincroniza tasks | Self-host / tu gateway | Ejecución local del agente | Código local; SaaS solo metadatos |
Matriz viva: actualizada 2026-09-13 (Chair MCP dispatch_worker / task_*). Reescribimos celdas cuando cerramos un gap. Herramientas complementarias pueden vivir junto a Orchemax; el wedge es ley del taller + mirador, no “otro ADE.”
Workspace ≠ proyecto
Solo ilustración: no es una plantilla obligatoria. Tú declares las rutas; Orchemax enlaza
.orch/ + orch.yaml y mide proyectos registrados, no el escaneo de carpetas.
acme-workshop/ ← WORKSPACE (no es un proyecto facturable) ├── orch.yaml ├── .orch/ ← solo estado de Orchemax ├── apps/ │ ├── api/ ← proyecto registrado │ ├── web/ │ └── worker/ ├── shared/ │ ├── go/ ← shared.go (+ orch:export) │ ├── css/ ← tip shared.css │ └── js/ ← tip shared.js ├── tools/ └── docs/ Orden: 1 workspace → 2 registrar proyectos → 3 shared por lenguaje (+ assets)
Orden ideal a enseñar: raíz del workspace → registrar proyectos → shared por lenguaje (y assets transversales cuando todas las apps los asumen).
Controles para quien paga la factura
Quien trabaja solo obtiene una fábrica local gobernada. Los CTO de equipo obtienen el mirador: quién puede correr qué, cuánto y cuándo — sin cuidar cada sesión a mano.
Controles de uso
Topes de proyectos, agentes concurrentes, dispositivos y corridas. Visibilidad de tokens/gasto por proyecto y modelo. Freno suave antes de que la factura sorprenda.
Horarios de trabajo
Define cuándo pueden correr los agentes: horario laboral, noches en silencio, ventanas de freeze antes de releases. La política viaja con la org, no en un sticky de Slack.
Allowlists de equipo
Un Chair por proyecto en el piso; Team+ define quién despacha y quién toca shared: para que “cualquiera con un CLI” no sea tu modelo de seguridad.
Mirador CTO
Score de gobernanza, horas ROI, pulso del fleet. HITL Telegram/WhatsApp en el plan Team (en shipping). Solo metadatos: nunca source. Renuevas la sub porque ves el piso.
FREE → STARTER → PROFESSIONAL → TEAM
Login obligatorio. Free está capado. Las cuotas miden agentes gestionados por orch (dispatch + gateway con virtual key) y proyectos registrados — no carpetas, ni agentes con login de seat que omiten el gateway. El gasto de LLM es BYO (tus proveedores); el precio de Orchemax es solo gobernanza.
Gateway vs login de seat
Ventaja: configurar URL + API key del gateway
- Crush/externalize reduce el prompt antes del proveedor → menos tokens facturados
- Aplican topes del plan: agentes concurrentes, proyectos, corridas/día
- La key de empresa queda en orch; los agentes reciben virtual keys
Desventaja: solo login Claude/Cursor (sin gateway)
- Sin compresión de orch → pagas el prompt completo al vendor
- Esos agentes quedan fuera de
orch.agents.concurrent; el plan no los limita - Sin ledger local content-free de ese tráfico
Un comando: orch gateway enable, luego orch gateway + dispatch, o orch gateway connect claude para el IDE.
Free
$0/mes · capado
- 1 proyecto · 1 agente orch concurrente · ~10 corridas/día
- Fábrica local · BYO gateway después
- Sin mirador
Starter
$15/mes
- Hasta 5 proyectos · 2 agentes orch concurrentes
- Fábrica local · proveedores BYO vía gateway
- Política solo
Professional
$35/mes
- Más proyectos · mirador personal
- Webhooks · más corridas
- 1–2 dispositivos · ahorro crush en gateway
Team
$59/usuario/mes
- Mirador CTO · allowlist · seats
- Topes de uso · horarios · agentes medidos
- HITL Telegram (en shipping) · Slack/GitHub listos
Lo que renueva la suscripción
Los CTO ven control y ROI: nunca el source. Uso, horarios, gobernanza y el piso en vivo.
Ilustración del mirador — cifras de ejemplo, no datos vivos del tenant. Viñeta Telegram = plan Team (en shipping).
Score de gobernanza
14 bloqueados
Intentos duplicados detenidos; reuso forzado de módulos shared.
Uso · topes
80% cap
Corridas, agentes, tokens por proyecto. Alertas antes del sobrecosto.
Ventana laboral
09–18
Agentes corren con horario. Freeze antes del release; noches en silencio por política.
Feed · fleet
5 online
Workstations + pulso de agentes. Pass / HITL / promovido a shared.
Telegram (Team · en shipping): “El agente quiere cambiar validators shared. Apruebas?” —
el Tech Lead aprueba desde el café; el agente sigue bajo la política de la org.
Gobernanza para el piso multi-agente
Fábrica local para sesiones en paralelo. Mirador Team para CTOs: uso, horarios, allowlists, HITL. Si hoy corre más de un agente, esto es para ti. El gasto de LLM queda con tus proveedores.