Scopes
Every resource in Ren (agents, skills, MCPs, vaults, file stores, memory stores, projects, pods, blueprints) has a scope that controls who can see it and reference it.
The three scopes
- Private: belongs to one user. Only that user can see or use it. Good for personal experiments and drafts.
- Org: belongs to the organization. Every member can see and use it. This is the default and the workhorse of team collaboration.
- Registry (public): published to the registry and usable by anyone, in any organization.
Owning vs. referencing
Scope governs two different things:
- Owning: modifying, archiving, or deleting a resource. You can own org resources in your org and your own private resources, but never another user’s private resources.
- Referencing: using a resource from your own, like attaching a skill to an agent or installing a blueprint. Anyone can reference a published (registry) resource. Otherwise you can only reference what you could own.
Scope can only narrow
References can narrow scope through a dependency graph, never widen it. An org-scoped agent can reference org and registry skills, but not another user’s private skill. This means you can’t make a private resource reachable by attaching it to something more public. If a skill is invisible to your teammates, an org agent can’t bridge access to it.
What can be published
| Resource | Default scope | Can be published? |
|---|---|---|
| Agents | Org | Yes |
| Skills | Org | Yes |
| MCPs | Org | Yes |
| Blueprints | Org | Yes |
| Replays | Org | Yes |
| Vaults | Org | No |
| File stores | Org | No |
| Memory stores | Org | No |
| Projects | Org | No |
| Pods | Org | No |
Secrets, storage, and compute (vaults, stores, projects, pods) can’t be published. They stay private or org-scoped permanently.
Where to go next
- Registry: how publishing moves a resource from org to public scope.
- Permissions: what an agent can do once it can reference a resource.
- Blueprints: packaged setups that install across scopes.