Arc OS

El Orchestration System para equipos de IA

Tu empresa no necesita más chatbots. Necesita un departamento que nunca duerme.

Qué es Arc OS

Arc OS es una plataforma de gestión de equipos de IA que despliega equipos de agentes autónomos dentro de una oficina visual en tiempo real. Cada agente tiene un rol definido, un supervisor y estándares de calidad aplicables. El CEO marca la dirección. Los agentes se encargan del resto.

En una frase: Arc OS convierte los modelos de IA en empleados responsables que revisan el trabajo de los demás antes de informarte.

v2: Arquitectura Native-First

Arc OS es una reconstrucción desde cero sobre las herramientas nativas de Claude Code:

67% menos código. Cero backend personalizado. Las mismas capacidades.

Funciones principales

1. Cadena de suministro de IA

Los agentes operan como una cadena de suministro coordinada — no como chatbots aislados:

El CEO establece un objetivo
    → Rick descompone, delega, asigna restricciones
        → Morty ejecuta (código, análisis, infraestructura)
            → Summer revisa (seguridad, calidad, auditoría OWASP)
                → Jerry documenta (decisiones, razonamiento, rastro de auditoría)
    → Rick sintetiza todos los resultados
    → El CEO solo ve la salida final validada

2. Agent Teams (Nativo)

Construido sobre Claude Code Agent Teams:

• TeamCreate — desplegar un equipo coordinado
• TaskCreate/TaskUpdate — gestión estructurada de tareas
• SendMessage — comunicación entre agentes
• No se necesita capa de mensajería personalizada

3. Oficina visual

Oficina de píxeles en Phaser.js en tiempo real donde los agentes existen como entidades persistentes:

• Los agentes se sientan en sus escritorios, caminan hacia los demás al delegar
• Los globos de diálogo muestran la actividad actual
• Los colores de estado reflejan la carga de trabajo
• El tablero de tareas es visible en la pared
• La oficina ES el estado del sistema — un vistazo lo muestra todo

4. Centro de mando móvil (Telegram)

Integración oficial de Telegram Channel:

• Comandos en lenguaje natural: /status, /tasks, delegación
• Los archivos subidos se clasifican automáticamente y se enrutan a los agentes
• Actualizaciones de progreso mediante ediciones de mensajes
• Reacciones para feedback rápido

5. Privacidad y cifrado Zero-Knowledge

Tus datos están cifrados en reposo — las claves API, los mensajes de chat y la configuración sensible están protegidos por cifrado AES-256-GCM. Las recovery keys (formato 1Password) garantizan que nunca pierdas el acceso. Las cabeceras de seguridad (CSP, X-Frame-Options) y la sanitización de PII en los logs añaden defensa en profundidad.

6. Skills bajo demanda

Experiencia portable cargada dinámicamente:

• handoff-protocol, code-review, system-audit, git-manager, project-onboarding
• Las skills se asocian con disparadores de comandos
• Se cargan bajo demanda, no permanentemente en el contexto
• Hasta 70% de reducción en el consumo de tokens en reposo

6. Memoria infinita (NotebookLM Bridge)

Búsqueda semántica real impulsada por Google NotebookLM — no búsqueda por palabras clave:

• NotebookLM Bridge — servicio Python FastAPI (:19213) que envuelve notebooklm-py
• Sincronización automática — el cierre/apertura de issues y las actualizaciones de wiki se sincronizan automáticamente con Google
• Cloud PM chat — la herramienta ask_notebooklm consulta el conocimiento del proyecto semánticamente
• Fallback — búsqueda local por palabras clave cuando el bridge no está disponible
• Notebooks por proyecto — cada proyecto tiene su propio notebook de Google NotebookLM
• El Bridge ES la memoria persistente — Google gestiona el RAG de forma gratuita, 100% de precisión

7. Lifecycle Hooks

Los hooks de Claude Code sincronizan automáticamente el estado de los agentes sin intervención manual:

• SubagentStop → agente marcado como inactivo en office-state.json → SSE → Phaser UI actualiza
• Stop → se genera el wrapup de sesión, todos los agentes se resetean a inactivo
• Los hooks SON el pegamento — sin polling, sin cron, solo sincronización de estado basada en eventos

8. Blueprints de departamento

5 configuraciones predefinidas:

• Web: Rick lidera, Morty codifica, Summer revisa
• GameDev: Summer lidera el diseño, Rick gestiona el motor
• Debug: Rick hace triage, Morty depura, Summer valida
• Legal: Beth lidera el análisis, Summer revisa
• Service: Rick lidera operaciones, Morty ejecuta

Para quién es esto

