Dentro de QM: Leímos el entorno de ejecución de agentes de toda la empresa de Y Combinator

Why it matters

QM turns YC's experience operating more than 50 internal agents into a self-hostable control plane, making permissions, persistent workspaces and fleet administration the core infrastructure problem.

Revisión de código: yc-software/qm en el commit 7f2c916, la revisión de origen registrada en el paquete npm @yc-software/qm@0.1.4

Dos días después de que Y Combinator publicara QM, el proyecto ya había atraído 6,600 estrellas en GitHub, 700 forks, 68 pull requests y 14 issues abiertas. Esa atención tiene sentido. QM es uno de los primeros intentos de código abierto por parte de una organización prominente para convertir el patrón local de agentes de codificación en infraestructura compartida de la empresa.

La descripción corta—“un arnés de agentes multijugador para el trabajo”—subestima la cantidad de maquinaria involucrada. QM es una capa operativa duradera y con ámbitos para agentes. Un bucle de modelo es un componente reemplazable. Alrededor de él están la resolución de identidad, un grafo de permisos, límites de archivos y memoria, intermediación de credenciales, políticas de comando, aprobaciones humanas, filtrado de contenido, programación en segundo plano, publicación de apps, registros de auditoría y gestión del ciclo de vida de sandboxes específica de la nube.

Esta es nuestra continuación del informe de lanzamiento de RuntimeWire. Descargamos el repositorio público y el paquete npm, fijamos ambos a la misma revisión, leímos el código de runtime y despliegue, generamos un directorio de despliegue fresco y ejecutamos la suite de pruebas CLI del paquete. El resultado es un mapa a nivel de código fuente de lo que hace QM, dónde viven sus ideas más fuertes y qué promesas de seguridad aún deberían tratarse como experimentos.

La versión corta

• “Multiplayer” significa que las personas y las salas obtienen ámbitos aislados. Un mensaje directo se resuelve en un ámbito personal; un mensaje de canal o de grupo se resuelve en estado compartido. El contexto de una ronda anterior se conserva únicamente cuando cada miembro de la audiencia actual tiene derecho a verlo.
• La computadora duradera es la idea central del producto. Cada ámbito obtiene archivos, software instalado y procesos de larga duración dentro de un sandbox. El modelo puede cambiar mientras el espacio de trabajo persiste.
• QM soporta Pi, OpenCode, Codex y Claude Code. Implementan una interfaz de arnés común, aunque sus capacidades difieren. Codex, Claude y OpenCode exponen roles nativos de subagente; Pi, la opción predeterminada recomendada, ejecuta el bucle de turno con ámbito sin esa capa nativa de subagentes.
• El paquete npm es una CLI de despliegue. No contiene runtime de QM. Genera un repositorio de despliegue y fija seis imágenes de contenedor preconstruidas por digest SHA-256.
• La memoria es texto plano con mantenimiento asistido por modelo. Hechos duraderos viven como viñetas en memory/MEMORY.md; la recuperación usa coincidencia de subcadenas sin distinción entre mayúsculas y minúsculas, contexto limitado y consolidación opcional por modelo. No hay una base de datos vectorial en la ruta predeterminada.
• La seguridad es un plano de control, no una afirmación de aislamiento endurecido. Reglas de comando, aprobaciones, concesiones de credenciales, umbrales de audiencia y filtrado añaden fricción útil. El propio modelo de amenazas de YC dice que la política de comandos es evadible, el material de credenciales es visible en los sandboxes, el filtrado es incompleto y el sistema está pensado para una sola organización de confianza.
• Una advertencia de seguridad ya está obsoleta. SECURITY.md dice que las apps publicadas pueden alcanzarse mediante enlaces de capacidad con token de portador. La implementación fijada elimina esos tokens de consulta, se niega a generar la cookie asociada y prueba que el enlace “no otorga nada”. El ingreso por subdominios incorporado ahora requiere una sesión de portal más pertenencia a la ACL, con un enlace de propietario de corta duración separado para administración.

Lo que realmente inspeccionamos

El historial del repositorio público comienza el 29 de julio con un commit llamado “Fresh repo history.” El paquete más reciente al momento del informe fue 0.1.4, publicado el 31 de julio a las 18:03 UTC. Sus metadatos en npm apuntan al commit 7f2c916360f1797a8ff2a77ce2ce40c5fabab087. Esa es la revisión usada a lo largo de este artículo.

