Team scope is optional. Solo agents (in zero teams) compose under the 3-layer cascade
platform → org → agent — the historical shape, unchanged. Teamed agents compose under platform → org → {team₁, …, tₙ} → agent. See Team Scope for the team layer’s mechanics; the rest of this page covers the rules that apply at every layer present.Why composition exists
Previously, card merging happened per request. The gateway would fetch an agent card, an org template, and a CLPI policy, then runmergeOrgAndAgentCard() and mergePolicies() on every inbound call. That cost real latency, scattered merge logic across services, and made it hard to answer “what does this agent’s effective card actually look like?”
Composition moves the merge to storage time. When an agent’s scope-level card, org template, platform policy, or exemption list changes, a background job (compose_agent_card, compose_protection_card) computes the canonical card — the fully-merged, fully-resolved, ready-to-serve document — and writes it to canonical_agent_cards or canonical_protection_cards.
Every gateway and observer read hits the canonical table, not the raw scope rows. The request path has zero merge cost.
The scopes
Scope ordering is platform → org → (team)? → agent. The team layer is conditional: agents in zero teams compose under the 3-layer cascade; agents in one or more teams pick up a Team layer between Org and Agent. Multi-team agents fold strictest-wins across all their teams. See Team Scope for details.
Later scopes apply over earlier scopes according to the per-field rules below. The same rules apply with 0, 1, or N team layers present — the composer’s strictest-wins idiom is variadic.
Field-level composition rules
Composition is not a single blended operation. Each card section has its own merge semantic chosen to match its governance intent:
Composition metadata (
_composition) on the canonical card records which scopes contributed which fields, so downstream readers can debug “where did this value come from?”
Exemptions
An exemption waives a specific org- or platform-scope field for a specific agent, with explicit justification and expiry. Exemptions replace the legacy booleanorg_card_exempt flag, which was an all-or-nothing escape hatch.
Structure
Rules
- Exemptions are section-specific. A single exemption targets one field or pattern-scoped subset, not the whole card.
- Exemptions are audit-logged synchronously on grant and revocation. Every composition that honors an exemption is traceable.
- Exemptions expire (default 90 days). The composer refuses to honor an expired exemption; the next recompose quietly drops it.
- Exemptions on
BOUNDARYconscience entries are rejected at the API layer. Inviolable commitments cannot be waived.
Composition with exemptions
When the composer runs:- Compute the scope union (platform + org) for each field.
- For each active exemption, subtract the exempted patterns from the scope union before applying agent-scope.
- Apply agent-scope per the normal rules.
- Record the exemption reference in
_composition.exemptions_applied[].
The canonical card
The canonical card is the output of composition:card_yaml is what the CLI and dashboard surface as the “card this agent is running.” card_json is what the gateway reads for policy evaluation (faster than re-parsing YAML on every request).
The recompose pipeline
Composition runs in response to events:Staleness window
Between an org-template change and the recompose worker finishing, the canonical card is stale. The gateway handles this with theneeds_recompose KV bypass: when the canonical row flag is true, the gateway serves the canonical without populating the 5-minute KV cache, so the next change after recompose is seen immediately.
For a sub-50-agent org, recompose completes in under 2 seconds. For 10k+ agents, the background worker paces the batch to avoid saturating downstream services.
Worked example: three-scope composition
Scenario: Acme Corp has an agentmnm-patch-001 (a deploy remediation agent).
Platform scope
Org scope (Acme Corp)
Agent scope (mnm-patch-001)
Composed canonical card
integrity_mode: observe was silently overridden to enforce by the org. The composition metadata makes this traceable — not hidden.
The protection card composes separately. The protected_surface entries carry source_scope stamped at the highest scope that declared them — so the agent cannot claim provenance of an org rule:
Debugging composition
CLI
mnemom card show always renders the canonical composed card. The _composition metadata block, the raw agent-scope row, and per-field scope provenance are not surfaced by the CLI today — use the API below.
API
Observer
Every gateway + observer card read emits a structured log entry withcard_source: canonical_hit (or canonical_miss_fallback in the rare case the canonical row is missing and the composer is still catching up). The production criterion is that the fallback rate is zero on production traffic.
Trust Posture is a parallel cascade, not nested
Cards compose alongPlatform → Org → Team → Agent. Trust Posture — the team-scoped oversight policy artifact — composes along its own parallel cascade Platform → Org → Team and does NOT fold into the per-agent card.
Postures and cards are parallel artifact types: postures are team-scoped policy input (drives the observer’s sideband sweep), cards are agent-scoped runtime treatment (read by the gateway at request time). They share infrastructure (this composer idiom, KV caching, audit log) but their data planes are independent.
Practically:
- An advisory written by a posture-driven detector lands in
pending_advisoriestagged withsource: sideband.{coherence,fault_line,fleet}. The gateway picks it up on the next turn for an affected agent and lets card-driven enforcement decide the runtime treatment. - The posture cascade has no agent leaf because postures are inherently fleet-level (they observe a group, not an individual).
- Composing a posture into the canonical card is intentionally not supported — see Posture vs. Cards for the design rationale.
See also
- Agent Cards — the two-card model overview
- Alignment Card Schema — normative schema for unified alignment cards
- Protection Card Schema — normative schema for protection cards
- Card Lifecycle — amendment, reclassification, expiry
- Trust Posture — team-scoped oversight policy
- Posture vs. Cards — parallel cascades architecture