• Desarrolladores en solitario que necesitan salida de IA fiable sin supervisar cada respuesta
• Fundadores técnicos que quieren una capa de operaciones de IA que escale
• Agencias que necesitan workspaces de IA aislados y de marca por cliente
• Cualquiera cansado de copiar prompts entre pestañas y revisar manualmente el código de IA

9. Arquitectura de bots federados (Phase 20)

Gestión multiproyecto mediante la federación Master + Child bot:

• Master Bot — orquestador Telegram ligero (no IA): /status, /health, /deploy, /new_project, /remove_project, /watchdog
• Child Bots — proxies Telegram ↔ Claude CLI por proyecto con contexto aislado
• Onboarding — entrevista interactiva → aprovisionamiento automático con matching de skills
• Auto-recuperación — watchdog reinicia automáticamente los children caídos con backoff exponencial
• Vault cifrado — almacenamiento AES-256-GCM para tokens de bots (no en .env)
• Logging estructurado — formato JSONL, rotación diaria, compatible con grep/jq

10. CRM Dashboard y observabilidad (Phase 22)

Gestión de proyectos en tiempo real mediante servidor HTTP Bun:

• REST API — 18 endpoints CRM: proyectos, logs, archivos, skills, métricas, specs, roles, mensajes, learnings, heartbeat
• SSE Streams — seguimiento de logs JSONL en vivo + salida de consultant
• Terminal WebSocket — tmux capture-pane con colores ANSI + modo interactivo
• Gráficos de Sparkline — gráficos de barras canvas para series temporales éxito/fallo
• Flujo de autenticación — email/contraseña u OAuth (Google, GitHub) → token JWT (TTL 24h)

11. Flujo Dual-Agent (Phase 24.5)

Colaboración de dos roles por proyecto:

• Consultant (Sonnet, solo lectura) — análisis, specs, propuestas de arquitectura mediante /c
• Developer (Opus, acceso completo) — implementación, despliegue mediante /d
• Cola de specs — auto-extraída del patrón ### SPEC:, el CEO aprueba/rechaza
• Tema Slate & Silver — glassmorfismo oscuro en toda la UI

12. Local Gateway Bridge (Phase 25)

Conecta el IDE local a la inteligencia de Arc OS:

• Bridge CLI (citadel-bridge) — connect, pull, push, status, disconnect
• Skills Sync — extrae el bundle de skills + evals del CRM al proyecto local
• Learnings Sync — bidireccional: extrae correcciones, sube descubrimientos locales
• CLAUDE.md Injection — contexto automático de Arc OS mediante marcadores <!-- CITADEL:START/END -->
• Heartbeat — informa de la actividad de la sesión local al CRM dashboard

13. Knowledge Dashboard (Phase 32)

Gestión completa del conocimiento del proyecto:

• Reports Feed — vista de línea de tiempo, agrupada por fecha, etiquetas de fuente codificadas por color
• Skills CRUD — editor de panel dividido para definiciones de skills
• Wiki Editor — edición, guardado y creación de páginas markdown en línea
• NotebookLM — landing de marca con tarjetas de casos de uso

14. Creación de proyecto multitenancy (Phase 33)

Creación de workspace self-service para usuarios que regresan:

• Account Settings — claves API por usuario almacenadas de forma segura (0o600)
• Create Project Modal — 3 campos (nombre, nicho, preset), sin asistente completo
• Directorios con espacio de nombres de usuario — /opt/repos/{chatId}_{projectName}/
• 10 helpers reutilizables — allocatePort, createProjectDirectories, generateClaudeMd, etc.

15. Project Manager autónomo (Phase 34)

8 herramientas MCP para la gestión de proyectos sin intervención:

• Issue CRUD — create_issue, list_issues, update_issue (P0-P3, etiquetas)
• Wiki Sync — update_wiki crea/actualiza páginas markdown
• Motor de roadmap — sync_roadmap con reemplazo de estado in situ
• Init Injection — issues abiertos + próximo objetivo del roadmap auto-inyectados en CLAUDE.md

16. Terminal Sync en vivo (Phase 35)

Transmite la salida de Claude Code local al dashboard web en tiempo real:

• Backend — POST /terminal/log recibe líneas JSONL, las añade a los archivos de log
• ARC CLI — Bun.spawn con pipe stdout, POST con buffer de 2s, strip de ANSI
• Frontend — selector de pestañas Bot/Live con punto verde pulsante para streams en vivo

17. Cloud Project Manager (Phase 36)

Análisis de proyectos con IA mediante el dashboard web:

