Here is a scene I keep seeing with founders I mentor.
You finally have a Company OS. You can answer "where are we?" in two minutes. Your research has clear stop points. Fake user scores do not get to declare victory. Then Y Combinator open-sources something called QM, headlines call it a company operating system, and a thought pops up: should I throw my process out and install theirs?
Short answer: no.
Longer answer is this article.
This is the third piece in the Company OS series. Start with how to see exactly where your startup stands, then how research actually runs. This one answers: when do we add a shared AI setup for a team, and what do we keep?
The confusion YC just made useful
In late July 2026, Y Combinator open-sourced QM (short for quartermaster). It is the multi-agent setup they use inside YC for accounting, legal, events, and engineering. The code is free on GitHub under MIT. Real software for real company work.
Calling it "a company operating system" is sticky marketing. It is also incomplete.
QM is great at running day-to-day work with AI agents for a whole company. The Solo Founder Company OS is great at deciding what is true while you are still proving a business.
Mix those jobs up and you get one of two messes:
- You spend weeks wiring team AI tools while the idea is still fog.
- You stay on chat logs forever and hope teamwork "just happens" after you hire.
You do not graduate from good judgment. You grow into team tools when people and workload make that real.
Two jobs (keep them separate)
Think in jobs, not brand names. Company OS and QM are not fighting for the same seat.
Judgment system
Your idea, phases, evidence, scores, and decisions only you can make
Shared team AI setup
Workspaces, Slack/web, safe agent computers, scheduled jobs, admin rules
Personal coding tools
Claude Code, OpenCode, Codex, and similar day-to-day helpers
Golden rule: steal the process from the portable Company OS template. Do not copy another founder's market. Treat QM as optional later, not a reason to skip talking to customers.
Portable template: docs/company-os/ in the Totbox open repo, especially operating-system.md and live-runtime.md.
What the Solo Founder Company OS is for (early stage)
If the first article was a blur, here is the plain version:
- Two clocks. A slow path (prove the business) and a fast weekly loop (learn this week).
- Founder gates. You choose: move forward, try again, wait, or stop. AI can advise. You decide.
- Evidence beats story. Pretend users are a filter. Real people acting is the real test.
- Label what you know. Outside facts, signals from your work, guesses, and things that still need real-world proof.
- Status board. "Where are we?" in under two minutes.
- Build with tests. Write what "good" means, then build a thin slice, then check.
It is a mentorship blueprint for independent founders with limited time and money. Solo is smart at the start because you can move at AI speed without waiting for a committee. It is not a religion that you must stay alone forever.
In startup slang this early stretch is often called 0 to 1: proving the idea before you scale people and process.
What YC QM actually is (growing team)
Personal and shared workspaces
Your agent and the channel's agent without overwriting each other
Slack and web
Same identity and settings on both
Pluggable coding tools
Pi, OpenCode, Codex, Claude Code can drive one core
Safe computers and scheduled jobs
Durable agent machines and work that runs unattended
Shared playbooks and permissions
Share skills and control who may use or promote them
Safety levels
Strict / Auto / Dangerous, plus hard command bans
Free license (MIT), cloud-first, install into your Fly or AWS account. YC says it is early and experimental. Used for real at YC, not a finished product for every startup on day one.
What QM is not: a replacement for talking to customers; proof that people want your product; free AI bills; or required day-one kit for every solo founder. If you only need a personal helper on chat or terminal, a simpler personal tool may be enough. QM's point is company install: shared projects, shared rules, multi-person memory.
In the same slang, this later stretch is 1 to n: many people, many agents, real load.
When you are early vs when the team grows
Solo Company OS
Decide what is true. Stay small. Prove value with almost no team or money.
- Two clocks and founder gates
- Label what you know vs guess
- Thin product slice with clear tests
- One main AI and scripts are enough
Plus shared team AI
Same judgment rules. Add a multi-person AI setup when people start stepping on each other.
- Separate workspaces per person or channel
- Slack / web plus safe agent computers
- Scheduled jobs, playbooks, admin rules
- Integrate. Do not delete the OS.
Upgrade does not mean throw the OS away
You do not outgrow labeling what you know, human stop rules, honest scoreboards, or "where are we?" Those get more important with money and headcount. Politics and vanity metrics grow with the team.
Integrate. Do not replace.
Wrong mental model
"We adopted QM, so we can drop phases, scoreboards, and stop rules. Agents will figure it out."
Right mental model
"Judgment rules stay the source of truth. The team tool runs day-to-day work. Journey advances still need a human gate."
Early: Company OS (rules + status + loop) + one AI / scripts / product Growing team: Same judgment rules + shared team AI setup (QM…)
Real trigger: people getting in each other's way
Funding, revenue, and headcount are rough stand-ins. The real switch is whether a shared team AI setup reduces pain more than it adds install and admin work.
Some founders call that pain coordination tax: the cost of people and agents stepping on each other.
- ·One person still holds the loop in their head or a status file
- ·Work is stop-and-start and you still approve big moves
- ·Research and build fit notes, scripts, one main AI
- ·Thin product loop with real users not closed yet
- Multiple people need separate AI workspaces
- A shared channel needs a lasting project agent
- Background jobs are real weekly work
- Ops and eng want one place for rules and audits
Bad pattern: raise money and spend the first month wiring cloud and Slack agents while you still have no real customer proof. That is busy automation with nicer branding.
Side-by-side in plain words
| Dimension | Solo Company OS | YC QM |
|---|---|---|
| Primary user | Solo / tiny team proving a business | Multi-person startup / company ops |
| Core artifact | Phases, scores, decision notes | Sessions, workspaces, playbooks |
| “Where are we?” | Journey + weekly loop + open questions | Session history + admin + channels |
| Human control | You decide strategy and high stakes | Safety levels + command rules |
| Cost shape | Notes, git, optional AI tools | Cloud + models + connectors |
| Misuse failure | Pretty plans, no proof | Busy agents, no truth |
How to transition (a practical path)
Step 0. Finish early-stage honesty first
Before any shared team AI setup:
- Written thesis (a guess you will test, not gospel)
- Ranked customer groups with labels on what you know vs guess
- Real interest or real usage, not only synthetic "I would buy"
- Thin product slice with clear pass/fail rules
- At least one real feedback cycle written back into your notes
If you cannot fill the status board in two minutes, you do not need QM yet. You need the first article's OS.
Step 1. Name the coordination pain
Write three bullets only:
- Who else needs an agent besides me?
- What work is already multi-person or runs without anyone watching?
- What breaks if two people share one agent workspace?
If the bullets are empty, stay put.
Step 2. Map how much AI may do alone
How much may AI do alone?
Even before you install QM, map how much the system may do without asking you. Same idea as a product "dry run first" default.
Strict
External send, spend, and journey advance wait for your OK.
Auto
Drafts and internal research run. High-stakes actions still wait for you.
Dangerous
Almost never early. No screening, no pauses. Skip this for mentees.
Step 3. Time-boxed pilot (if the pain is real)
W0
Strict safety · 1 admin · at most 2 users
Sign-in works; secrets not pasted in chat
W1
One shared project channel or one personal scheduled job
Useful updates without credential leaks
W2
One shared playbook or internal tool with clear permissions
Non-admins cannot raise the safety level
Park it if it fails: if install cost exceeds weekly benefit after two weeks, park the tool and keep the Company OS loop. Come back when the pain is undeniable.
Step 4. Integrate. Do not replace.
Put judgment notes where both humans and agents can read them:
- Thesis, open questions, scoreboard, and decision notes stay in your company docs (git or equivalent)
- QM (or a similar tool) runs day-to-day work against that brain
- Journey advances still need a human gate. Never a silent agent.
Optional later: package your research workflow as a shared playbook with founder gates in the instructions. Same discipline as the research article, on a multi-person surface.
What not to do
- Replace "is this true?" with "we have agents in Slack"
- Let the tool auto-advance your journey phase because a task finished
- Import untrusted playbooks without review
- Run Dangerous mode to "move faster" on customer data
- Copy a big org chart as your virtual office before you have outputs
- Skip real customer proof because a team AI setup looks like traction
How this fits the series
How to See Exactly Where Your Startup Stands
Blueprint: two clocks, gates, status board
How Your Company OS Actually Runs Research
How to run research without letting AI declare victory
From Solo Company OS to YC QM
When judgment meets a shared team AI setup
The Totbox open repo remains the portable template plus one live example. Steal discipline, not someone else's market. QM is third-party open source from YC. Judge it on your coordination pain, not on star count.
One-page thesis for your notes
Company OS is how a solo founder refuses to lie about evidence while building. QM is how a growing team runs fleets of agents at work. You stack them when people start stepping on each other. You do not swap judgment for tools.
FAQ
Is QM competing with the Company OS?
Mostly no. Different jobs. The "company OS" brand can collide in headlines. In practice they stack.
I'm solo with early revenue. Do I need QM?
Only if multi-person or unattended agent work is already a weekly pain. Otherwise stay lean.
Can I run Company OS inside QM?
Yes in spirit: playbooks, scheduled jobs, and shared memory that hold your scoreboard and gate rules. The rules still live as your policy, not as "the agent felt like advancing."
Should non-technical founders deploy QM on day one?
Usually no. Day one is thesis, research, and tiny honest tests. Day multiplayer is after people and load show up.
Next actions
- Fill this week's status board (journey, loop, gate, open questions).
- Write whether coordination pain is real today (three bullets).
- If no: finish one real feedback cycle before any team-AI pilot.
- If yes: Strict two-week pilot with a kill date.
- Write a short decision note: adopt / park / revisit.
AI tools change fast. Principles last longer. Goal: help founders use AI speed without confusing team infrastructure for proof that people want the product.