La cifra de 74,814 líneas describe el runtime TypeScript bajo src, no todo el repositorio ni líneas lógicas escritas a mano. Es un conteo reproducible del sistema de archivos, útil principalmente como medida de superficie. Los archivos más grandes incluyen el orquestador de 2,841 líneas, la capa de herramientas comunes de 2,483 líneas y el adaptador de Pi de 2,047 líneas.

No desplegamos QM en Fly.io o AWS, no conectamos un workspace en vivo de Slack, no suministramos credenciales reales de modelos ni ejecutamos la suite raíz completa respaldada por Postgres. El propio CI del repositorio es más amplio: cinco shards de pruebas raíz, pruebas de durabilidad con Postgres, typechecking, cuatro builds de plugins, pruebas de humo de imágenes, varios linters, cheques de código muerto, pruebas de artefactos empaquetados y pruebas de contrato de despliegue. Nuestra ejecución independiente cubrió la vía publicada del CLI.

Por qué lo construyó YC

La nota de lanzamiento de YC ofrece una historia compacta. La organización comenzó con un bucle simple de agente en Ruby y algunas herramientas de datos internas, añadió crons y triggers de webhook, y luego aprovisionó más de 50 agentes Hermes como asistentes personales. Los agentes individuales eran útiles; administrar la flota se volvió el problema. YC quería la flexibilidad de esa configuración, la simplicidad del bucle anterior y la infraestructura que pudiera alojar por sí misma.

El nombre es abreviatura de quartermaster: la persona que coordina el trabajo bajo cubierta. Esa metáfora encaja con el código. QM dedica mucho más esfuerzo a decidir qué computadora, memoria y autoridad recibe un turno que a definir prompts de modelo.

El historial público nos cuenta menos sobre cómo evolucionó el sistema de lo que lo haría un repositorio normal de código abierto. SECURITY.md dice que las publicaciones de código fuente públicas intencionalmente empiezan con historial fresco y que los hashes de historial privado no son compatibles. Los 40 commits visibles cubren del 29 de julio al 31 de julio. Muestran preparación de la release y correcciones rápidas; no permiten sostener una narración forense del sistema interno anterior.

Qué se instala cuando instalas QM

La primera sorpresa es que el paquete npm no es el runtime. cli/README.md lo dice de forma directa: el paquete es una CLI de release y despliegue. Valida la configuración, renderiza la infraestructura, sube secrets, coordina upgrades y delega a herramientas como Docker, Fly, AWS, Terraform y Git. No tiene dependencias de runtime en JavaScript propias.

Ejecutar qm init crea un directorio de despliegue propiedad de la organización. En nuestra prueba con objetivo Docker produjo:

• qm.config.jsonc, un archivo del paquete fijado a 0.1.4, entradas de lockfile y manifiestos de imagen fijados por digest;
• .env.example que contiene nombres de secretos, más un .env vacío e ignorado en lugar de valores de credenciales;
• documentación para el operador y un archivo AGENTS.md;
• una skill de despliegue para Codex, con runbooks para setup, comprobación, despliegue y verificación;
• directorios de ejemplo para skills específicos de la organización y herramientas de sandbox.

El proceso de release construye seis imágenes—core, web UI, admin, portal, auth y sandbox base—luego firma cada digest exacto con Sigstore. El flujo de publicación en npm reemplaza referencias de imagen de marcador de posición con esos seis digests e invoca npm publish --provenance. El paquete que descargamos contenía los mismos digests producidos por esa release. Este diseño le da al operador artefactos inmutables de primera parte mientras mantiene el estado de despliegue específico de la organización en un repositorio separado.

También crea un límite de revisión importante. Leer solo el tarball de npm te dice cómo se generan los despliegues. El comportamiento en runtime vive en el código de los contenedores en la revisión de Git enlazada. Una revisión de seguridad necesita ambos.

El modelo mental útil: un ámbito, una computadora duradera

La arquitectura de más alto nivel de QM tiene tres piezas duraderas:

1. Postgres guarda sesiones, mensajes, revisiones de memoria, jobs, grants, registros de auditoría y otro estado del plano de control.
2. El core API resuelve identidad y ámbito, aplica políticas, programa trabajo, invoca el arnés seleccionado y registra el resultado.
3. Un sandbox por ámbito suministra archivos, comandos, procesos y software instalado.

