Y Combinator has open sourced QM, the multi agent harness it built to run its own legal, engineering, and accounting work.

It is a capable tool and a louder signal. Multiplayer agent infrastructure is becoming something you download rather than something you build, and that shifts where the hard work sits for anyone running agents against a Salesforce org.

What Y Combinator actually shipped

QM lets several people work with the same agents inside Slack and on the web. Each user gets their own files, permissions, and memory. Background crons and webhooks keep agents working when nobody is online, which is the part most single user assistants never solve.

• Self hosted, so your org controls the infrastructure end to end.

• Model agnostic, running against Codex, Gemini, DeepSeek, Kimi, or local models.

• Built for team wide collaboration rather than one person and a chat window.

How it compares to Claude Tag

QM sits in the same category as Anthropic's Claude Tag. Both surface agents in Slack, and both support several humans working with one agent at once.

The difference is control. Claude Tag is hosted by Anthropic and tied to Anthropic's models. QM hands you the keys. You host it, you choose the model, and you own the uptime. That trade is worth making for some teams and not for others, and the deciding factor is rarely the feature list. It is whether you have someone whose job it is to keep the thing running at two in the morning.

The missing piece for Salesforce teams

QM ships with no native Salesforce connector. If you want it working with CRM data you are building that integration yourself, most likely leaning on Salesforce's MCP tools to bridge the gap.

That is not a small lift, and it puts the burden of getting Salesforce access right entirely on your team.

• No out of the box connection to Salesforce objects or data.

• Custom MCP work required to bridge the harness and your org.

• Full responsibility for hosting, upgrades, and uptime sits with you.

Why permissions are the real risk

The moment an agent can touch Salesforce data, your existing permission model has to hold on its own.

A self built connector that skips field level security or role hierarchy checks can quietly grant an agent more access than any human user has. Nothing errors. The responses come back fluent and complete, assembled from records the requesting user was never entitled to see, and they read exactly like correct answers.

This is the failure mode we see most often when teams move quickly on agent integrations without governance designed in from the start. It is also the one that surfaces last, usually during an audit rather than during testing, which is the worst possible time to find it.

Open source gives you a foundation, not a finished product

Tools like QM prove that multiplayer agent harnesses are becoming commodity infrastructure. That is genuinely good news. It removes months of undifferentiated work and lets teams start from a running system rather than an empty repository.

What it does not remove is the unglamorous part, and the unglamorous part is what separates a working prototype from something that survives contact with a real org.

• Governance has to be designed in, not added after an incident.

• Audit trails matter as much as task completion.

• Salesforce aware context requires real integration work, not a plugin.

The short version

The harness is becoming free. The trust layer is not.

Every agent we build for a Salesforce org gets evidence logging and QA from the first commit, because that is where trust is actually earned. Open source tools like QM lower the barrier to entry. They do not lower the standard you are judged against once the agent is writing to production, and that standard is set by your auditors rather than by your roadmap.