Shared context

Everything an assistant accumulates — knowledge and playbooks, skills, tasks, data tables and dashboards, credentials — lives in a memory pool. Teams exist so that pool doesn’t have to be all-or-nothing: every piece of context is either personal (belonging to one assistant) or shared in a team (accessible to every current member). One deliberate exception up front: team assistants have no personal scope at all — their owning team’s pool is their memory. Everything below about choosing between personal and team applies to T-W1Ns and personally-supervised assistants; a team assistant simply defaults to its owning team and can additionally write into other teams it belongs to.

​

The two scopes

Nearly everything can take either scope:

​

How assistants choose a scope

You don’t file anything manually — assistants route content as they work, under strict rules:

• Personal is the default. Anything private, ambiguous, or individual-flavored stays personal.
• Team only when it clearly belongs. Each team has a name and description; content goes to a team pool only when it plainly matches that team’s domain.
• When unsure, they ask. “Should this go in the Repairs team’s shared pool, or keep it just between us?” — a brief question rather than a guess toward the wider audience.
• Credentials get extra caution. Sharing a credential is harder to undo than sharing it later, so the bar for putting one in a team pool is highest of all.

You can always direct scope explicitly: “save this as team guidance for the repairs team”, “keep that analysis personal”.

​

How shared context gets used

Here’s the payoff. Whenever an assistant works, it draws on its personal memory plus every team it belongs to — searching for relevant playbooks, skills, knowledge, and credentials across all of them at once:

• A new member’s T-W1N can follow the team SOP on day one, because the playbook lives in the team pool, not in a veteran’s head.
• The expense workflow that one assistant learned last month runs identically for everyone on the team.
• The team dashboard is fed by team data tables that any member’s assistant can update.

Writing is the disciplined side: each saved item goes to exactly one scope — personal or one named team — never sprayed across pools.

​

The controls that make sharing safe

This design deliberately avoids “everything visible to everyone in the org”:

• Team pools are invisible to non-members. An assistant that isn’t on the finance team cannot see finance’s knowledge, data, or credentials — they don’t appear in its searches at all.
• Membership is current-members-only. Remove someone and their access ends immediately; the content stays for the rest of the team.
• There is no org-wide memory view. Nobody — including admins — has a single pane showing every assistant’s memory. Reviewing a team’s shared pool means being on that team; reviewing an assistant’s personal memory means being its owner.
• Sensitive stays scoped. Elevated-access credentials, division-specific data, confidential procedures — put them in the narrowest team that needs them, and that’s exactly how far they reach.

​

Seeing scopes in the Console

Every brain pane on an assistant — Contacts, Transcripts, Knowledge, Functions, Guidance, Tasks, Data, Dashboards — carries scope chips:

• All (the default) — the exact merged picture the assistant itself works from: its personal pool plus every team it belongs to, combined into one correctly-ordered view. Merged entries show which scope they came from, and in Transcripts each thread is labeled with its team.
• Personal — just its private memory.
• One chip per team — just that team’s shared pool.

The complementary view is the team itself: selecting a team in the sidebar shows every one of those sections scoped to the team’s pool — the same data any member’s assistant sees when it reads that team, without going through any individual assistant.