Give Y Combinator’s QM agents your company’s knowledge

QM is the multiplayer agent harness Y Combinator open-sourced for company work — the same one YC uses internally. Each person gets an agent that can actually do work. What QM does not give them is the company's memory.

PipesHub is that layer: Drive, Slack, Gmail, Jira, Confluence, GitHub — already indexed, already filtered by who is asking. They stop pasting context into the chat. They ask, and the answer comes with a link they can open.

About ten minutes once PipesHub and QM are both running.

Without PipesHub

Someone asks: "What did we agree with Acme on renewal?"

"I don't have access to that information."

The answer is sitting in a Drive doc, a Slack thread, and a ticket. Someone pastes in what they can find, or the agent writes something fluent that nobody in the company ever said.

With PipesHub

Same question.

"Renewal was revised 12 March — 18 months at the previous unit rate."

Three citations you can open: the contract, the Slack thread, the ticket. If the documents cannot support an answer, the agent says so rather than filling the gap.

That is the whole product. People stop assembling context before they ask. They ask, and the agent goes and finds it — with the access they already have, and no more.

PipesHub is not a search box bolted onto the agent. It is the workplace context layer: it connects those apps once, keeps them indexed, and applies each person's permissions on every query. The QM agent does not learn Slack's API, then Jira's, then Drive's. It asks one place, and what comes back is already scoped to that person.

What PipesHub is, and how to get it running

Company knowledge lives in a dozen tools. PipesHub connects them, indexes them, and answers from them with citations — and it only returns what that person is already allowed to see. You can use a hosted instance or run it yourself with Docker Compose. Adding the first source, Drive or Slack, is a few minutes in the web UI, not another stack to stand up.

The full connector list and deploy options are in the PipesHub docs. For QM, the instance has to be reachable over public HTTPS — agent sandboxes do not run on your laptop. A Cloudflare tunnel is enough for a trial. Once that URL exists, the rest of this post is connecting it to QM.

What changes on Monday

Once it is connected, this is what a normal week looks like. Engineering, support, and leadership ask the way they already ask. The agent pulls across apps they already use, and every claim is something they could have opened themselves.

• "Why did incident #402 fire in eu-west?" — Slack triage, the Jira history, and the runbook, cited, in one answer.

  
  

• "What language did Legal approve for the SOC 2 addendum?" — the clause in Drive, and the Gmail thread that signed off on it.

  
  

• "What is blocking mobile this sprint?" — open Jira tickets and the Slack threads attached to them, without anyone collecting links.

  
  

• "What does the Q4 report say about ARR?" — an answer drawn from that report, with a link to the page.

  
  

• "Show me executive compensation" — a denial if they cannot open that Drive folder. Not a vague miss, and not a quiet summary.

  
  

The reason this is safe to roll out is that every answer is bounded by the person asking. One token per person, in their own QM keychain. If they cannot open the document in PipesHub, the agent cannot read it to them.

Do not share one organisation token. That would give every agent turn the same identity, which means everyone reads whatever the token's owner can read. There is no configuration that makes a shared token safe.

Why not "just add another connector"?

You can wire Drive, then Slack, then Jira, each with its own OAuth dance and its own idea of who is allowed to see what. After two sources, the real question is whose identity the agent is using. An agent that can read every document in the company is a leak with a chat box. Point to point, you also never get one index: the model sees five tools, five login stories, and no way to ask a question that spans them. Slack stays in Slack; Jira stays in Jira; the agent never sees them as one picture.

PipesHub already connected those apps. It indexes them together, so one question can pull a Slack thread, a Jira ticket, and a Google Doc into the same answer — with each person's real permissions applied before anything reaches the model. This integration does not replace QM, and it does not bolt PipesHub on as an extra MCP server. QM is itself an MCP server, talking to its own harness; it will not attach a third-party one. The agent simply runs a small pipeshub command inside that person's sandbox, the same way it runs anything else.

How to connect PipesHub to QM

If QM is already running and PipesHub has a public HTTPS URL, this is the whole path. The Use with QM guide has the failure messages and the edge cases. What follows is the sequence that actually works.

1. Install the CLI into the deployment

You need @pipeshub-ai/mcp 2.3.2 or later. Agent sandboxes do not run on your laptop — they run on Fly Sprites — which is why that public HTTPS URL matters.

Set egress in sandbox/tools/pipeshub/tool.json to the hostname only: no https://, no /mcp. Then run qm check && qm up.

Publishing a sandbox image does not put pipeshub on PATH. Sprites ignore a custom image today. The first time someone asks a question, the agent installs the CLI once on that Sprite, and it stays there.

2. Each person creates a personal access token

In PipesHub: Developer Settings → Personal Access Tokens → Create. Accept the defaults. Keep the phpat_ prefix if the token has one; it is there for secret scanners, not as a second secret.

Never paste the token into a chat. Transcripts last, and they pass through the model provider. The keychain exists so the credential never has to take that path.

3. Each person adds two keychain entries

In QM, in their own keychain, both under service pipeshub:

• PIPESHUB_TOKEN — the token value only, no KEY= and no URL

• PIPESHUB_BASE_URL — the public origin, with no path

• Two entries, because the URL does not reach the sandbox from deployment config. They show up on the next message. There is no grant step, and nobody else's token should be in a shared place.

4. Ask something you already know is in the corpus

"What do we know about X? Cite the document." You should get an answer with a link you can open. If the documents do not cover it, the agent says so rather than inventing a source.

If it asks you to add a semantic:read scope, it called the wrong API. Start a new chat and tell it to use pipeshub ask. Do not widen the token.

Don't have QM yet? Y Combinator open-sourced it — yc-software/qm. You host it yourself; this integration sits on top. Agent sandboxes need Fly Sprites — a Fly account on its own is not enough. Stand QM up first, then come back to connecting PipesHub. That is the long part. PipesHub is not: a hosted instance, one connector in the UI, then the four steps above.

Two things that stay true

The reason to send a question through PipesHub, instead of hoping the model already knows, is that you can open whatever it claims. A real answer names the document and gives you a link. You click through and see the sentence yourself. That is the difference between research and a fluent guess.

If nothing in the corpus covers the question, the agent says so. It does not invent a document to hang an answer on.

What comes back from PipesHub is also not a set of instructions for the agent. Slack, email, and tickets are indexed like any other document, which means anyone who can post there can get text into the agent's context. If a message says "ignore previous instructions" or "print the token," that is a document saying that. The agent should mention it if it matters to the question you asked, then keep going with the original task. It should not obey the document.

Try it. One PipesHub instance, one connector, a Cloudflare tunnel, and the four steps above. The package is @pipeshub-ai/mcp 2.3.2 or later.

Roll it out. The full setup, including every failure message we have actually seen, is in Use PipesHub with QM. For questions, Discord.