Skip to main content

Memory Types: Facts, Preferences, and Summaries

OpsWorker memory stores three kinds of entries. You create facts and preferences directly; summaries are generated automatically. Choosing the right type controls how the entry can be shared and how the AI applies it.

Facts​

A fact is something objectively true about your environment, your team, or the way your systems operate. Facts are the kind of thing you'd write in a runbook one-liner: short, unambiguous, and useful as background context for anyone reasoning about the cluster.

Good fact examples​

  • "The checkout service is deployed in the payments namespace on the prod-us-east cluster."
  • "Team Payments owns all services prefixed with pay-."
  • "Database migrations only run during the maintenance window, 02:00 to 04:00 UTC."
  • "We never auto-scale the ingress-controller deployment, capacity is set manually."
  • "Pods stuck in Pending due to PVC issues should be investigated against the EBS storage class first."

Properties​

  • Can be created at personal, cluster, or organization scope.
  • Can be promoted to a wider scope (personal → cluster → organization).
  • Visible to anyone with access to the scope.
  • Loaded by the AI during investigations and chat for the relevant cluster or organization.

Preferences​

A preference is a personal directive about how the AI should communicate or behave with you specifically. Preferences shape style and approach, they don't describe the environment.

Good preference examples​

  • "Keep answers concise. Skip introductions."
  • "Always include the exact kubectl command, not just a description."
  • "Prefer pointing me to relevant logs over giving me a summary."
  • "Use ISO timestamps in UTC."
  • "Don't suggest restarting workloads without first ruling out a configuration cause."

Properties​

  • Personal scope only, preferences are never shared with teammates.
  • Loaded for every chat session you start.
  • Apply across all your clusters (preferences are not cluster-specific by default).

Summaries (Auto-Generated)​

A summary is a third category that OpsWorker creates on its own. As you chat, the AI condenses what happened (the problem, what was checked, what was concluded) into a short summary entry so the context survives across sessions. You don't author summaries directly; they appear alongside your facts and preferences and can be deleted like any other entry.

Choosing the Right Type​

QuestionType
Is this something every teammate would benefit from knowing?Fact
Is this about how I want the AI to write or behave?Preference
Could this become outdated when a person leaves the team?Fact (ownership facts), Preference (work-style preferences)
Would I want this in a runbook?Fact

What Memory Should NOT Hold​

Memory is for short, durable context. Avoid putting these into memory:

  • Live cluster state: pod counts, current resource usage. The AI fetches that fresh every time.
  • Long-form documentation: runbooks, postmortems, internal docs. Memory is for short one-liners, not documents.
  • Secrets or credentials: memory is not a vault.
  • Temporary task notes: memory persists; transient context belongs in the chat conversation.

Who Can Edit (Role Gating)​

Editing rights depend on the scope and your role in the org. Read access to all scopes is available to every member.

ScopeCreate / edit / delete requires
My Memory (personal)Any member (your own entries)
Cluster MemoryAdmin or Readonly role
Organization MemoryAdmin role only

These rules are enforced by OpsWorker, not just recommended. Promotion is gated the same way as the destination scope: personal → cluster promotion requires Admin or Readonly, and cluster → org promotion requires Admin. See Promotion.

When editing a memory entry, OpsWorker replaces the old entry with the new one (this is delete-then-create on the backend, so the entry ID changes after edit).

Next Steps​