Sharing

Working as a team

Keep your own work continuous, then add authorized members, shared scope, team-wide views, and controlled external sharing when collaboration calls for them.

Useful before you invite anyone

You do not need a team to benefit from a workspace. An individual can keep one project's decisions, lessons, runbooks, plans, media, and captured session state available across a laptop, desktop, fresh session, and supported editor. A personal handoff can move work between your own agents; a self-only capsule can preserve a checkpoint with no share link.

Collaboration adds authorized readers and contributors to that same model. It does not unlock a separate “real” version of ContextStream, and personal scope remains available after you invite people.

What sharing a workspace gets you

Shared decisions, lessons, documents, diagrams, plans, tickets, incidents, reviews, handoffs, and other workspace records can follow the project across supported assistants. A decision your colleague recorded on Tuesday can answer your question on Thursday—in whichever connected assistant you use.

The practical effect is smaller than "shared knowledge base" sounds and better: new people stop asking the questions that are already answered, and nobody re-litigates a choice made three months ago because nobody could find why.

Inviting people

From the dashboard: invite by email, they accept, they're in. Roles control who can administer the workspace and change billing. Owners and admins have full workspace access, members can read and contribute, and viewers are read-only.

Personal and shared

Not everything belongs to the team. The important distinction is the record's scope, not a rule that one kind is always personal and another always shared. A preference can be yours or a workspace convention. A todo can be private or part of shared work. A document can be a personal draft before it becomes the team's runbook.

On team plans, new transcripts default to personal unless they are explicitly shared. Personal transcript reads are restricted to their owner; shared workspace records still follow workspace and project access.

Use personal mode for work that should follow only you. Use team mode for authorized shared work. Automatic mode can choose from the current context, but it cannot turn a private record into a shared one.

Team-wide views

Authorized team views can collect:

  • tasks and todos;
  • documents and runbooks;
  • diagrams;
  • structured discussions;
  • transcript topics that are allowed to be shared.

These are views over the underlying records, not copied team versions. Editing a shared runbook updates the shared document; viewing team tasks does not duplicate them into a second backlog.

Projects can also be listed across the team, and workspace administrators can control multi-machine index settings. See Workspaces and projects.

Getting the boundary right

One workspace per group of people who should see each other's work — usually one per company. A second when there's a genuine wall: client work, a separate business unit, a regulated area.

Splitting further than that costs more than it saves. The whole value is that the person who needs an answer finds it.

Connected services keep their own permissions. Team mode does not let a member read a private GitHub repository, Slack channel, Notion page, Jira project, or Figma file their connected account cannot access.

What a new person should do first

  1. Join the workspace and connect their assistant.
  2. Ask "what have we decided about X" for the area they're joining.
  3. Read the runbooks — or better, ask a question and let the answer cite them.
  4. Check pending handoffs and the plans or tickets attached to the area.

That's a faster first week than any onboarding document, because it's their questions rather than someone's guess at their questions.

A focused first day in a real project

A new engineer joins the authentication project. Instead of handing them the entire workspace, start with the active project and let them ask:

  1. “What have we decided about token refresh and signing-key overlap?”
  2. “What lessons should I know before changing auth middleware?”
  3. “Show me the current auth runbooks and sequence diagrams.”
  4. “What tickets, risks, reviews, and handoffs are still open?”
  5. “Where is the refresh path implemented, and what depends on it?”

The answers can cite the current records and source. A pending handoff gives them a bounded first responsibility; a capsule can package the same area for their agent without granting access to unrelated projects.

Keep personal draft notes and transcripts personal until they are deliberately turned into a shared decision, lesson, document, or handoff. Joining the workspace should not make every thought someone captured during onboarding visible to everyone else.

Sharing outside the team

Don't add someone to the workspace for one conversation. Send a capsule — scoped, expiring, revocable.

For someone taking responsibility rather than merely reading, create a handoff and pair it with the capsule. The handoff records ownership and next steps; the capsule carries the selected context.

If it doesn't work

A teammate can't see what I recorded. Different workspace, or it was recorded in a personal scope. Ask each connected assistant which workspace and project it resolved before changing access.

Too much of other people's work surfaces. Several projects are sharing one project record. See Workspaces and projects.

Someone left and their sessions went with them. Sessions are personal by default. Anything that mattered should have been a decision, a document, or a capsule — that's what those are for.

Team search can see the project but not an integration result. The provider's own account permissions still apply. Check the member's connection and the source service, not only ContextStream membership.

A shared skill changes too much behavior. Retire or narrow it. Team skills apply a workspace convention through connected assistants and should have specific triggers.

Next