“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í.
Orchemax
El producto, completo
La portada es la versión corta. Esto es el flujo del día a día, todo lo que viene bajo el asiento, en qué se diferencia un workspace de un proyecto, los controles para quien paga la cuenta y las respuestas largas.
Tres escenas más
La portada lista tres. Estas son las otras tres del mismo repo.
“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ó.
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 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.
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 orch, 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.
Qué viene bajo el asiento
Esto existe en otras partes. Lo que sigue es en qué se diferencia aquí. Orchemax está escrito en Go para un binario local pequeño; tus talleres siguen siendo polyglot con ~30 plantillas de lenguaje (TS, Python, Delphi, Rust, C#, …).
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.
Gates de plan activo y disciplina DDL
Free → Starter → Professional → Team → Enterprise. 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.
Gateway vs login de asiento
Ruta gateway: tus API keys en el vault local
- Crush y externalize encogen los prompts antes del proveedor, y la rotación sale de una llave en cooldown
- Aplican los topes del plan: agentes concurrentes, proyectos, runs/día
- La llave del proveedor de la empresa se queda en orch; los agentes reciben llaves virtuales
Ruta login de asiento: Claude / Cursor en su propio plan
- Nada pasa por un proxy y el login queda intacto — orch no sustituye una credencial de cuenta
- El hook local
PostToolUseigual comprime la salida de herramientas, yorch usageigual cuenta esos tokens desde la transcripción - Esos agentes quedan fuera de
orch.agents.concurrent; los conteos de agentes del plan no los limitan
Un comando: orch gateway enable, después orch gateway keys add <proveedor> y orch gateway status.
Workspace ≠ proyecto
Solo ilustración: no es una plantilla forzada. Tú declaras las rutas; Orchemax enlaza
.orch/ + orch.yaml y mide proyectos registrados, no escaneos de carpetas.
El ask cross-proyecto y search_shared_symbols {project} funcionan dentro de un workspace como este.
acme-workshop/ ← WORKSPACE (no es un proyecto facturable) ├── orch.yaml ├── .orch/ ← solo estado de Orchemax ├── apps/ │ ├── api/ ← proyecto registrado (su propio Chair) │ ├── web/ ← proyecto registrado (su propio Chair) │ └── worker/ ├── shared/ │ ├── go/ ← shared.go (+ orch:export) │ ├── css/ ← tip de shared.css │ └── js/ ← tip de shared.js ├── tools/ └── docs/ Orden: 1 workspace → 2 registrar proyectos → 3 shared por lenguaje (+ assets) El agente de api puede preguntarle al Chair de web; la respuesta trae proyecto + ruta + línea.
Orden ideal para enseñar: raíz del workspace → registrar proyectos → shared por lenguaje (y assets transversales cuando toda app los asume). Un Chair por proyecto, varios proyectos por workspace, un solo bus para todos.
Controles para quien paga la cuenta
Los builders solos reciben una fábrica local gobernada. Los CTO de equipo reciben el mirador: quién puede correr qué, cuánto y cuándo — sin cuidar cada sesión.
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. Team Assist (aprobar/negar) live en /app; canal de bot de Telegram en camino. Solo metadatos, nunca el código. Renuevas la suscripción porque puedes ver el piso.
Integraciones de Team
Incluido con Team
- Assist HITL (API live) · bot de Telegram en camino
- Webhooks · rollup del mirador de organización
Add-ons (opcionales)
- Puente de workflows n8n
- Puente Zapier
- Actívalos en /app/integrations cuando estés listo
Lo que le muestras a liderazgo
Los CTO responden “¿a dónde se fue la plata de la IA?” con hechos content-free — nunca con el código. Tokens, quién los gastó, ahorro del gateway y prueba de política.
Cifras de ejemplo, no datos de un tenant real. Las horas ROI de abajo son una estimación a partir de conteos de intentos hasta que llegue work-pulse; la compresión y la mezcla de tokens sí son pushes reales del gateway. Tus propios números salen de orch usage, no de esta tarjeta.
Horas ROI (estimación)
12.5h
Intentos × 0.25h — un argumento de renovación, no una cifra de facturación.
Compresión
ejemplo
Bytes que no salieron al cable frente a los enviados, netos del overhead de crush. Lee los tuyos en orch usage.
Eventos de gobernanza
14
Promotes, negaciones, locks, claims — prueba de que el piso está gobernado.
Feed en vivo · flota
5 en línea
Estaciones de trabajo + pulso de agentes. Pass / HITL / promovido a shared.
Team Assist: “Un agente quiere cambiar los validadores compartidos. ¿Apruebas?” — consola hoy; canal de bot de Telegram en camino.
El Tech Lead toca Aprobar desde el café; el agente sigue bajo la política de la organización.
Lo que ofrecemos en vez de un muro de logos
Sin citas de clientes, sin logos, sin contador. Tres cosas que puedes revisar tú mismo:
- El benchmark corre en CI, no en una lámina.
tests/benchmark/antidupes un test de Go; el workflow.github/workflows/antidup-benchmark.ymlsube su JSON como el artefactoantidup-bench-jsonen cada corrida — duplicados que pasaron, duplicados bloqueados, merges rotos, conflictos detectados. - La tarjeta del mirador en esta página es una muestra etiquetada. Cada cifra bajo Lo que le muestras a liderazgo está marcada como muestra o estimación. Tus números reales salen de
orch usagesobre tu repo, en el tier gratuito, desde el primer día. - La promesa de privacidad tiene un test de regresión. El payload del mirador es content-free por esquema y
TestMarkdownContentFreefalla si alguna vez aparece texto de código adentro.
Antes de instalarlo
Las cuatro cosas que preguntan al entrar, respondidas sin la versión de ventas.
¿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.