El producto, completo

“Dos agentes tomaron el mismo ítem del ledger.”

Los dos terminaron. Los dos se pagaron. Un diff hubo que tirarlo, y ninguno de los dos supo nunca que el otro estaba ahí.

“El proyecto A rehízo lo que el B ya tenía.”

Mismo workspace, misma semana, el mismo helper de reintentos. No había forma de preguntarle al agente del otro proyecto si ya lo había resuelto.

“Todo dashboard cita un ahorro que no puedo reproducir.”

Un porcentaje en una lámina no es una medición. Quieres el número de tu repo, y quieres ver cómo se contó.

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 queda bloqueado.

3. Chair vs workers

Por qué un solo Chair: si cada agente actúa como director, corren contra los mismos archivos, inventan helpers duplicados y el trabajo se anuda. Los workers son para tareas secundarias, dirigidos por ese Chair — no una segunda orquesta sobre el mismo proyecto. El orden de llegada elige al Chair; no lo nombras en el chat. ¿Necesitas más manos? Abre workers; no abras otro Chair. Las escrituras de código del propio Chair también tienen un límite: la 3ra recibe un aviso que nombra dispatch_worker, la 4ta se deniega. Cualquier guard que bloquea hace fallar la tarea despachada y hace que worktree_promote la rechace. En una corrida medida, el hook PostToolUse de Claude Code movió 23,634 bytes de salida de herramientas al disco en vez del transcript. Una corrida, no un porcentaje. Despachar dos workers desde un mismo Chair en el mismo turno los corre en paralelo: 312 ms de tiempo de MCP en una corrida medida, contra 151,125 ms cuando los mismos dos despachos corrieron uno después del otro.

4. Código compartido

Antes de editar rutas comunes, toma un lock. Busca en el registro antes de escribir el helper. Edita y libera para que el equipo vea el refresh. No edites shared sin lock.

5. Reclama el ítem, habla por el bus

Reclama tu línea del ledger para que nadie más la tome. Deja notas cortas y handoffs para los otros asientos (inbox / avisos). Usa la mensajería de Orchemax, no un chat paralelo del vendor entre agentes.

6. Nube opcional

Enlaza una cuenta Orchemax cuando quieras topes, visibilidad de gasto y el mirador del CTO. El código se queda local; la nube ve metadatos, no tu repo.

Pruebas: la prueba es proporcional

Escribir código nunca espera a una suite de pruebas, y cerrar una sesión nunca corre una. Un cambio corre solo las pruebas que alcanza, y se reutiliza un resultado aprobado sobre código idéntico. Cuando hace falta una verificación completa, se te dice su tiempo medido y tú eliges cuándo corre. Un cambio que se saltó la verificación se etiqueta como no verificado, nunca como aprobado.

orch try <sesión|rama> integra las ramas aceptadas en un directorio de tren aparte, las compila y las instala con una copia para revertir, no corre ninguna suite, no mueve ninguna rama y no hace push. Después orch status muestra la instalación como orch try, unverified hasta que orch land --install la reemplace, y orch try --rollback restaura la anterior. En corridas medidas tardó de 23 a 52 segundos, frente a 20 a 40 minutos de un land completo.

orch land verifica paquetes completos, divide por ramas un tren que falla, vuelve a correr solo las pruebas fallidas, integra el resto y puede hacer push e instalar. Planeado: un land que corra solo las pruebas que el cambio alcanza.

Noches en las que puedes confiar: orch nightly run integra en un solo tren todas las sesiones aceptadas que aún no se integraron, dentro de una ventana que eliges (verify.nightly.start y verify.nightly.end). Ensaya el land primero en una copia desechable e integra solo lo que pasó; el informe de la mañana, con lo que se integró y lo que se rechazó y por qué, te espera en tu próximo informe de inicio hasta que orch nightly status lo lea.

Revisiones más rápidas y honestas: el sello corre una revisión solo cuando el cambio la alcanza, y las auditorías, los sellos, los ensayos y el doctor comparten una misma caché de compilación del taller. Un resultado de pruebas que declara un worker lo vuelve a correr el sello y lo juzga, nunca se acepta por su palabra; esa repetición solo admite flags, entorno y paquetes permitidos.

Cualquier lenguaje: orch test y orch repro corren el adaptador de pruebas del lenguaje del proyecto y nombran el adaptador que falta en vez de adivinar.

Sesiones: un inicio que te informa, un cierre liviano

El Chair abre con un primer mensaje propio, en tu workspace.locale (en o es-US), y un informe de inicio: la tarjeta de la última sesión, las memorias fijadas, las lecciones que reincidieron en los últimos 7 días, las filas de aprendizaje abiertas, el estado del trabajo (en curso, aceptado y esperando land, esperando auditoría) y las decisiones que esperan por ti.

