YC abrió el harness con el que se corre a sí mismo: así levantas qm en Fly en una tarde
Y Combinator acaba de publicar el agent harness que usa para correr su propia empresa. No es un demo ni una implementación de referencia: es lo que está efectivamente detrás del trabajo de accounting, legal, eventos e ingeniería de YC, incluido el trabajo de construir qm.
El repo es github.com/yc-software/qm, licencia MIT, 19 commits de vida, y hoy llegó a la portada de Hacker News con 640 puntos y 151 comentarios. El tagline es deliberadamente acotado:
“A multiplayer agent harness for work. In Slack and on the web.”
Esa palabra — multiplayer — es toda la tesis, y es lo que separa a qm de la pila de agent runners que venimos cubriendo este año. Instalémoslo y veamos qué hay debajo.
Qué te compra realmente el “multiplayer”
La mayoría del tooling de agentes asume un desarrollador, una terminal, un contexto. qm asume una empresa.
Cada persona y cada sala de Slack tiene su propio scope. Un scope no es un perfil de configuración: es una unidad aislada con su propia memoria, sus propios archivos, su propio keychain, su propio set de permisos, sus propios crons y su propio sandbox durable. La memoria de tu scope no se filtra al mío. El keychain de la sala #finance no es alcanzable desde el agente de la sala #eng.
Esa es la parte donde vale la pena detenerse. El problema difícil en despliegues de agentes para equipos nunca fue “puede el modelo llamar a una tool”. Fue “cómo le doy al agente suficientes credenciales para que sea útil sin darle a cada agente de la empresa todas las credenciales”. Los scopes son la respuesta de qm, y son la razón por la que esto es arquitectónicamente más interesante que un bot token compartido en un workspace de Slack.
Encima de eso: los crons y watches corren trabajo cuando nadie está mirando, y los scopes pueden construir y publicar aplicaciones web internas. La misma identidad y configuración, estés en Slack o en la web UI.
Por debajo es Node/TypeScript sobre Fastify, PostgreSQL para sessions, memory y queue, y un sandbox por scope para la ejecución de tools. Los plugins opcionales cubren Slack, la web UI y un panel de admin.
La parte que más debería importarte: no es una jugada de vendor
Acá está la decisión de diseño que hace que qm valga tu tiempo incluso si nunca lo adoptas:
“Pick your own harness and model and switch between them — Pi, OpenCode, Codex, and Claude Code.”
El core es harness-agnostic. YC construyó el modelo de scopes, el sistema de permisos, el sandbox y la integración con Slack como la capa durable, y dejó al coding agent propiamente dicho como un componente intercambiable.
Eso invierte la dependencia habitual. Si estandarizas hoy a tu equipo en Claude Code y en seis meses Codex es mejor, migras el agente, no el deployment. Todo lo caro de construir — el modelo de identidad, los límites de credenciales, la superficie de auditoría, el cableado con Slack — sobrevive al cambio.
Cualquiera que haya visto a un equipo reconstruir todo su tooling interno porque un vendor cambió de rumbo sabe exactamente cuánto vale eso.
Ponerlo a correr
El CLI es un CLI de deployment, no el runtime. Delega en Docker con Buildx, flyctl, el AWS CLI y git, así que ten eso en tu máquina primero. Terraform lo corres tú contra los módulos que init te genera.
Hay tres targets: docker, fly y aws. Empieza con docker. Obtienes el modelo de scopes completo en tu propia máquina antes de gastar un peso en infraestructura, y descubres si qm encaja con el modelo mental de tu equipo antes de estar debuggeando una task definition de Fargate.
npm exec --yes --package=@yc-software/qm@latest -- \
qm init . --org acme --target docker
npm install
qm init materializa un repositorio de deployment. Obtienes qm.config.jsonc (se commitea, sin secrets adentro), un package.json que pinea el CLI en la versión exacta que armó el directorio, un deployment.md generado y escrito para tu target, .env.example junto a un .env ignorado, los archivos de manifest de Slack, y los directorios sandbox/, plugins/ e infra/.
Ese pin de versión es un detalle chico con consecuencias grandes: contract: 1 es solamente el piso de compatibilidad, y el pin significa que cada checkout de tu repo resuelve el mismo intérprete. Actualizas deliberadamente, no porque alguien corrió npm update un viernes.
De ahí en adelante el loop es el mismo sin importar el target:
npm exec qm -- check # config, secrets, tools, skills, plugins — sin red
npm exec qm -- infra render
npm exec qm -- doctor # verifica prerequisitos externos, read-only
npm exec qm -- infra build-image
npm exec qm -- plan
npm exec qm -- up --yes
npm exec qm -- check --live
Vale la pena internalizar el orden check antes de doctor antes de plan antes de up. Tres de esos cuatro son read-only, lo que significa que puedes llegar bastante lejos hacia un deployment correcto sin mutar nada.
Cuando pases a Fly, cambia el target en el init — --target fly — y qm corre los servicios como Fly apps con Fly Machines como agent computers. En AWS obtienes tasks ARM64 pineadas por digest sobre ECS Fargate, con Lambda MicroVMs como agent computers, y las mutaciones en AWS exigen el --yes explícito.
El camino de AWS tiene una comodidad operativa que vale la pena mencionar: se toma un snapshot de RDS previo al deploy, bajo un deploy lease y antes de las mutaciones, nombrado según el manifest del deployment y registrado en él. qm rollback --to <revision-or-sha> restaura código y configuración e imprime el punto de restauración de datos, así que el rollback de código y el de datos siguen siendo decisiones separadas. Puedes apagar los snapshots con aws.predeployDbSnapshot: false — que tengas que optar por salir es el default correcto.
Para el día a día tienes status, logs [service] -f --tail n, outputs --json, secrets push --from <file> y slack render. down --purge cuando termines de experimentar.
Tres posturas de seguridad, y su lectura honesta
qm trae una postura de seguridad a nivel org con tres valores, descritos en el repo así:
- Strict — “every harness tool call pauses for human approval”
- Auto (el default) — “a classifier screens provenance-labelled external data”
- Dangerous — “no content screening, no pauses between tool calls”
El provenance labelling del default Auto es lo interesante: la data externa lleva una etiqueta, y el classifier filtra sobre esa etiqueta en vez de intentar razonar sobre el contenido en frío.
Ahora la parte que merece más atención de la que le dio la cobertura del lanzamiento. El propio SECURITY.md de YC es inusualmente franco, y no se lee como marketing:
- qm está descrito como software experimental. Aislar la data por scope se plantea como objetivo de diseño, y explícitamente “not a promise that data cannot leak, a certification, or a substitute for a deployment-specific security review”.
- La command policy es evitable mediante ofuscación o haciendo que el agente escriba un script. El planteo de YC: atrapa errores, no ataques sofisticados.
- Las credenciales del sandbox quedan en texto plano mientras están en uso. Si el proceso del agente se compromete, quedan expuestas.
- El propósito de una credencial viaja como guía, no como autorización aplicada.
- Los admins de la org pueden leer transcripts, memoria y metadata sensible. Queda auditado, pero no requiere aprobación aparte.
- Los links de apps publicadas son bearer tokens. Cualquiera con el link entra, y la revocación es incompleta.
También hay un cooldown de dependencias de 7 días (min-release-age=7) que gatea las instalaciones de npm, y ese es un default de supply-chain genuinamente bueno que más proyectos deberían copiar.
Lee esa lista por lo que es: un equipo documentando su threat model con honestidad en vez de reclamar un límite que todavía no construyó. Eso es más útil que una página de seguridad de vendor. Pero también significa que la movida correcta para la mayoría de los equipos es --target docker en una laptop, o un deployment en Fly con credenciales que no sean de producción — no rutear el keychain real de tu empresa por ahí este trimestre.
La objeción del hilo de HN
Hay una crítica del hilo que vale la pena arrastrar hasta acá. Pese al pitch de desplegar en tu propia cuenta de cloud, un comentarista argumentó que la arquitectura “feels like it’s written to run on one mac/vm”, con las mismas restricciones prácticas que las plataformas contra las que qm se posiciona. El propio anuncio de YC enmarca a qm como “easy to customize, like Hermes or OpenClaw, but useful for a whole company” — y si ya desplegaste Hermes, esa es justamente la comparación que conviene que pruebes tú mismo en vez de darla por buena.
Diecinueve commits son diecinueve commits. El modelo de scopes es la contribución real acá, y vale la pena estudiarlo lo despliegues o no.
Quién debería correr esto de verdad
Si eres un desarrollador solo, Mux o un harness a secas te van a servir mejor; toda la propuesta de valor de qm es el límite entre personas, y ahí no hay límite que trazar.
Si manejas un equipo de cinco a cincuenta y vienes improvisando el acceso de los agentes con tokens compartidos y buenas intenciones, dedícale una tarde a --target docker. El modelo de scopes va a coincidir con cómo tu equipo ya piensa los permisos, o no va a coincidir, y lo vas a saber en un par de horas. Es una respuesta barata a una pregunta cara.
¿Y tú? ¿Cómo estás resolviendo hoy el problema de darle credenciales a un agente sin abrirle toda la casa — scopes, tokens compartidos, o todavía nadie tocó el tema en tu equipo?