Slack runs as an optional in-process plugin. La interfaz web, la interfaz de administración, el servicio de autenticación y el portal son servicios HTTP opcionales alrededor del núcleo sin cabeza. El runtime es TypeScript ejecutado directamente por Node; Fastify sirve la API, Slack Bolt maneja Slack y el cliente de navegador está construido con Vite y Lit. El repository README proporciona el propio diagrama conciso de YC.

Un turno normal procede aproximadamente así:

1. La interfaz de Slack o la web autentica al remitente y describe la audiencia actual.
2. La resolución asigna la conversación a un alcance y calcula los alcances montados, instrucciones, concesiones de ACL, política de comandos, postura de seguridad y umbral de egreso.
3. QM carga únicamente el historial y la memoria que puede ver toda la audiencia.
4. El harness seleccionado recibe un objeto de turno común y un conjunto fijo de herramientas de QM.
5. Las llamadas a herramientas pasan por envoltorios de política. Los comandos se ejecutan dentro del sandbox del alcance; el uso de credenciales pasa por el keychain y las reglas del broker.
6. Los resultados y la procedencia pueden ser filtrados antes de volver a ingresar al contexto del modelo.
7. La respuesta se entrega, el turno se persiste y la extracción de memoria se ejecuta de forma asíncrona.

Ese orden importa. QM no le pide a cada proveedor de modelos que implemente el aislamiento por empresa. Calcula el contexto de la empresa antes de invocar el modelo y envuelve la superficie de herramientas alrededor del modelo después.

“Multiplayer” es un grafo de autorización

La descripción pública dice que cada empleado y proyecto recibe un agent. En el código, un agent se entiende mejor como un alcance resuelto más estado durable. src/types.ts define cinco tipos de alcance:

El resolution service convierte un DM en el alcance personal del actor y una sala en estado compartido de canal o grupo. El alcance actual se monta en lectura-escritura. Las capas de organización y de equipo relevantes pueden montarse en solo lectura. Las instrucciones de la organización se sitúan por encima de las instrucciones de menor alcance; la personalización local no puede aflojar la seguridad ni el umbral de aprobación de la organización.

El detalle de implementación más agudo es el filtro de audiencia. context-filter.ts conserva un elemento del historial solo cuando cada persona en la audiencia actual tiene derecho a él. Si una interacción privada se vuelve compartida, el modelo no hereda automáticamente la transcripción privada. Las reglas de egreso usan la misma forma conservadora: los hosts permitidos se intersectan entre los miembros de la audiencia y los hosts denegados se unifican por unión.

El compartido está respaldado por un grafo de ACL. Los managers conceden o revocan acceso; un destinatario no puede retransmitir transitivamente un objeto a menos que la política lo permita por separado. Para un identificador de archivo propiedad de la audiencia, las comprobaciones consideran tanto al propietario como a los destinatarios con derecho. Esto es lógica de autorización real, no un prompt que le diga al modelo que tenga cuidado.

El modelo de amenazas de YC todavía registra una brecha: las etiquetas de procedencia aún no cubren todos los caminos de origen, y el juez ambiental de Slack no realiza una comprobación interna completa de la audiencia. El umbral de audiencia es una de las ideas más fuertes de QM. Sus propios mantenedores no lo presentan como un control completo de flujo de información.

Memoria: un cuaderno, un extractor y un limpiador

El sistema de memoria por defecto de QM es agradablemente verificable. Cada alcance escribible tiene un archivo memory/MEMORY.md que contiene hasta 300 hechos en viñetas. La recuperación está limitada a aproximadamente 6,000 caracteres. memory-service.ts elimina duplicados de hechos exactos, descarta el más antiguo cuando el cuaderno está lleno y responde consultas de memoria usando coincidencia de subcadenas en minúsculas con condición AND.

No existe un índice semántico ni un almacén de embeddings en la implementación por defecto. El modelo aporta la inteligencia alrededor de un libro mayor en texto plano.

Después de una ráfaga de actividad —por defecto, hasta diez turnos separados por no más de tres minutos de silencio— la estrategia per-turn solicita a un modelo extraer preferencias duraderas, identificadores y hechos del proyecto. Su prompt excluye secretos y la mecánica del sistema. Los hechos dichos en un canal o grupo también pueden copiarse en el cuaderno personal del hablante con procedencia como “dicho en #channel”; los hechos de los DMs se excluyen de esa ruta de copia.

