OtoDock lanza un panel autoalojado para orquestar agentes de Claude Code y Codex
El proyecto, publicado en GitHub con licencia fair source, organiza agentes en departamentos que delegan entre sí, con sandbox de kernel y aislamiento de red activados por defecto.
OtoDock es un panel autoalojado que convierte Claude Code y Codex en una plantilla de agentes repartida por departamentos. El proyecto acaba de aparecer en GitHub bajo licencia fair source y no incluye modelo propio: se apoya en las suscripciones de Anthropic y OpenAI de cada usuario, o en modelos locales sobre hardware propio. El motor se escoge por agente y se puede cambiar en mitad de una conversación.
Cada agente se define con seis piezas editables: persona, memoria, workspace, conocimiento, skills y herramientas. El workspace es lo que decide quién ve qué, y ahí entran los cuatro modos de compartición que propone el proyecto: solo personal, personal con zona compartida, compartido con zona privada, o un único historial y workspace para todo el equipo. Los permisos también se reparten por agente. El README se lía un poco en este punto: anuncia tres roles de plataforma y luego enumera seis por agente, de Admin a Viewer.
Ejecución y máquinas remotas
Los agentes corren por calendario, cuando dispara un webhook o una vez en el momento que se elija. Todo aterriza en el workspace y las notificaciones llegan con cuatro niveles de severidad, desde un aviso suave hasta una alarma persistente. Cada ejecución queda como un chat completo que se puede abrir y continuar, así que no hace falta que nadie esté mirando la pantalla.
El despliegue por defecto es en servidor, con todos los agentes bajo un único panel. Además se puede emparejar un portátil, una estación de trabajo o un PC con macOS, Linux o Windows mediante una instalación de una línea: la máquina mantiene una sola conexión saliente, no necesita puertos abiertos y sincroniza sus archivos. Si esa máquina se cae, el servidor retoma el trabajo. También se les puede dar teléfono: el agente contesta y realiza llamadas usando una cuenta de Twilio o un servidor Asterisk o FreePBX ya existente.
Sandbox y credenciales
La parte que más interesa a quien vaya a desplegarlo es cómo está encerrado. OtoDock asume que un agente no es de fiar y mete cada sesión del lado servidor en un sandbox de kernel con su propio namespace de montaje y de procesos. El aislamiento de red bloquea por diseño los rangos privados, la LAN y los endpoints de metadatos de nube; las herramientas MCP que necesiten un servicio local se autorizan una a una. Las credenciales se cifran en reposo y se inyectan solo por sesión, de forma que el agente puede usarlas pero nunca verlas. SSO, doble factor y presupuestos de coste por usuario vienen desde la primera instalación.
El detalle técnico está en el modelo de seguridad y en la documentación de instalación, donde se aclara qué hace falta para levantarlo.
El interés del proyecto está en la propuesta de operación, no en los números: no hay benchmarks públicos, ni comparativa de coste, ni demo más allá de un vídeo de dos minutos que, según el propio README, fue dirigido, grabado y editado por un agente de OtoDock. La afirmación es suya. Queda por ver si el modelo de compartición por roles aguanta un equipo real y cuánto consume mantener varios agentes activos contra las suscripciones de cada usuario.

