Shared versus project scope

Decide whether a fact, rule, or named action belongs to a single Project or to the wider workspace. The right scope keeps context relevant where it is used and out of the way where it would be noise.

Audience: builders

The two scopes

Every piece of authored context lives in one of two places.

• Project scope. Authored on a Project's Context tab. Available only to that Project's conversations, Tasks, and Apps. Use this for context tied to one workflow.
• Shared scope. Authored in the Shared Context section in the left nav. Available to every Project, App, and Data Collection that the scope reaches. Shared scope has two sub-scopes:
  • Team. Visible to the active team only.
  • Workspace. Visible to every team in the tenant.

The platform uses the same authoring patterns at both levels: memories, verified logic, and skills each carry the same live and pending-review states. The only difference is who can see and approve them.

Pick a scope

A short heuristic gets you most of the way:

• One workflow uses it. Keep it in the Project. Naming conventions for a single AP queue, a Project-only prompt rule, or a sample document set all stay scoped.
• One team shares it. Lift it to Team. The AP team's vendor abbreviation list, the credit memo procedure your AP analysts all run, the cadence the AP team agreed on.
• The whole company refers to it this way. Lift it to Workspace. The legal entity table, the corporate close calendar, the brand voice rules, the named queries every team reuses.

Two more checks before you lift:

• Will the next Project benefit? If yes, lift. If you are guessing, leave it in the Project until a second Project actually needs it.
• Could leaking this confuse the agent in another workflow? If yes, keep it Project-scoped. A rule that helps AP triage can hurt AR triage.

Move context between scopes

The product surfaces are deliberate about which scope an entry lives in. Today, moving a piece of context across scopes is a copy, not a transfer:

• Project memory to shared. Author the memory in Shared Context > Memories in the target scope, then delete the Project-level entry. The shared row is now the source of truth.
• Shared memory to project. Author the Project-level memory on the Project's Context tab. Retire the shared entry if no other Project relied on it.
• Project verified logic to shared. Scaffold a new entry in Shared Context > Verified logic, port the package contents, and archive the Project-level entry once the shared version is live.

The audit trail follows the data

Each scope writes to the same workspace audit ledger. Filter /audit by the actor or the entry name. When you copy a Project memory into shared and retire the original, the ledger captures both the new author event and the retire. That is the receipt your controllers will ask for.

The memory ladder

Most teams find their context settles into a ladder over the first few weeks of a workflow:

1. Project memory. A correction, a naming rule, a one-off fact lands here first. Cheap to write, cheap to revise.
2. Shared memory (team or workspace). Once two or more Projects benefit, lift to shared. Memories at this rung are still revisable; reviewers approve changes.
3. Verified logic. When a rule has stabilized enough that the agent should act on it consistently and a controller wants the receipt, encode it as a verified rule or action. Reviewers approve, executions are logged, and supersession is explicit.

The ladder is one of the patterns in Build patterns. Use it to guide where each piece of new context should land, and to know when to lift something up a rung.