Skip to main content
Before you open the platform to teams, you decide how to structure it. This is the question most organizations hesitate on: a single organization with groups, or several organizations?
One org with groups gives a shared catalog, asset reuse, groups for members and permissions, and lighter administration. Multiple organizations give hard isolation of data, quotas, billing, and models, per-subsidiary compliance, and independent catalogs. Choose multiple orgs only for hard separation.

​
How to decide

One org + groups

Keep a shared foundation. Groups organize members and permissions, and membership rules auto-assign roles as people join. Best when teams collaborate and reuse each other’s assets.

Multiple organizations

Separate everything: data, quotas, billing, and available models. Best for subsidiaries or business units with their own compliance perimeter and no cross-sharing.
Decide on a few concrete criteria:
  • Data segregation: must data never cross a boundary? That points to multiple orgs.
  • Billing and chargeback: do you need fully separate cost attribution? Multiple orgs make it clean.
  • Compliance perimeter: different regulatory scopes per entity? Multiple orgs.
  • Reuse and collaboration: do teams share agents, skills, and tools? One org with groups keeps that simple.
Recommendation: choose multiple organizations only when you need hard separation of data, billing, or compliance. Otherwise, one organization with groups keeps reuse and administration simple. The two levels of governance (central and per-org) apply either way, see Governe.

​
Next steps

Who does what

The teams and rights per level

Opening strategies

Open to all or curate, without chaos