This AI Runs YC's Entire Company... And It's Free!

Y Combinator has open-sourced QM, its actual internal AI system, with the full codebase on GitHub under an MIT license, so any organization can inspect, run, or fork it. Instead of a typical personal assistant, QM gives every employee and room an isolated workspace with its own memory, files, permissions, and sandboxed execution, all managed under a single company-wide admin control plane to avoid the tangled context and permission issues of scaling assistants. The system is model-agnostic, supports multiple swappable harnesses, and includes unified search and a company brain for retrieving institutional knowledge. Its security model enforces a hard baseline policy, uses the user’s own credentials, and logs all actions, while candidly documenting limitations such as the command policy being only a speed bump, plaintext credential exposure, and broad admin visibility with indefinite data retention. YC already runs QM internally across accounting, legal, events, and engineering, making it a real, production-tested blueprint for deploying organization-wide AI agents.

• ▶ 0:00 Y Combinator open-sourced its actual internal AI system, not a demo or marketing pitch, with the full codebase on GitHub under an MIT license ▶ 0:17 — so anyone can inspect, run, or fork it.
• ▶ 0:25 QM is not a typical personal-assistant agent: instead, every employee and every room gets its own isolated workspace with separate memory, files, permissions, and sandboxed execution, all under one company-wide admin layer [1:00-1:26].
• ▶ 1:34 The video promises a deep dive into QM's architecture, real internal use cases, its security model and admitted limitations, and whether you can actually deploy it for your own company.
• ▶ 2:54 Personal-assistant AI agents break down when scaled company-wide: shared context becomes tangled, permissions get complicated, disconnected versions multiply, and there is no central oversight.
• ▶ 4:02 The reframe: give every person/room an isolated scope by default, but keep all scopes inside one shared system with a single admin control plane for policy, tools, and oversight.
• ▶ 4:57 This is not theoretical — Y Combinator runs QM internally across accounting, legal, events, and engineering, and even uses it to help build QM itself.
• ▶ 5:19 Scopes are the core concept: isolated workspaces for each person and each room/channel, each with its own memory, files, permissions, cron jobs, and sandbox environment — nothing bleeds between them by default.
• ▶ 6:31 Shared scopes ("rooms") give every Slack channel or project a single shared instance, history, and context, so the agent acts as a collaborative teammate rather than separate per-user assistants; sharing tools into rooms is deliberate while isolation remains the default.
• ▶ 8:13 The system is not tied to one AI engine: multiple swappable harnesses (Pi, OpenCode, Codex, Claude Code) plug into the same core, letting admins choose different harnesses/models per scope and avoiding vendor lock-in in a fast-moving space.
• ▶ 10:45 Unified search lets users query across email, documents, databases, and the web in one request, instead of checking multiple tools.
• ▶ 11:08 A "company brain" turns scattered institutional knowledge into a retrievable memory layer, so employees can get answers without pinging coworkers.
• ▶ 12:50 These use cases are real, actively running inside Y Combinator across accounting, legal, events, and engineering teams, not hypothetical examples.
• ▶ 13:40 The architecture centers on a headless core handling API, identity, policy, and scheduling, with durable Postgres storage for sessions, memory, and background jobs—so scopes retain context across conversations.
• ▶ 14:25 Every scope gets its own sandboxed environment with persistent files, tools, and services, described as the agent's "durable computer" that accumulates state between sessions.
• ▶ 15:52 The core remains generic while company-specific customization lives in a separate deployment directory; major substrates sit behind defined interfaces, so swapping pieces only requires changing a single wiring file.
• ▶ 16:49 QM uses a single organization-wide security posture as a hard ceiling; narrower scopes can tighten further but can never loosen below the baseline.
• ▶ 17:36 The default "Auto" posture uses a classifier to screen external data and tool results before they reach the model, and can be swapped for a custom screening proxy.
• ▶ 18:07 The "Dangerous" posture has no content screening and no pauses between tool calls, representing the maximum-autonomy end of the spectrum.
• ▶ 18:21 A predeclared command policy acts as a universal safety net underneath all three security postures, even the most permissive "dangerous" posture.
• ▶ 18:33 This baseline policy contains hard denials for dangerous actions, such as recursive delete commands and destructive SQL operations, which cannot be overridden.
• ▶ 18:47 Even in the least restrictive mode, this safety net remains active, ensuring there is always at least one layer blocking truly catastrophic actions.

• ▶ 18:51 QM’s security model prevents unrecoverable actions by reusing proven patterns from local developer tools rather than inventing a novel permission system.