Después de diez hechos nuevos, una pasada de consolidación puede reescribir el cuaderno mediante operaciones ADD, UPDATE y DELETE. El prompt indica que una instrucción explícita “recuerda esto” no debe debilitarse ni eliminarse y que la procedencia debe sobrevivir. La base de datos conserva revisiones, por lo que la memoria puede restaurarse. Debido a que la extracción y la consolidación ocurren después de la respuesta, la nueva memoria es eventualmente consistente en lugar de garantizada dentro del turno recién completado.

Existen dos estrategias alternativas. agent-only deja el mantenimiento a acciones explícitas del agent. scratch-promote escribe registros scratch fechados, recupera por defecto los últimos dos días y periódicamente solicita a un modelo promover ítems duraderos al cuaderno. La estrategia es seleccionable desde una interfaz; per-turn es la predeterminada.

Este enfoque es fácil de auditar y editar. También hace que el modelo forme parte de la política de retención. Una extracción defectuosa puede registrar un hecho incorrecto, y el material durable puede persistir indefinidamente a menos que un usuario o administrador lo elimine. QM reconoce ese riesgo.

Las implementaciones del sandbox son materialmente diferentes

La interfaz del sandbox cubre ejecución de procesos, disco durable, entornos scratch, suspensión, hidratación y capacidades opcionales de egreso. Los backends disponibles no proporcionan un aislamiento idéntico.

Los valores predeterminados de AWS son cuatro vCPUs, 8 GB de RAM, un disco de 8 GB y una sesión máxima de ocho horas, con rotación a las 7.5 horas. Antes de la suspensión o rotación, el directorio home del alcance se empaqueta y se escribe en S3; la siguiente VM lo hidrata. Así es como sobrevive en un sustrato de cómputo efímero la idea de “las herramientas instaladas permanecen instaladas”.

QM también crea sandboxes scratch para tareas puntuales. Los entornos scratch están libres de credenciales, montan solo el contexto global de la organización y se destruyen después del turno. Eso los hace útiles para procesar material no confiable con un radio de impacto menor.

La frase “durable computer” no debe leerse como un sandbox de red universal. El descriptor de despliegue acepta configuración de egreso, sin embargo docs/deploy-directory.md indica que la versión uno valida ese descriptor sin afirmar la aplicación en tiempo de ejecución. El documento de seguridad dice que el egreso condicional depende del backend. Local Docker y AWS reportan explícitamente que no hay soporte nativo de egreso a través de esta interfaz.

Cuatro harnesses, un core — y capacidades disparejas

QM fija cuatro integraciones modelo-agent en esta revisión:

Los cuatro implementan el contrato HarnessAdapter. Eso permite que la misma resolución de alcance, política, persistencia y registro de herramientas rodee diferentes bucles de agent. El modelo y el harness pueden seleccionarse globalmente y anularse por alcance dentro de los límites del operador.

La superficie común de herramientas es pequeña: execute, read, write, publish, memory, history y background, con cron, sharing, guidance y herramientas para finalizar turnos añadidas cuando el plano de control lo permite. En modo de solo lectura, solo la recuperación de memory, history y el fin silencioso de turno sobreviven. La postura Strict envuelve cada llamada a herramienta con efectos en una aprobación humana.

Codex, Claude y OpenCode luego exponen su propia maquinaria restringida de tareas-hijo. El hook de Claude evita que los agentes-hijo contacten a personas, programen eventos, cambien la configuración permanente o supriman la respuesta del padre. Codex mapea eventos de tareas del servidor de aplicaciones al run de QM y limita las herramientas hijo. Estos son verdaderos subagentes, distintos del más amplio lenguaje “fleet” de YC. La fleet es principalmente el conjunto de personas persistentes y los ámbitos de sala; los agentes-hijo son trabajadores temporales dentro de algunos arneses.

La dependencia Pi merece una nota al pie. YC publica qm-pi-coding-agent-0.82.0-security.2 desde su repositorio yc-software/pi. Comparar esa etiqueta con Pi 0.82.0 upstream mostró cambios en siete archivos: una sobreescritura de brace-expansion pasó de 5.0.7 a 5.0.8 en los metadatos de lock/package, y se añadió una licencia MIT al paquete. No encontramos un fork en el bucle de agente que cambiara el comportamiento en ese diff. La etiqueta personalizada es un parche estrecho de empaquetado y cadena de suministro.