Mientras un asiento arranca o cierra, una sola línea animada muestra el paso actual y el tiempo transcurrido; queda en silencio fuera de una terminal y con NO_COLOR, ORCH_NO_SPIN y ORCH_QUIET. Cerrar un Chair no corre pruebas de sello de workers, vista previa de integración ni compuerta del repo; solo juzga sus propios commits. Un worker que está sellando nunca se muestra como detenido.

Planeado: el traspaso y la tarjeta escritos en cada cambio de estado, para que un cierre vuelva en menos de un segundo y el siguiente inicio lea un informe ya armado.

El bus: tus máquinas trabajan como una

Una nota escrita en una silla de una máquina llega a una silla de otra, y quien la envía ve el acuse cuando aterriza. Cada máquina reporta si está en línea y qué está corriendo; orch machines imprime esa tabla. Una silla inactiva se despierta cuando llega trabajo para ella, en vez de esperar tu próximo mensaje.

Una sola máquina tiene el rol de coordinador, así dos máquinas nunca reparten el mismo trabajo. Si se queda callada, la siguiente toma el rol sola y el relevo queda registrado; una máquina relevada que vuelve recibe el aviso de quién lo tiene ahora.

El gateway: tres formas de pagar los modelos

Tu propia cuenta del proveedor. Una silla interactiva conserva el login que ya pagas, y nada se enruta por Orchemax.

Tus propias llaves. El gateway usa las llaves de tu configuración y nada más.

El gateway de Orchemax. El tráfico de modelos pasa por Orchemax en vez de por una llave tuya.

La vía se fija por silla (agents.auth, --auth), así una silla y sus workers pueden usar vías distintas. Un proveedor que falla o limita la tasa entra en enfriamiento y el trabajo sigue en el siguiente. orch gateway status muestra el estado vivo, los enfriamientos y las rotaciones; lo que costó y ahorró una corrida está en orch stats, medido sobre tu propio tráfico en vez de impreso aquí.

Notificaciones: solo cuando tienes que actuar

Una notificación de escritorio aparece solo cuando algo te necesita. Los resultados de los workers (sellado, fallido, terminado, detenido, necesita respuesta, traspaso) nunca notifican mientras haya un Chair abierto, y el aviso de inactividad del Chair no notifica mientras corre su propio land, auditoría o sello. Cada línea del registro de notificaciones termina en delivered=toast o delivered=none reason=<motivo>, así que puedes leer por qué no te llegó nada. Algunos llamadores y un tiempo límite para las notificaciones aún se están pasando a la misma regla.

Disposición del taller: se quita borrando una carpeta

Los datos de Orchemax viven bajo el .orch/ del taller y el .sandbox/<asiento>/ de cada proyecto, y los archivos temporales de un asiento van dentro de esa carpeta de trabajo. Esa carpeta se limpia pasados guard.sandbox_days (14 por defecto) y nunca guarda conocimiento duradero: ese vive en la memoria de Orchemax y en archivos que versionas. Mover la raíz de trabajo por defecto dentro del taller sigue en curso.

Aprendizaje: las lecciones llegan donde está la acción

Una lección se muestra en el momento en que aplica: despacho, brief, auditoría, land o edición. Una lección que se rompe después de mostrarse se convierte en gate, y mientras no lo tenga solo se despacha trabajo base (la regla de needs-gate). Cada anulación se registra y se cuenta, y las reincidencias se cuentan por lección. Se planean más gates. El aprendizaje se mide: una lección nueva empieza en período de prueba y los sellos verdes aceptados la asientan; una que no se inyecta en 60 días (learn.expire_days) queda dormida. Un proponente barato opcional (learn.propose: off, shadow u on) redacta lecciones tras un sello fallido y un promotor determinista las valida, y orch learn curate fusiona casi duplicadas (simulacro hasta usar --apply).

Estadísticas: lo que pasó, en números que puedes leer

orch stats agrupa por guard y veredicto, por superficie y por regla, así ves qué guard se dispara de verdad y cuál nunca. Los failovers y enfriamientos del gateway se cuentan por proveedor, y los contadores de aprendizaje muestran qué se propuso, se promovió y expiró, y cuánto costó.

Cada cifra de esta página que no puedas leer en ese medidor se quitó en vez de redondearse: un número de una corrida en una máquina no es una medición que puedas exigirnos.

Worktrees y locks

Un worktree por sesión de agente es el default de la industria, y solo aísla. Orchemax suma el lock lógico que se toma antes de la edición compartida y el registro de símbolos que se consulta antes de escribir el helper — y después orch worktree promote hace merge con falla cerrada ante conflicto y nunca hace push solo. Prevención y aislamiento, no uno en vez del otro.

Un reaper que termina el trabajo

Los watchdogs que notan a un agente colgado son comunes. Este tick además falla la tarea, libera el lock, elimina el worktree, barre el contexto externalizado vencido y borra aristas del grafo cuyo símbolo destino ya no existe — en una sola pasada, sin base de datos extra ni multiplexor de terminal. La verificación de vida mira el PID hijo del propio agente con una ventana de gracia; el intervalo es tuyo, sin definir son 60s y 0 lo apaga.

