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 toWritable byLoaded by AI for
The whole organizationEvery user in the org (read)Admin role onlyInvestigations 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, memory is for short one-liners, not documents

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​

Creating, editing, and deleting organization memory is Admin-only, and this is enforced by OpsWorker. Every user in the org can read org memory, but only Admins can change it. Promotion from cluster to org memory is also Admin-only.

Because the impact is wide, treat org memory curation carefully:

  • 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

Promoting to org memory is Admin-only. 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​