Skip to main content
A team is an agent grouping primitive within an organization. Teams are optional: an agent may belong to zero, one, or many teams. Solo agents — agents in zero teams — compose under Platform → Org → Agent, the existing 3-layer shape. Teamed agents compose under Platform → Org → {Team, …} → Agent. This page documents the team-scope model: why it exists, how it interacts with the composition cascade, and how to manage team-scope alignment + protection templates.

​
Why team scope exists

The Mnemom safe house composes governance state by layering scopes: platform-wide defaults at the top, organization-level templates below them, and agent-specific cards at the leaf. The platform is the most permissive ceiling; each layer down can only tighten — strictest-wins. For organizations with heterogeneous agent populations, the org-level template is too coarse. A bank’s customer-service agents and its internal devops agents have different risk profiles, different bounded actions, different forbidden tools, different audit retention needs. Two compromises were possible: (1) write the org template strict enough for the strictest sub-population (over-restrictive for everyone else), or (2) carry per-agent overrides on every agent (high friction, no shared baseline). Team scope is the missing middle. Org admins set the org-wide floor. Team admins refine within the org’s permissions for each team. Agents in a team inherit the team’s contributions on top of the org floor. Solo agents that don’t belong to a team simply don’t pick up the team layer — their cascade is unchanged.

​
When team scope applies

There is no auto-created default team. Teams are an explicit org-admin construct. If a customer-shaped need for “agents auto-land in a specific team” arises, that lands as an opt-in default_team_id setting on the org — additive, not breaking.

​
The four-layer cascade (when applicable)

For an agent that belongs to one or more teams, the composer reads four scope sets:
  1. Platform defaults — set by Mnemom (the safe-house operator). Compliance ceiling.
  2. Org template — set by org admin (/v1/orgs/:org_id/{alignment,protection}-template). Tightens platform.
  3. Team template(s) — set per team (/v1/teams/:team_id/{alignment,protection}-template). Tightens org for the team’s agents.
  4. Agent card — the agent’s own self-declaration. Tightens whatever the team(s) and org allow.
For each field on the canonical card, the composition rule applies across every layer present: The fold is variadic: the same rules apply with 0, 1, or N teams. Solo agents reduce naturally to the 3-layer cascade with no team contribution.

​
Multi-team agents

An agent can be a member of multiple teams within its org. The composer aggregates contributions from all teams the agent belongs to via strictest-wins per field. If an agent is in team:platform and team:sre, and platform sets autonomy_mode: nudge while sre sets autonomy_mode: enforce, the strictest (enforce) wins. This is a v1 simplification consistent with Mnemom’s existing strictest-wins idiom. Future v2 refinement (named-priority precedence — “team A wins over team B for this field”) is on the roadmap if customer signal materializes.

​
Team templates vs. team identity cards

Mnemom has two separate concepts that both reference a team:
  • Team-scope templates (this page) — written to teams.card_template and teams.protection_template. Applied to every member agent’s composition cascade. Read by the composer; never visible on the wire as a “team’s card.”
  • Team identity cards (see Team Reputation) — a single representative card auto-derived from the team’s member cards via POST /v1/teams/:id/card/derive. Stored in alignment_cards.team_id. Used for fleet-coherence analysis and team-reputation scoring; not applied to member agents’ cascades.
The two surfaces are orthogonal. Setting a team-scope template doesn’t touch the team identity card; deriving a team identity card doesn’t touch the templates. Most customers will only need team-scope templates (the cascade-applying surface); team identity cards are for the team-reputation feature on Team / Enterprise plans.

​
Authoring a team-scope template

​
Via the dashboard

Settings → Organization → Teams → <team> → Alignment template or Protection template tab. The editor shows three rows:
  • Org floor (read-only) — the org admin’s authored org template, which acts as the strict floor.
  • Team (editable) — your team’s contribution, hybrid form + YAML editor.
  • Composed preview (read-only) — what the cascade resolves to for an agent in this team (combining org floor + your draft + platform ceiling).
The save button is gated on org owner / org admin role today. (A dedicated Team Admin role lands in a later milestone, scoped to a single team within an org. Until then, all team-template authorization is purely org-level.)

​
Via the API

Same shape for protection (/v1/protection/team/{team_id}). Body size limits: 128 KiB for alignment, 64 KiB for protection (mirrors org-scope template limits). Authorization: requireOrgRole(team.org_id, ['owner', 'admin']) for writes; full member roster (owner / admin / member / viewer / auditor) can read.

​
Via the CLI

The CLI walks every org you’re a member of and lists teams across all of them; the org_name column disambiguates teams across orgs.

​
What team scope does NOT do

  • Team scope is not user-scope. Users do not “belong to” a team in the composition sense. The user-team association comes only via the Team Admin role grant (a permissions concept, not a membership concept) — landing in a later milestone. Until then, all team-scope authorization is purely org-level.
  • Team scope does not affect solo agents. Agents in zero teams compose exactly as they did before team-scope shipped. No regression; no migration; no surprise.
  • Team scope is not a recipe. Recipes are an orthogonal data plane for detection rules. They will gain team scope on the same rationale as cards (cataloged as a follow-on); until then, recipes are platform/org/agent-scope only.

​
See also