• ▶ 18:54 The agent operates with the actual user’s credentials and permissions, not a separate elevated account, so every action stays scoped to the human’s access level.

• ▶ 19:09 All agent actions are logged for audit, creating a clear chronological trail of what happened, on whose behalf, and when—mirroring Claude Code, Codex, and Open Code.

• ▶ 19:26 Y Combinator's security documentation is unusually transparent, openly admitting QM's weaknesses rather than glossing over them.
• ▶ 20:06 The command policy is explicitly framed as a "speed bump against mistakes," not a true sandbox boundary—it can be bypassed via obfuscation, encoding, or indirect script execution.
• ▶ 20:21 A second documented limitation is that credentials sitting inside the sandbox can be exposed to active processes running within it.
• ▶ 20:25 Any credential in active use by a running process exists in plain text.
• [20:29–20:32] Encryption protects data at rest only, not credentials while being used by a live process.
• [20:34–20:39] If anything inside the sandbox is compromised while a credential is active, that credential is exposed.
• ▶ 20:41 The third documented limitation is that organization admins can read essentially everything: transcripts, documents, memory, and connector metadata.
• ▶ 20:55 Admin access is fully audited, but it is not separately gated behind any additional consent or approval step.
• ▶ 21:02 In practice, admins need no special permission beyond their existing role, so the system relies on audit logs rather than extra protection against admin visibility.
• ▶ 21:08 By default, durable data such as sessions, memory, and captured model requests has no expiration date and persists indefinitely.
• ▶ 21:26 Sensitive information from months or years ago can remain in the system with no automatic cleanup or lifecycle policy.
• ▶ 21:28 Organizations must proactively configure data retention policies; otherwise, historical data will be held indefinitely.
• ▶ 21:32 QM's fifth security limitation: published app links are core design constraints, not an oversight.
• ▶ 21:36 Published app links act as bearer tokens—the URL itself is the only credential, with no separate authentication step.
• ▶ 21:41 If a link is leaked or shared, there is no way to revoke access; the unintended recipient retains permanent access.
• ▶ 21:47 Once a QM copy is distributed, there is no way to revoke access for that specific copy individually—reinforcing that it's not meant for distributed or unattended deployments.
• ▶ 21:51 QM is explicitly designed for one trusted internal organization, not as a hardened public-facing system or for multi-tenant isolation between separate organizations.
• ▶ 22:09 The standout strength is transparency: Y Combinator plainly documents these security boundaries up front rather than letting users discover them after deployment.
• ▶ 22:22 Failure-related example sets up the practical takeaway.
• ▶ 22:24 Key question: can you actually stand up QM for your own company.
• ▶ 22:33 Y Combinator designed the deployment path, making the process intentionally accessible.
• ▶ 22:34 QM doesn't require cloning the entire repo—a single initialization command materializes a full deployment directory (for an org slug, on Fly.io or AWS) that automates setup, sign-in, Slack wiring, deployment, and live verification checks.
• ▶ 24:20 The realistic fit: QM suits startups or midsize companies with at least one platform engineer comfortable managing cloud infrastructure and Postgres—it is not for non-technical teams, and enterprises should review the security posture before production use.
• ▶ 25:50 QM is genuinely capable but still early software: YC openly describes it as "bugs and all," and it demands real infrastructure commitment (cloud accounts, Postgres, and someone able to manage the deployment), so treat it as serious early-stage infrastructure.

• ▶ 0:00 Introduction: YC Open-Sources QM (0:00 - 2:28) - - Introduces QM, why it differs from typical AI agents, and the video roadmap.
• ▶ 2:28 Why QM Started With a Reframe (2:28 - 5:19) - - Covers the scaling limits of personal-assistant AI, the scattered-agent problem, and the Quartermaster name.
• ▶ 5:19 Scopes and Multi-Surface Design (5:19 - 10:32) - - Explains QM's core scope concept, personal vs shared scopes, persistent identity, and swappable harnesses.
• ▶ 10:32 Real Use Cases Inside a Company (10:32 - 13:31) - - Details unified search, company memory, inbox management, engineering workflows, and project tracking.
• ▶ 13:31 Technical Architecture (13:31 - 16:42) - - Breaks down the headless core, Postgres, per-scope sandbox, plugin architecture, and company-specific customization.
• ▶ 16:42 Security and Deployment Model (16:42 - 22:36) - - Covers security posture, documented limitations, intended deployment, and the question of self-hosting QM.
• ▶ 22:36 Deployment Setup and Realistic Takeaway (22:36 - 26:34) - - Shows how to initialize QM, identifies who it fits, and wraps up with strengths, limits, and closing CTA.