Connect to team memory

Share this page with a teammate — or paste it into another LLM's system prompt — to connect to BusyBro's global (team) memory: the shared, non-personal store of project knowledge that any teammate (and any connected LLM) can recall, and that any teammate can contribute to. The whole point is a single team brain that gets smarter as everyone uses it, with attribution and a review queue so nothing un-vetted becomes recallable.

This is the team store. Personal memory (what BusyBro learns about you) is owner-scoped and never shared — see Long-term memory for the full personal-vs-global model and the leak-proof privacy guarantees.

Connect

Team memory is reached over the MCP server — the same JSON-RPC tool surface Claude, Cursor, and any MCP client connect to. There is no token to paste: auth is browser OAuth on first use.

https://mcp.busymate.net/

• Auth — OAuth 2.1 (DCR + PKCE). The first call opens your browser → you sign in with your normal Busymate login → approve → the client gets a self-refreshing access token. No API key to manage. Full walkthrough + per-client config: Connect & authenticate.
• Each teammate uses their OWN dashboard account. Don't share a login or a token — every person connects with their own account so the team store correctly attributes who contributed what (see Who's the source). Multiple clients per account coexist and don't revoke each other.

Client config is the standard MCP one — no headers, OAuth runs in the browser on first use:

{ "mcpServers": { "busymate-net": { "type": "http", "url": "https://mcp.busymate.net/" } } }

Claude Code:

claude mcp add --transport http busymate-net https://mcp.busymate.net/

Roles you need

Team memory is gated by your RBAC role — an admin assigns it in the dashboard (Settings → Roles / Users):

A read-only teammate (users:view) can recall and browse but cannot change the store. Proposing a fact only ever writes a pending candidate — recall is unaffected until an operator approves it.

The agent protocol

So a connected LLM doesn't just have the tools but actively recalls at the start of a task and contributes durable findings at the end, give it this instruction. Paste it into the agent's CLAUDE.md, system prompt, or project rules:

## BusyMate team memory (busymate-net MCP)
 
You are connected to BusyMate's shared team-memory store. Use it actively:
 
- **RECALL — at the start of every task.** Call `list_global_memories` (optionally
  with a `query` substring or a `kind`/`status` filter) to pull the team's known
  project facts before you reason. Treat approved facts as ground truth about the
  project; prefer them over your own assumptions.
- **CONTRIBUTE — when you learn something durable and team-worthy.** Call
  `propose_global_memory` with a single **third-person, subject-less** project fact
  (≤ 600 chars). NO person, no first/second-person, no names / emails / IPs /
  hostnames / secrets — those are personal, not team facts. Your proposal lands as
  **pending** (never recalled) until an operator approves it in the review queue.
- Recall is free (`users:view`); proposing needs `users:edit` + `confirm: true`.

In short: RECALL via list_global_memories at task start; CONTRIBUTE via propose_global_memory → pending → an operator approves. Good team facts read like "the PAC port pool is 9000–9999" or "block rules live in settings_*.data.blockRules" — generalizable project truth, never anything tied to a person.

Note — auto-adoption: the MCP server now advertises this protocol in its initialize instructions, so a compliant client (e.g. Claude Code) adopts it automatically with no manual paste. If your client doesn't surface server instructions, paste the block above instead — it always works.

Who's the source

Every contribution is attributed to the contributing teammate's account — without ever putting a person into the recallable store.

• Two different things, don't confuse them:
  • origin is a coarse author class on each fact — busybro (self-train), claude-code (an LLM/Claude over MCP), or user (a human promote). It tells you what kind of client authored a fact, not who. (Over the raw MCP server every proposer currently collapses to claude-code.)
  • The contributor ledger is the per-person link: busybro_global_contributions records (memory_id, user_id, surface, source_thread), and the memory row's approved_by records who approved it. This is the only place a person is linked to a fact.
• Surfacing it — an operator with users:view reads list_memory_contributors(memory_id) to see exactly who proposed a team fact and who approved it (joined to each person's email / display name).
• Leak-proof by design — the contributor ledger is strictly off the recall path. The recallable store (busybro_global_memories) has no user_id column at all, and the recall function (match_global_memories) returns no identity. Contributor identity only ever appears on the explicit list_memory_contributors lookup — never in what an LLM recalls. The dashboard review queue likewise shows a candidate's contributor count, never identities. (The full three-layer leak-proof argument is in Long-term memory → Why a personal fact can't leak.)

Governance — propose → pending → approve

No single chat writes team truth directly. The lifecycle is a quarantine:

1. Propose — propose_global_memory (or "remember this for the team" through BusyBro) writes a pending candidate. It is not recallable.
2. Pending — the candidate sits in the review queue. Corroboration accrues automatically: the same fact independently proposed by N distinct contributors (default 2) can auto-promote.
3. Approve / reject / edit — an operator with users:edit resolves it. Approving makes it recallable to everyone; rejecting keeps it for audit/dedup but never recalls it; editing content re-embeds it.

Manage it all in the dashboard at Settings → BusyBro (Stats · Review queue · Manage tabs), or over MCP with list_global_memories / approve_global_memory / reject_global_memory / update_global_memory. The full model — the deterministic PII scrub, the corroboration math, origin scoping, and GDPR erasure — is documented on Long-term memory.

Next

• Long-term memory — the full personal-vs-global model, the leak-proof privacy guarantees, and the review-queue mechanics.
• Connect & authenticate — the OAuth 2.1 flow + per-client (Claude / Cursor / curl) config.
• Tool reference — the memory & governance tools and their exact gating.
• Roles & permissions — the users:view / users:edit capabilities an admin assigns.