> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rootly.com/llms.txt
> Use this file to discover all available pages before exploring further.
# AI SRE Memory
> Review and curate durable, evidence-backed context that Rootly AI SRE can recall during future investigations.
AI SRE Memory turns useful investigation findings and eligible incident evidence into durable semantic context for future alert and incident investigations. It helps Rootly AI SRE reuse system-specific knowledge without treating an old conclusion as proof of what is happening now.
The Memory page requires AI SRE memory to be enabled and an Incident Response seat on the currently selected team. Confirm the selected team and your seat first; if both are correct and **Memory** still doesn't appear under **AI & Agents → AI SRE**, contact your Rootly representative. See [Manage User Permissions](/managing-users/user-permissions#ai-agents-and-ai-sre) for view and management roles.
## How Memory Works
After a completed investigation identifies a root cause or produces a useful best-effort explanation, Rootly can propose reusable context notes from the final analysis. When the incident context engine is enabled, Rootly can also propose notes from eligible recent incidents that allow Slack history collection and have a published retrospective; private incidents are excluded. A useful note is:
* Specific to a durable service, topology, mechanism, signal, or failure pattern.
* Durable enough to help with a future alert.
* Backed by exact evidence from the source investigation or eligible incident record.
* Written as a hypothesis the next investigation can verify.
These are separate proposal paths, but neither uses private-incident content for team Memory. A completed AI SRE investigation of a private incident does not propose, grade, or automatically activate context notes. Alert investigations linked to any private incident are excluded from those learning steps as well. If an incident later becomes private, notes sourced from that incident—and notes sourced from alerts linked to it—are excluded from Memory listing, version history, direct note access, and semantic recall.
One-off timestamps, customer or user identifiers, incident recaps, generic SRE advice, and instructions to acknowledge, ignore, restart, or roll back a system don't belong in memory. Rootly generalizes eligible findings into reusable system behavior and rejects a candidate that is meaningful only for the original customer, person, or incident.
Only **Active** context notes are available for semantic recall. When a later alert or incident has related context, AI SRE can include the most relevant notes and recheck them against current evidence.
Activation can be manual or automatic. Owners and admins with an Incident Response seat can activate a proposed note after review. When optional automatic activation is enabled for the current team, a proposed **Diagnostic hint**, **Known failure mode**, **Topology fact**, or **Historical context** note can become active without human approval after at least two distinct investigations each grade it 70 or higher out of 100 as strongly useful. Proposed notes are evaluated as near matches that were not shown to AI SRE, using each investigation's completed finding. **False positive pattern** and unrecognized categories are never eligible for automatic activation.
Automatic activation is a Rootly-managed team setting, not a self-service toggle on the Memory page. Contact your Rootly representative to verify whether it is enabled for the current team or to request that it be enabled or disabled.
## What AI SRE Can Remember
Context notes use one of these categories.
| Category | Use It For |
| -------------------------- | ------------------------------------------------------------------------------- |
| **Diagnostic hint** | The best signal, query, or comparison for investigating a service |
| **Known failure mode** | A recurring failure, its mechanism, and how it appears |
| **Topology fact** | A non-obvious relationship between services, queues, workloads, or dependencies |
| **Historical context** | A past incident or change that materially informs a future investigation |
| **False positive pattern** | The evidence pattern that distinguishes a benign signal from a real failure |
A false-positive note should explain how to verify the pattern. It shouldn't tell AI SRE to dismiss or acknowledge an alert without checking current evidence.
## Review Context Notes
Review proposed and active knowledge from the Memory page.
Open **AI & Agents → AI SRE → Memory**.
Search by title, summary, or category. Filter the list by category, source, or status.
Open the note and check its knowledge, scope, source, and evidence before changing its status.
Activate a reliable note, deprecate knowledge that is no longer useful, or quarantine a note that is wrong or unsafe to recall.
Select **Edit** to change the title, summary, or category. Saving creates a version and preserves the earlier version in **History**.
Owners and admins with an Incident Response seat can activate, edit, deprecate, and quarantine context notes. An on-call admin role by itself doesn't grant Memory management. Members with an Incident Response seat and access to **AI & Agents** can view Memory when the feature is enabled.
Memory from eligible sources is shared across the current team. The Memory page does not re-filter a note's title, summary, body, scope, source, or evidence references according to whether the viewer could invoke the originating connector or Private Agent capability. Treat Memory viewers and future investigations as the audience for every note proposed from an eligible public incident or alert.
Private incidents and alerts linked to any private incident don't participate in team Memory learning. Notes already sourced from an incident that becomes private, or from an alert while it is linked to a private incident, are excluded from the Memory page, version history, direct note access, and recall. This exclusion applies even to users who can view the source incident because Memory is team-shared rather than a private, per-incident store.
## Memory Statuses
| Status | Meaning | Available For Recall |
| --------------- | ---------------------------------------------------------------------------- | -------------------------------- |
| **Proposed** | A candidate learning awaiting manual review or eligible automatic validation | No |
| **Active** | Knowledge validated manually or by enabled automatic activation | Yes |
| **Deprecated** | Knowledge that is no longer useful | No |
| **Quarantined** | Knowledge that may be wrong or harmful | No |
| **Superseded** | An immutable earlier version replaced by an edit | No; available in version history |
Automatic activation is optional and team-scoped. When it is disabled, or when a proposal's category or usefulness grades don't meet the criteria above, the note remains **Proposed** until an owner or admin changes its status. Contact your Rootly representative to change this Rootly-managed setting. Continue reviewing active memory as your architecture and telemetry change.
## Editing And Version History
Context-note content is versioned so a correction doesn't rewrite the evidence trail. You can edit the title, summary, and category. Saving creates a version in the same lineage and keeps the previous version in **History**.
The underlying knowledge body, scope, and evidence references carry forward unchanged and remain available in version history. If the underlying claim is wrong, quarantine the note rather than softening only its title or summary.
## Recent Alert Context
Curated context notes can inform both alert and incident investigations. Separately, an alert investigation also checks recent operational history outside the curated Memory list. It can consider:
* Completed verdicts from the previous 30 days for alerts that name the same service or scoped entity.
* Resolution or mitigation notes from incidents linked to the current or related alerts.
AI SRE treats an earlier verdict as a candidate explanation, not as current evidence. It repeats the decisive reading over the new alert's window before relying on the same mechanism.
## Keep Memory Reliable
* Activate notes only when the claim is specific, reusable, and supported.
* Reject notes that preserve customer, user, incident, request, or other ephemeral identifiers instead of a durable system behavior.
* Prefer a verifiable signal over a prescribed response action.
* Deprecate knowledge that is valid history but no longer helps current investigations.
* Quarantine knowledge that contradicts current evidence or could mislead a responder.
* Recheck notes after service renames, topology changes, or observability migrations.
* Use [AI SRE instructions](/ai/ai-sre/instructions) for practices that should always run, and Memory for context retrieved only when relevant.
## Data Handling
Context notes are stored as durable Rootly records and keep version history. They don't use the 90-day AI session-message expiry. Changing a note to **Deprecated** or **Quarantined** removes it from recall but doesn't delete its record or earlier versions, and the Memory page doesn't currently provide a hard-delete action.
The investigation evidence used to create or recall a note can also appear in AI conversation history, model traces, and connector-specific records. Review [Data Privacy for Rootly AI](/ai/data-privacy-for-rootly-ai) for the complete storage and retention boundaries.
## Troubleshooting
Only **Active** notes are available for recall. Review the proposal and activate it if the claim is reliable and reusable. If automatic activation is enabled, an eligible proposal can instead become active after two distinct investigations each grade it as strongly useful; proposals that don't meet those criteria remain proposed.
Memory keeps deprecated, quarantined, and superseded records for review and history. Filter by **Active** to see only notes available for recall.
Review the note's scope and evidence, then quarantine it if the claim is misleading. AI SRE should revalidate recalled context against current evidence; use the completed investigation's accuracy control to flag a diagnosis that didn't.
## Frequently Asked Questions
No. Rootly proposes a context note only when the source evidence contains a durable, reusable system learning. Producing no note is valid when the result is one-off, customer-specific, procedural, or too uncertain.
No. Memory supplies a hypothesis or investigation shortcut. AI SRE must verify it against the current alert's live evidence before using it in a diagnosis.
No. Private incidents and alerts linked to any private incident don't propose, grade, or automatically activate team Memory notes. If a source incident later becomes private, notes sourced from it are excluded from Memory listing, history, direct access, and recall. This applies even to users who can view the private incident because Memory is a team-shared store.
The Memory page uses status changes and version history instead of deletion. Deprecate a note that is obsolete, or quarantine one that is misleading or unsafe to recall.