Gateway: tus llaves, una conexión

Varias llaves por proveedor en un vault local como anillo rotativo, cada una probada contra el proveedor antes de guardarse y nunca impresa de vuelta. orch gateway status muestra estado live/cooldown, posición en el anillo y conteos de rotación, content-free. Claude Code conserva su plan: el gateway rechaza a propósito un bearer de cuenta y te dice por qué.

Compresión que reporta neto

El compresor es genérico sobre cualquier salida de herramienta, cae a texto crudo cuando el parseo falla, y reporta bytes ahorrados después de su propio overhead. Errores, stack traces y salidas distintas de cero se conservan textuales — una compresión que esconde un panic es un bug, no un ahorro.

Workers heterogéneos sobre un protocolo

Orchemax habla ACP (JSON-RPC sobre stdio) como cliente. Pon agents.transport en acp y un worker de Gemini CLI u OpenCode reporta tool calls y resultados estructurados en vez de stdout raspado; el transporte por defecto sigue siendo un subproceso. Verificado para esos dos; Codex, Claude Code y Cursor corren como subprocesos. El pedido de permiso de un worker se enruta al Chair por ask, así lo puede aprobar un agente en vez de un humano frente al panel.

Tus propias reglas, más seis guards por defecto

Los chequeos deny, require y cmd que escribes en .orch/gates/user/manifest.json corren en los mismos puntos de sellado, hook de git y hook de IDE que los guards integrados. Orchemax también trae seis guards por defecto: docs, signature, upsert, env-drift, shared-shadow y template-drift.

Tu propiedad intelectual sigue privada

Un proyecto declarado público solo acepta las rutas que nombran sus globs de publish.allow; cualquier otra ruta se rechaza al hacer commit, push y sellar, y una regla que no se puede leer falla cerrada. orch doctor avisa de un origen público que no declara visibilidad.

Consentimiento antes de tocar tu perfil

Los hooks de alcance proyecto (.claude/settings.json, .cursor/hooks.json) se instalan por defecto desde un orch setup limpio. Todo lo que fuera a escribir en tu perfil de usuario en cambio pregunta primero, nombra el archivo, guarda un backup con marca de tiempo, y trae un comando para deshacerlo (orch guard unwire).

Gates de plan activo y disciplina DDL

Free → Starter → Professional → Team. Los agentes llaman entitlements_status; las negaciones por cuota o plan traen pistas de upgrade, y los topes Free locales aplican cuando no hay cuenta enlazada. El promote puede exigir seeder y repository al lado de una migración para que los agentes no dejen esquemas huérfanos. ORCH_TASK_TOKEN_BUDGET topa el presupuesto de una tarea antes de que arranque; el enmascarado local de secretos mantiene credenciales fuera del registro de uso y de todo lo que se empuja como evento.

Controles de uso

Topes de proyectos, agentes concurrentes, dispositivos y runs. Visibilidad de tokens y gasto por proyecto y por modelo. Freno suave antes de que la factura te sorprenda.

Horarios de trabajo

Define cuándo pueden correr los agentes: horario laboral, noches tranquilas, ventanas de congelamiento antes de un release. La política viaja con la organización, no en una nota pegada en Slack.

Allowlists de equipo

Un Chair por proyecto en el piso; desde Team, allowlist de quién puede despachar y quién puede tocar shared, así “cualquiera con un CLI” no es tu modelo de seguridad.

Mirador del CTO

Eventos de gobernanza, horas ROI, pulso de flota en vivo. Professional: mirador + Telegram avisos suaves. Team: Assist HITL (aprobar/negar) en /app y Telegram. Solo metadatos, nunca el código. Renuevas la suscripción porque puedes ver el piso.

¿Es otra capa entre mi agente y yo?

No. Orchemax no pasa tu tráfico por un proxy ni reemplaza tu login. Registra herramientas MCP que tu agente puede llamar y un hook del harness. El CLI que abres es el que tenías.

¿Va a romper mi suscripción de Claude o Codex?

Antes sí — un bug inyectaba credenciales de API en un login por plan y mataba la suscripción. Está corregido, el gateway ahora se niega a sustituir una credencial de cuenta y explica por qué, y los asientos por plan se comprimen con el hook local en vez de enrutarse a ningún lado.

¿Mi código llega a su nube?

No. El runtime es local. Una cuenta enlazada recibe contadores, nombres de modelo, ids de sesión y eventos de gobernanza — content-free por esquema de payload, con un test de regresión que falla si alguna vez aparece texto de código. Los talleres sin enlazar siguen funcionando.

Ya usamos git worktrees. ¿Qué queda?

Los worktrees aíslan y difieren el choque al momento del merge. Lo que queda es el lock que se toma antes de la edición compartida, el registro que se consulta antes de escribir el helper, el claim sobre la línea del ledger, el reaper que limpia después de una caída, y un promote que se niega en vez de adivinar.