• SSE Chat — POST /api/crm/projects/:name/chat hace proxy a la API de Anthropic Messages
• Bucle de herramientas del lado del servidor — ask_notebooklm consulta wiki, issues, roadmap semánticamente
• NotebookLM Bridge — Python FastAPI con búsqueda semántica de Google + sincronización automática

18. Sage Worker + Skill Evolution (Phase 40.11)

Curación de skills basada en datos con benchmarking A/B opcional:

• Sage (modelo Haiku) — analiza borradores de skills vs el registro, identifica solapamientos y lagunas
• Solicitudes de actualización (PRs) — los humanos revisan, aprueban/rechazan, se registra automáticamente la evolución
• Benchmarks A/B — ejecuta evaluaciones cara a cara sobre prompts reales antes de promover una skill
• Marketplace Discovery (Phase 40.12) — escanea claudemarketplaces.com, analiza compatibilidad mediante LLM, instalación con un clic (global o por proyecto)

19. Knowledge Graph + enlace Obsidian (Phase 40.17)

• /api/crm/projects/:name/knowledge-graph — nodos + aristas desde los enlaces wiki
• Grafo canvas force-directed en el frontend (sin lib de terceros)
• Botón Open in Obsidian en cada tarjeta de Neural Memory — salta directamente al vault

20. UI Refresh — Adaptación del rediseño Vercel (Phase 41)

Migración por etapas de un diseño de referencia Next.js generado por Vercel al stack existente React+Lingui+Vite. 8 subfases, sin cambio de framework:

• Tokens de diseño — espacio de color OKLCH (primary deep-teal, accent warm-amber, surface warm-ivory), Inter + JetBrains Mono
• Pills del Worker Selector — pills horizontales con avatares de anillo de tono (coloreados por hash determinista del worker id)
• Burbujas de mensajes de chat — usuario invertido (fondo oscuro), prefijo de avatar del worker, esquinas redondeadas asimétricas, barra de acciones por mensaje (Guardar en nota, Copiar, 👍, 👎)
• Composer — selector de modelo inline (Sonnet ↔ Opus), chip de herramientas con badge de recuento activo, chip de inserción rápida /btw, dock de acciones debajo (/btw, Pause, Stop, Approve Last)
• Sidebar — badge de recuento de issues en la navegación, feed de actividad en vivo (top 3 eventos de issues, poll 30s), ping-pulse animado en Neural Memory sincronizado
• TopBar — botón de búsqueda con pista kbd ⌘/Ctrl K aware de plataforma (listener global lo enfoca)
• Context Rail (nuevo) — panel derecho de 320px, visible ≥1280px: Current Goal extraído de ROADMAP.md + métricas 2×2 (Issues abiertos, Cerrados/sem, Bloqueados, Skills) + lista de Skills activas + Fijados del hilo + pie de rama git
• Pinned Notes (función backend) — migración 009 + POST/GET/DELETE /api/crm/projects/:name/pins. "Guardar en nota" en el chat ahora fija el mensaje en el Context Rail en lugar de escribir en la wiki.

21. Hardening de seguridad (Phase 42)

Iniciado por la auditoría del agente Sentinel el 2026-04-23. 13 parches de seguridad en 4 pasadas de auditoría independientes. Veredicto: 🟢 VERDE, listo para múltiples usuarios.