Credentials: strong brokerage until materialization

El llavero de QM almacena registros de credenciales cifrados. La implementación usa AES-256-GCM con claves derivadas mediante HKDF. Los grants vinculan una credencial a un scope, persona y modo; pueden ser de un solo uso o permanentes, y pueden expirar. Una persona puede otorgar credenciales desde su propio scope personal. Los grants permanentes y el compartido más amplio siguen sujetos a las reglas del operador.

Para uso HTTP soportado, el broker de credenciales es la mejor vía. El núcleo verifica los encabezados del llamante y la habilitación, requiere HTTPS, empata el hostname de destino y una regla de subdominio opcional, limita métodos y prefijos de ruta, inyecta el secreto dentro del core y limita los tamaños de solicitud y respuesta. El comando sandbox ve el endpoint del broker en lugar del token subyacente.

Esa protección termina cuando una credencial se materializa en un sandbox para un CLI u otra herramienta que no puede usar el broker. SECURITY.md dice que el material está en texto plano y es legible por el software en ese sandbox. El campo purpose de un grant se registra y se muestra al modelo; no es autorización aplicada después de la materialización. One-time significa una sola materialización atómica, no una sola operación API aguas abajo.

Esa distinción es esencial. QM tiene un plano de control de credenciales serio. No puede obligar a un cliente de línea de comandos arbitrario con sesión iniciada a mantener un token secreto frente al agente que controla esa misma máquina.

Three security postures, plus an always-on command floor

Un operador selecciona una postura organizacional; ámbitos más estrechos pueden endurecerla:

Los tres conservan un piso de políticas de comandos. Las reglas predeterminadas requieren aprobación para borrados recursivos, force pushes, SQL destructivo y descargas canalizadas por shell; se niegan el formateo del sistema de archivos y una fork bomb. El scanner expande recursivamente cargas útiles anidadas de shell hasta una profundidad de ocho.

Esto es una protección útil contra accidentes y ataques obvios. No es un límite de seguridad de shell. Los mantenedores dicen que codificar una carga útil o escribir y ejecutar un script puede eludir las reglas. El modelo y el sandbox se tratan explícitamente como no confiables, mientras que el operador, el host core y la base de datos permanecen privilegiados.

La capa de filtrado automática igualmente tiene límites. Recolecta contenido externo etiquetado con procedencia, limita lo que envía al clasificador y puede poner en cuarentena contenido cuando el clasificador devuelve un veredicto strict. Algunos caminos de filtrado no disponibles o no soportados fallan abiertos con un marcador de advertencia y un evento de auditoría. El juez ambiente de Slack y el sidecar de OpenCode tienen rutas que no todas pasan por la misma pasarela del modelo. Las acciones del navegador quedan fuera de la política de command/HITL, y el acceso de red del proveedor de navegador no necesariamente sigue la egress del sandbox.

El documento de seguridad de YC es refrescantemente directo sobre el entorno previsto: un despliegue interno de una sola organización con un operador de confianza. No se presenta como multi-tenant público endurecido, una certificación o una prueba de confinamiento. Los administradores son lectores privilegiados de contenido, los proveedores de modelo y navegador reciben los datos que se les envían, y las sesiones duraderas, registros de auditoría, archivos y memoria pueden permanecer indefinidamente.

The app-link documentation drift

Nuestra conclusión de mayor impacto en código versus documentación concierne a las apps publicadas.

El modelo de amenazas dice que un owner puede distribuir un enlace de capacidad bearer y que cualquiera que lo posea puede alcanzar la app. Eso aparentemente era cierto en un diseño anterior. En la release fijada, el ingreso por subdominio incorporado se comporta de forma diferente.

deployments.ts elimina ?access= de la URL, borra cookies de capability obsoletas y se niega a acuñar un reemplazo. El acceso ordinario a la app requiere una sesión de portal válida y una verificación ACL. Los owners pueden solicitar un enlace de gestión firmado separado con una expiración de cinco minutos. El test correspondiente se llama “un enlace de capability no concede nada — el alcance lo determina solo la ACL,” y afirma que las credenciales caducadas en query y cookie fallan.

La conclusión precisa es estrecha: los enlaces de visitante bearer están deshabilitados en la pasarela de subdominio incorporada en 0.1.4; SECURITY.md no se ha actualizado. Los plugins personalizados o endpoints de apps expuestos externamente necesitan su propia revisión.

