← Back to docs

Recipe

Team workspace design

A Meridian team workspace is a shared scope for prompts, evals, datasets, and routing rules. This recipe walks through the building blocks needed to stand up a workspace that scales from two engineers to a 50-person org without rebuilding the IAM model on day 90.

1. Pick a tenancy boundary

One workspace per product line beats one workspace per team. Teams rotate, products persist. Use sub-folders inside the workspace for team scoping, and bind keys at the folder level so a sunset team doesn't strand its prompts.

  • One workspace = one billing root
  • One folder = one team or initiative
  • Keys + budgets attach to folders, not users

2. Map roles to real verbs

Meridian ships four built-in roles. Map them to the verbs your team actually performs, not to seniority. A staff engineer who never edits prompts is a Viewer, not an Editor.

Owner   -> billing, key rotation, delete workspace
Admin   -> add members, set budgets, publish routes
Editor  -> author prompts, run evals, ship versions
Viewer  -> read prompts, view traces, no mutations

3. Wire budgets before invites

Configure per-folder monthly caps, alert thresholds at 50/80/100 percent, and a hard-stop policy before you invite the first non-owner. A workspace that can run unbounded spend on day one will run unbounded spend on day thirty.

Tip

Set the workspace-level cap to 1.2x the sum of folder caps. The 20 percent buffer absorbs spikes without freezing production traffic mid-incident.