• Guardián de multitenancy — canAccessProject(registry, chatId, project) en cada ruta protegida (SSE, terminal WebSocket, bloque CLI/MCP). El terminal WS interactivo requiere CEO o role=admin.
• Perímetro — Bun se enlaza solo a 127.0.0.1:19210; /api/internal/* rechaza cabeceras de proxy (X-Forwarded-For/X-Real-IP/Forwarded) como canario de nginx malconfigurado.
• Lista blanca SSRF — handleScoutAnalyze restringe el fetch saliente a https + host claudemarketplaces.com, redirect:"manual" bloquea el bypass por cadena de redirección.
• Rutas de token — extractChatId lee tanto la cabecera Bearer como el parámetro de consulta ?token= (coincidencia con EventSource del navegador con crmAuthMiddleware).
• Hardening — timingSafeEqual en la firma JWT, auditoría safePath en todos los handlers (corregido traversal en handleSaveSkill), lista de denegación de nginx extendida a config/+data/+knowledge-base/.
• Cobertura de regresión — scripts/vps-sync.sh ejecuta 7+ smoke tests post-deploy (bind loopback, traversal de rutas, bloqueo SSRF, canario de proxy, SSE ?token=, validación fail-closed, entrada chat/save).

Referencia completa: docs/SECURITY.md, informe de auditoría: docs/security/audit-2026-04-23.md.

22. Zero-Knowledge E2EE (Phase 45)

Cifrado en el lado del cliente para datos sensibles del workspace. Incluso los operadores de Arc OS no pueden leer el contenido cifrado.

• Derivación de clave maestra — WebCrypto PBKDF2 (100k iteraciones) → clave AES-256-GCM en caché en sessionStorage
• Recovery keys — formato estilo 1Password XXXX-XXXX-XXXX-XXXX-XXXX, backup de clave maestra cifrada
• Cifrado en reposo — vault AES-256-GCM para claves API, columnas cifradas en SQLite para mensajes de chat
• Defensa en profundidad CSP — default-src 'self', X-Frame-Options: DENY, X-Content-Type-Options: nosniff
• Sanitizador PII — redacta emails, claves API, JWTs y números de tarjeta de los logs JSONL antes de escribir en disco

23. Timeline e Issues Redesign (Phase 47)

Observabilidad inspirada en DAW y rastreo de issues agrupado por fases.

• Timeline — carriles de workers, chips de eventos, controles mute/solo, playhead con scrubbing. Reproduce la sesión de un worker como una consola de mezcla de audio.
• IssuesRedesign (Phase 47.8) — tabla agrupada por fases + panel de detalle deslizante, animación de pulso P0, barras de progreso, responsive móvil.

24. Descomposición de la arquitectura (Phase 48)

Refactorización de monolitos en módulos de dominio sin cambiar el comportamiento.

• CRM router — crm-routes.ts (10.779 LOC) → shared/routes/router.ts (373 LOC) que despacha a 19 módulos de dominio
• Workspace UI — Workspace.jsx (~2.000 LOC) → orquestador de 168 líneas + 9 componentes en pages/workspace/
• API server — master-bot/api-server.ts (196 líneas) delega a master-bot/routes/{auth,internal,cli,websocket}.ts
• Phase 48.5 — CRM inbox basado en eventos mediante fs.watch (latencia 100× menor que el polling de 500ms)
• Phase 48.6 — ciclo de vida lazy de workers: idle-kill + wake-up bajo demanda, ~298 MB RAM liberados (39%), capacidad 2 → 6-10 usuarios concurrentes

25. Enforcement de documentación (Phase 49.1)

Pre-push git hook (.githooks/pre-push → scripts/check-docs-coverage.ts) bloquea los pushes que cambian código sin actualizar los docs mapeados.

26. Trial Credits + Stripe Billing (Phases 50-51)

Monetización self-service sobre una base de coste cero.

• Trial credits (Phase 50) — uso único por email, da acceso a nuevo proyecto + Anthropic API para planes de pago
• subscriptions + stripe_events (migración 020) — ID de cliente Stripe, tier de plan, log de idempotencia
• PLAN_LIMITS — única fuente de verdad para el mapeo plan → proyectos/workers/funciones
• checkPlanLimit(userId, action) — middleware con semántica OR devuelve {allowed, reason, current, limit, plan}
• Tiers de precios — Free (1 proyecto / 5 workers), Min ($4.99 — 5 O 25), Max ($11.99 — 20 O 150)
• 402 Payment Required — error estructurado en handleOnboardingSetup + handleCreateWorker al superar el límite

27. F&F Beta Launch (Phase 52.1)

Puerta de beta cerrada antes del lanzamiento público — registro solo por invitación, bucle de feedback dedicado.

• Códigos de invitación — formato arc-XXXX-XXXX (hex de crypto.randomBytes), tabla invites (migración 021)
• Puerta de registro — /api/auth/register requiere invite_code, devuelve 403 invite_required si no
• endpoints de admin — POST/GET/DELETE /api/crm/admin/invites + ARC CLI arc invites generate/list/revoke
• Tier de plan beta — sin límites (proyectos/workers Infinity, todas las funciones Max) sin otorgar rol admin
• Canal de feedback — @arcos_beta_feedback Telegram, resumen semanal, 50% de descuento de por vida + Founders Wall

28. Enforcement de disciplina de issues (#115 / #116 / #117, mayo 2026)

"Cada tarea = issue registrado + rastro de actividad auditable" es la piedra angular de la promesa de Arc OS. Los workers conocían la regla del CLAUDE.md pero nada en el runtime la aplicaba — los proyectos acumulaban rutinariamente días de sesiones CLI completadas con cero issues registrados. Este trío de tres issues cierra el bucle de extremo a extremo.

#115 — enlace en runtime (CLI + Web + Telegram, las tres superficies):

• Selector al inicio de sesión en arc <project> — lista interactiva de issues abiertos (ordenados P0→P3 + más recientes primero, filtro difuso cuando >10), recientemente cerrados (con confirmación de reapertura), [n] crear nuevo, [q] saltar con doble confirmación. El id seleccionado persiste en ~/.arc/sessions/<project>-<worker>.json y se inyecta como variable de entorno ARC_ACTIVE_ISSUE_ID en el subprocess de Claude + como bloque Active issue: #N — Title en CLAUDE.md para que los workers auto-registren durante la sesión.
• Modal del Web Workspace que refleja el flujo del CLI; pill de issue activo clicable en la barra de workers permite al usuario volver a elegir en cualquier momento. Persiste mediante POST /api/crm/projects/:name/active-issue (escribe evento activity_log session_active_issue).
• Suite /issue de Telegram en cada child-bot — list, switch <id>, create <title>, close <id>, actual.
• Hook de fin de sesión auto-registra una entrada session_end con duración + recuento de commits + archivos modificados. Las etiquetas amplían el flujo de actividad por issue: session_start / session_end / switched_in / switched_away / auto_summary / reopened.
• Cron de auditoría nocturno marca proyectos con ≥5 eventos de actividad pero cero actualizaciones de issues en 24h y avisa al propietario mediante el master Telegram bot.

#116 — enforcement en tiempo de git: .githooks/commit-msg bloquea cualquier commit que no tenga #<id> (o closes #<n> / fixes #<n> / refs #<n> / resolves #<n> / (#<n>)) en algún lugar del mensaje. Las trailers Co-Authored-By + Signed-off-by se eliminan primero, por lo que las refs solo en trailer no satisfacen la regla. Los prefijos de mantenimiento (chore/docs/style/test/build/ci/refactor/perf), Merge / Revert / fixup! / [ci skip] pasan sin problema. El mensaje de error muestra el id de sesión activo del usuario para copiar y pegar. Override de emergencia: git commit --no-verify.

#117 — relleno retroactivo: arc retro <project> reconstruye issues desde ~/.arc/sessions/<project>-*.json + JSONLs de transcript + git log --since=started_at --until=ended_at. Deduplicación mediante similitud de título Jaccard (≥0.55) cruzada con una ventana de superposición de ±48h. Las entradas de actividad caen en marcas de tiempo originales mediante el nuevo campo opcional ts en POST /api/mcp/issues/:project/:id/log (los valores con fecha futura se recortan a ahora). El trabajo antiguo con commits se cierra automáticamente; el reciente sin terminar permanece abierto. Dry-run por defecto, --apply crea.

Estado actual

Phase 52.1 — F&F Beta Launch en progreso. El lanzamiento público está condicionado a los criterios de éxito (≥70% registro → primer_mensaje, ≥40% retención Día-1, ≥25% retención Día-7, 0 bugs P0 en los últimos 3 días).

• 6 agentes, 5 blueprints, 15+ skills, ARC CLI (3 plataformas + 9 subcomandos cloud), React CRM Dashboard con Context Rail + Timeline + IssuesRedesign, frontend Phaser (legacy), federación Telegram (Master + Children)
• 70+ endpoints CRM API en 19 módulos de dominio (auth, proyectos, workers, skills, sage, archivos, wiki, chat, analytics, billing, invites, etc.), HTTP Bun enlazado a 127.0.0.1
• Flujo dual-agent, Dynamic Workers con hot-reload fsWatch + ciclo de vida lazy, Bridge CLI, ARC CLI, Knowledge Dashboard, Cloud PM Chat, NotebookLM Bridge, Sage Worker + benchmarks A/B + Marketplace Discovery, Knowledge Graph
• i18n EN/UK (438 cadenas), autenticación web (email + OAuth + restablecimiento de contraseña + verificación de email mediante Resend), proyectos multi-tenant con owner_id SSOT, lifecycle hooks, watchdog con backoff exponencial, vault AES-256-GCM, watcher de auto-ingest
• Seguridad y privacidad: JWT (timingSafeEqual), puertas de multitenancy en cada ruta, lista blanca SSRF, bind loopback, zero-knowledge E2EE (PBKDF2 + AES-256-GCM, recovery keys), cabeceras CSP/X-Frame, sanitizador PII, smoke tests de regresión en cada deploy
• Monetización: Trial credits + Stripe billing Stage 1 (DB + middleware + estado), registro con puerta de invitación, tier de plan beta
• DX: Pre-push hook de cobertura de docs, descomposición de arquitectura Phase 48 (refactorización de monolito 10.779 → 373 LOC)

Arc OS. Construido de forma nativa sobre Claude Code. Los agentes hacen el trabajo. Google lo recuerda todo.