Launch-week bug reports

El rastreador público de issues se está moviendo rápidamente. Al momento del reporte, había 14 issues abiertos. Varios son reportes detallados con referencias a código en lugar de solicitudes de función. Incluyen un despliegue reciente en Fly que no solicita ni empuja SPRITES_TOKEN (#130), un RPM fijado del GitHub CLI que ya no está disponible para la build de AWS MicroVM (#122), un mensaje de Slack solo con attachment que se pierde durante la guía en medio de una ejecución (#48), y el acuse de recibo de entrega ocurriendo antes de que una respuesta en Slack se publique con éxito (#44).

No reproducimos esas cuatro rutas operacionales. Deben leerse como reportes abiertos, no como vulnerabilidades confirmadas. Su especificidad sigue siendo evidencia útil sobre la madurez: 0.1.4 es una release de semana de lanzamiento, y se están descubriendo casos límites de nube y entrega en público.

Background work: crons, watches and a webhook-shaped gap

El sistema de background de QM tiene dos mecanismos claros.

Los crons soportan expresiones cron, zonas horarias, schedules por intervalo, first-fire times, identidad run-as y un destino. Cada disparo crea un hilo nuevo mientras la definición de tarea, el workspace y el fire log persisten. Los jobs respaldados por Postgres usan pg-boss; identificadores singleton y leases limitan trabajo duplicado. Hay una barrida de scheduler disponible como recuperación. La concurrencia por defecto de cron-fire es cuatro.

La herramienta background también puede dejar un proceso corriendo en el sandbox y registrar una watch sobre su salida, salida de proceso, texto que coincida u otras condiciones. El monitor poller usa un heartbeat de tres minutos por defecto, hace cumplir un intervalo mínimo, limita los eventos almacenados y despierta la conversación original a través de la ruta de turno filtrada por seguridad. Una watch expira y las sesiones de proceso tienen reglas estrictas de time-to-live; la fan-out de eventos está limitada.

La nota de release de YC dice que su agente histórico en Ruby adquirió triggers de webhook. El runtime abierto contiene webhook como un tipo de procedencia/origen de sesión y la documentación de despliegue muestra endpoints con forma de webhook que pueden ser proxyables. No hallamos un receptor de webhook incorporado y general que cree turns ordinarios en esta revisión. Esa capacidad puede esperarse de un plugin de organización o una integración externa. Crons y process watches son las rutas completas y directamente trazables de background en el core público.

Internal app publishing

La herramienta publish convierte código propiedad de un scope en una app interna versionada. Los registros de despliegue vinculan una app a su owner y scope, mantienen versiones, soportan actualizaciones y rollback, y adjuntan grants de view/manage. Las apps son solo para el owner hasta que se comparten mediante ACLs. El acceso Git usa autorización firmada, que expira y está vinculada al principal, y verifica la revocación.

QM trata el código de la aplicación como un límite de confianza separado. El núcleo no revisa el código de aplicación generado por seguridad. Las credenciales o valores de entorno proporcionados a una aplicación son explícitos, y las credenciales ambientales del autor se mantienen fuera del tiempo de ejecución de la aplicación. La gateway incorporada agrega la identidad del portal y verificaciones de ACL, como se describió arriba.

Esta característica hace que QM sea más amplio que un asistente de chat. Una conversación puede producir una pequeña superficie operativa, publicarla a un equipo y continuar actualizando sus datos en segundo plano. También amplía la carga de trabajo de seguridad de aplicaciones: cada aplicación generada se convierte en software que un operador debe monitorear, parchear y eventualmente retirar.

Deployment and rollback

Los destinos soportados son Docker local, Fly.io y AWS. Fly combina aplicaciones con Sprites/Machines. AWS renderiza servicios ECS Fargate, RDS, S3 y la capa sandbox MicroVM. Slack usa Socket Mode dentro del core; el portal es el punto de entrada público previsto.

El directorio generado es un contrato entre una organización y la CLI. La configuración y los nombres de secretos viven allí; los valores secretos permanecen en el entorno del operador y en la tienda de secretos del proveedor. Una organización puede añadir herramientas, habilidades, una imagen de sandbox personalizada y plugins sin modificar el core. Las imágenes de release permanecen fijadas por digest.

Los rollbacks tienen diferentes significados según el destino. La ruta de Fly restaura el pin del sandbox anterior. El desmontaje de Docker puede ser destructivo cuando se solicita purge. AWS toma un snapshot de RDS antes de un despliegue mutante; el rollback de código y configuración no restaura por sí mismo el contenido de la base de datos, por lo que la CLI imprime el punto de restauración para la acción del operador.

El proyecto por defecto no contiene ningún flujo de trabajo de despliegue en producción activo. Terraform y las acciones en la nube siguen siendo ejecutadas por el operador. Eso evita conceder silenciosamente amplios privilegios de infraestructura al CI, aunque también significa que el control repetible de cambios es responsabilidad del adoptante.

A las organizaciones que quieren core y personalizaciones privadas en un solo repositorio se les indica crear un clon privado independiente, nunca un fork de GitHub. Los forks de GitHub comparten una red de objetos y los forks públicos no pueden volverse privados; un commit empujado a esa red puede seguir siendo recuperable por hash. QM sitúa el material privado bajo deploy/layers/<org>/ y provee habilidades para fusionar upstream y preparar parches upstream depurados. Se espera que el core permanezca idéntico byte a byte al QM público.

A codebase built by agents, governed through prose

La política de contribución de QM es tan interesante como el runtime. CONTRIBUTING.md dice que agentes que codifican escriben la mayor parte del código subyacente. A los contribuyentes externos se les pide presentar propuestas informales, escritas por humanos, bajo adrs/; los mantenedores entonces usan sus propios agentes y el contexto para implementar las ideas aceptadas. El directorio público estaba vacío aparte de un marcador en la revisión revisada.

El interno AGENTS.md es estricto: evitar comentarios y docblocks, nunca auto-revisarse, usar un agente independiente para la revisión, ejecutar pruebas afectadas, realizar QA en vivo en Slack cuando sea relevante, capturar capturas de pantalla para cambios visibles y preservar el límite entre repositorio privado/público.

Esto ayuda a explicar la forma del código. Las interfaces son explícitas, las pruebas son abundantes y los nombres llevan más peso explicativo porque se desaconsejan los comentarios. También crea un modelo de gobernanza inusual: los contribuyentes proponen la intención, los mantenedores gastan el presupuesto de inferencia, y un agente realiza una revisión independiente. La calidad de esa revisión depende de los prompts, del contexto y de la disciplina de ejecución que solo son parcialmente visibles en Git.

What QM gets right

El alcance es la unidad duradera, más que una conversación específica de un proveedor. Esa decisión le da a QM una respuesta coherente a varios problemas difíciles a la vez: trabajo compartido, personalización personal, computadoras persistentes, cambio de modelo y contexto consciente de permisos.

El filtro de contexto a nivel de audiencia es particularmente fuerte. Muchos agentes de trabajo añaden control de acceso a la recuperación y luego dejan el historial de conversación como contexto ambiental. QM vuelve a evaluar el historial contra toda la audiencia actual. Su regla de intersección/unión para el egreso aplica la misma idea a la acción.

La separación del despliegue también está disciplinada. Una pequeña CLI que incorpora información de procedencia crea un repositorio de la organización y fija imágenes firmadas. Los detalles de la organización pueden permanecer fuera del árbol de código fuente público. La reproducibilidad y la privacidad tienen mecanismos concretos en lugar de depender de la promesa de un README.

Finalmente, el modelo de amenazas es útil porque nombra las fallas que los operadores probablemente malinterpretarán. Credenciales en texto plano dentro de una computadora controlada, reglas de patrones de shell sorteables, procedencia incompleta, canales laterales en el navegador y administradores privilegiados son las verdaderas líneas de falla de un sistema de agentes interno.

Where the model still leaks through the abstraction

La interfaz de harness hace que los proveedores sean intercambiables a nivel del plano de control. No son equivalentes en comportamiento. El direccionamiento, las sesiones gestionadas por el proveedor, los modos de pensamiento, el manejo de imágenes y el soporte de agentes hijos varían según el adaptador. Una empresa que cambie de harness debe esperar distinta calidad de tareas, latencia, costo y modos de falla incluso cuando los permisos se mantengan estables.

La consolidación de memoria y el filtrado de contenido delegan el juicio de nuevo en los modelos. El código circundante limita sus entradas y registra los resultados; no puede garantizar una clasificación correcta. La consulta de memoria predeterminada también es lo bastante literal como para que hechos útiles puedan pasarse por alto a menos que la redacción actual se solape con el punto almacenado.

El egreso es el control de infraestructura menos uniforme. Algunos backends pueden forzar el enrutamiento de dominio a través de un proxy; otros no exponen ningún mecanismo nativo de aplicación de políticas a través de QM. Los proveedores de navegador y los runtimes de aplicaciones añaden límites de red separados. Un operador necesita un diagrama de flujo de datos específico del despliegue antes de tratar la “política de egreso” como una garantía universal.

La madurez operativa es la restricción final. El código fuente contiene un programa de pruebas sustancial y una maquinaria de lanzamiento cuidadosa. El paquete tiene días de antigüedad, el historial público es deliberadamente superficial, y están abiertos los errores en la nube de la semana de lanzamiento. Esos hechos pueden coexistir.

The verdict

QM es una arquitectura de referencia creíble para agentes a nivel empresarial. Su contribución definitoria es la combinación de autoridad acotada y computadoras duraderas: cada persona o sala recibe un entorno de trabajo persistente, mientras que el núcleo recalcula contexto y permisos para cada audiencia y acción. El bucle de modelo puede ser entonces Pi, OpenCode, Codex o Claude sin convertirse en la fuente de la verdad organizacional.

El proyecto está listo para estudiarse, prototiparse y adaptarse dentro de una organización de confianza con operadores experimentados. La adopción en producción exige un modelo de amenazas ligado al sandbox elegido, al proveedor de identidad, a los conectores, a los proveedores de modelos y a las obligaciones de retención. Una postura estricta puede pausar acciones; no puede reparar un comando generado inseguro después de que un humano lo apruebe. El filtrado automático puede reducir la exposición; no puede probar que la inyección de prompts esté contenida. Un espacio de trabajo duradero aumenta el riesgo de capacidad y de retención de datos al mismo tiempo.

El lanzamiento público importa porque expone las partes difíciles. El código más valioso de QM se encuentra alrededor del agente: el filtro de audiencia, el servicio de resolución, el almacén de ACL, el intermediario de credenciales, el registro de ejecuciones, el planificador y el ciclo de vida del sandbox. Esa es la capa que las discusiones sobre agentes de trabajo a menudo han pasado por alto. YC ha puesto ahora una implementación seria sobre la mesa, junto con suficientes advertencias para mostrar cuán incompleta sigue siendo la categoría.

Reproduction notes

# Pin the reviewed source
git clone https://github.com/yc-software/qm.git
git -C qm checkout 7f2c916360f1797a8ff2a77ce2ce40c5fabab087

# Download the reviewed package
npm pack @yc-software/qm@0.1.4
sha256sum yc-software-qm-0.1.4.tgz

# Inspect package metadata and provenance pointer
npm view @yc-software/qm@0.1.4 version time dist --json

# Generate a local deployment directory without putting secrets in config
npm exec --yes --package=@yc-software/qm@0.1.4 -- \
  qm init ./qm-deploy --org example --target docker

El tarball SHA-256 de RuntimeWire fue 51593f853eade42ed04f10e96e1c8ddffca876c5be0ee98d753636018ee5e473. Los lectores deben esperar que el campo de integridad publicado por npm permanezca estable para la misma versión inmutable.

Primary source index

1. Nota de lanzamiento de QM de YC
2. Repositorio de QM y commit revisado
3. README y arquitectura del sistema
4. Modelo de amenazas y limitaciones conocidas
5. CLI y contrato de despliegue
6. Resolución de alcance y filtrado de audiencia
7. Servicio de memoria y estrategias de memoria
8. Interfaz de sandbox, Docker local, Sprites y AWS
9. Interfaz de harness y adaptadores
10. Posturas de seguridad, política de comandos y keychain
11. Ingress de app publicada y prueba de capability-link
12. Flujo de trabajo de CI, flujo de trabajo de imagen firmada y flujo de trabajo de procedencia de npm
13. Política de contribución y instrucciones para agentes

Divulgación: RuntimeWire realizó una revisión estática del código fuente y de los paquetes, además de pruebas locales de la CLI. Esto no fue una prueba de penetración ni una auditoría de despliegue en producción. Los conteos de repositorios e issues son una instantánea del 2 de agosto de 2026.