Y Combinator open-sources QM: el harness de agentes IA para toda la empresa

¿Qué es QM?

El 31 de julio de 2026, Y Combinator publicó QM (Quartermaster) bajo licencia MIT en GitHub. No es un demo ni una lista de espera: es el harness real que YC construyó después de operar más de 50 agentes Hermes internos y chocar contra el techo de lo que los asistentes personales pueden hacer cuando se les da a toda una empresa.

QM es un harness de agentes multiplayer para trabajo: corre en Slack y en la web, y da a cada empleado y cada canal su propio scope aislado con memoria, archivos, credenciales, permisos y sandbox dedicados.

El problema que resuelve

Los agentes IA actuales están diseñados como asistentes personales: Claude Code, OpenCode y Codex sirven a un desarrollador en un repo. Hermes y OpenClaw escalan para power users individuales. Pero cuando una empresa quiere dar agentes IA a 20+ personas across contabilidad, legal, eventos e ingeniería, los problemas aparecen:

• Credenciales compartidas: no puedes escalar un setup de un solo usuario sin dar acceso a tu API key a múltiples empleados.
• Contexto que se filtra: el contexto privado de finanzas no debería llegar al sandbox de ingeniería.
• Gobernanza ausente: no hay forma central de definir qué modelos y herramientas puede usar cada persona.
• Auditoría: las acciones del agente deben ser atribuibles a una persona y un scope.

QM ataca exactamente estos problemas. Como dijo Eve Bouff del staff de YC: "he sido la usuaria #1 de qm durante meses. Hoy lo estamos open-sourcing. Ha sido mesmerizante ver a los partners y staff de YC usarlo para multiplicarse por 1000."

Arquitectura: el scope es la unidad, no el usuario

La decisión de diseño más sharp de QM es que la unidad fundamental es el scope, no el usuario. Cada persona obtiene un scope. Cada canal de Slack obtiene un scope. Cada scope tiene su propio stack completo e independiente:

• Memoria persistente (notebook de markdown en Postgres)
• Filesystem durable
• Keychain de credenciales scoped
• Cron jobs y web apps
• Sandbox aislado con disco persistente
• Permisos propios

Un canal compartido tiene acceso al mismo contexto acumulado sin importar qué colega hable con el agente. La identidad y configuración se mantienen entre Slack y la web app.

Los tres componentes durables

1. Postgres: sesiones, mensajes, revisiones de memoria, jobs, grants, audit records y estado del control plane.
2. Core API: resuelve identidad y scope, aplica policy, schedulea trabajo, invoca el harness seleccionado y registra resultados.
3. Sandbox per-scope: archivos, comandos, procesos y software instalado.

Model-agnostic: 4 harnesses intercambiables

QM no ata a un vendor. Cuatro coding agents pueden manejar el mismo core de forma intercambiable:

Harness	Dependencia	Integración	Child agents nativos
Pi	@mariozechner/pi-ai 0.82.0	In-process	No
OpenCode	1.17.18	HTTP/plugin	Research, code, consult
Codex	0.144.5	JSON-RPC app server	Spawned tasks constrained
Claude Code	Agent SDK 0.3.211	SDK with in-process MCP	Research, code, consult

Todos implementan el contrato HarnessAdapter. El modelo es policy de la organización, no preferencia del usuario: un admin define qué harnesses y modelos están aprobados, los individuos heredan el default y pueden overridear dentro del allowlist, pero nunca pueden seleccionar un runtime prohibido.

Seguridad: el doble de código de access control que de modelo

El repo tiene 342 archivos TypeScript en 50 módulos. 13 archivos implementan el harness (el loop que habla con el modelo). 26 archivos implementan access control, identity, auth, audit, policy, credentials y security. El doble de código gobierna quién puede ver qué que el que maneja el modelo.

El audience filter

En un canal compartido, varias personas con permisos diferentes leen la misma sesión del agente. filterTapeForAudience en tape-fold.ts filtra el transcript por viewer: si alguien sin permiso ve un tool call, el resultado se sustituye con un placeholder en vez de eliminarse. Eliminarlo corrompería la estructura del transcript.

