Skip to main content

Organization Memory

Organization Memory holds facts that apply across every cluster in your OpsWorker organization. It's the top of the memory hierarchy — entries here are loaded for every investigation and chat session in the org.

Use organization memory for company-wide standards that don't change between clusters:

  • "Engineering on-call rotates weekly. The current on-call is identified by the oncall:true annotation on PagerDuty schedule X."
  • "We require RFC-style postmortems for all SEV-1 incidents."
  • "Production data exfiltration is blocked at the network policy level — never suggest exporting raw data."
  • "Our incident comms channel is #incident-room."

Scope​

Scoped toVisible toLoaded by AI for
The whole organizationEvery user in the orgInvestigations and chat across all clusters

Like cluster memory, organization memory only stores facts. Preferences remain personal.

What Belongs Here​

Good organization memory entries are:

  • Universally true — they apply no matter which cluster the AI is reasoning about
  • Slow-changing — quarterly updates at most, not weekly
  • Policy-level — escalation, compliance, naming conventions, communication norms

Anything that varies between clusters belongs in Cluster Memory instead.

Good examples​

  • "All clusters use the same alert severity scheme: SEV-1 (paging), SEV-2 (urgent business hours), SEV-3 (informational)."
  • "Service ownership is tracked in the engineering/ownership GitHub repo. Each service has a CODEOWNERS entry."
  • "We do not auto-restart workloads. Every remediation requires a human to apply it."
  • "Customer-facing services are tagged customer-facing: true in their deployment labels."

Avoid​

  • ❌ Cluster-specific facts — keep those in cluster memory
  • ❌ Live state or current incident notes — those don't belong in memory at all
  • ❌ Sensitive information — credentials, customer PII, etc.
  • ❌ Long-form policy documents — link to them from Knowledge Sources instead

How OpsWorker Uses Organization Memory​

Organization memory loads at the start of every investigation and every chat session, regardless of which cluster is involved. The AI treats org-wide facts as the highest-priority context.

When org memory contradicts cluster memory, the AI surfaces the contradiction rather than silently choosing one. This makes organization memory a good place for hard policy ("we never auto-remediate") that you want to ensure is consistently applied.

Who Can Edit​

Any user in the organization can create, edit, or delete organization memory entries by default. Because the impact is wide, most teams treat org memory curation as a privileged operation:

  • Limit org memory edits to admins or a designated platform team
  • Review additions in a team channel before adding
  • Use clear, unambiguous wording — entries that need interpretation will be interpreted inconsistently

Promoting from Cluster​

The most common path into org memory is promotion from cluster memory. When a cluster memory entry proves to apply universally:

  1. Open the entry in Cluster Memory
  2. Click Promote to Organisation
  3. Confirm

The cluster copy is preserved; an org-scoped copy is created. See Promotion.

Editing and Deleting​

Organization memory follows the same edit and delete semantics as cluster memory:

  • Edit is delete-then-create on the backend — the entry ID changes.
  • Delete is immediate and not reversible.

Because org memory is loaded for every session, deleting an entry takes effect immediately for all users.

Next Steps​