Posturas de seguridad

• Strict: pausa cada tool call para aprobación humana.
• Auto (default): un classifier filtra datos externos antes de que lleguen al modelo.
• Dangerous: sin screening ni pausas (sigue aplicando command policy con denials hardcodeados).

Proxy de egress

QM envía un proxy autorizador standalone (egress-authz-main.ts) que bloquea ataques específicos:

• Endpoints de metadata cloud bloqueados: 169.254.169.254 (AWS), metadata.google.internal
• Tokens de capability firmados con JWS, no trust de red ambiente
• DNS rebinding cerrado: IP verificada después de resolución DNS
• Rangos link-local bloqueados: IPv4 169.254.0.0/16, IPv6 fe80::/10

Memoria: notebook de markdown, no vector store

La memoria de largo plazo en QM es un notebook de markdown de bullets atómicos, cada uno con fecha de captura, persistido en Postgres. Tres estrategias seleccionables:

• per-turn (default): extrae facts cuando los turns terminan.
• scratch-promote: buffer en scratch, promueve lo que sobrevive.
• agent-only: el agente escribe su propia memoria.

La consolidación es lo interesante: después de 10 bullets nuevos, un model pass corre sobre el notebook y devuelve acciones: UPDATE, DELETE, ADD o NONE. Prefiere UPDATE sobre DELETE+ADD cuando un fact evolucionó.

QM vs Hermes vs Claude Code

Dimensión	QM	Hermes / OpenClaw	Claude Code / Codex
Usuario principal	Empresa completa	Personal / power user	Developer en un repo
Scopes	Persona + canal, aislados	Usuario único	Sesión única
Admin + policy	First-class	DIY o ausente	Per-developer
Multiplayer	Nativo (tape filtering)	Emergente / limitado	Swarm / multi-session
Vendor lock	Pluggable (4 opciones)	Stack-specific	Tied to one harness
Licencia	MIT	Varía	Varía

Stack técnico

• Core: TypeScript en Node con Fastify para HTTP
• State: Postgres para sesiones, memoria, jobs y audit
• Slack: plugin in-process via Bolt
• Web UI: Vite + Lit (admin panel, portal público y web app opcionales)
• Deploy: Fly.io o AWS, qm init con org slug

Recepción y números

En tres días desde la publicación:

• 7,500 estrellas y 788 forks en GitHub
• 2.3 millones de views en el thread de anuncio
• 68 pull requests y 14 issues abiertos

¿Para quién es QM?

QM es software de organización, no una app de escritorio. El deploy asume una cuenta de cloud, Postgres y alguien cómodo con infraestructura. El fit ideal:

• Startup o empresa mediana de 10 a 500 personas
• Al menos un platform engineer
• Operando en Slack
• Quieren scopes privados + canales compartidos
• Pueden operar Postgres y Fly.io o AWS

Si eres una sola persona, Hermes o OpenClaw siguen siendo más simples. Si eres un equipo de 20+ across cuatro departamentos, el scope model de QM es lo que necesitas.

Limitaciones y caveats

YC lo describe como un experimento early con bugs. El threat model nombra sus propios gaps:

• La postura Strict puede pausar acciones, pero no puede reparar un comando unsafe generado después de que un humano lo aprueba.
• Auto screening reduce exposición, pero no puede probar que prompt injection esté contenido.
• Un workspace durable sube capability y retention risk juntos.
• Agregar un nuevo modelo requiere un nuevo adapter, no es un cambio de config.

Conclusión

QM es la respuesta open-source más creíble hasta la fecha a la pregunta "¿cómo dar agentes IA a toda una empresa?". YC ya probó que funciona en una organización conocida por hacer más con menos personas que casi nadie. La competencia real no son otros harnesses de agentes: son los vendors SaaS que cobran por seat por algo que una startup ahora puede self-hostear al costo de la infraestructura.

El código está en github.com/yc-software/qm bajo MIT. Antes de adoptarlo en producción, revisar SECURITY.md y alinear el threat model con tu sandbox, identity provider y retención de datos.