> For the complete documentation index, see [llms.txt](https://docs.cleric.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cleric.ai/learning/memories.md).

# Memories

How Cleric remembers facts about your environment

Memories are facts that Cleric learns from your conversations and uses to improve future investigations. They cover everything from system architecture and alert behavior to how you want Cleric to respond.

## How Memories Work

When you interact with Cleric during an investigation, it identifies useful facts from your interactions and offers to remember them. These memories are then used in future investigations to provide more accurate and contextual analysis.

### Categories

Cleric classifies each memory into one of these categories:

* **Alerts & Runbooks**: triage rules, known false positives, escalation policy, and incident remediation playbooks
* **Architecture & Data**: service dependencies, ownership, deployment topology, data stores, and data flows
* **Observability**: where and how to query data, including dashboards, log and metric sources, queries, and metric names
* **Infrastructure**: the platform layer beneath services: cloud accounts, Kubernetes, networking, and capacity
* **Auth & Security**: authentication, authorization, secrets management, and security posture
* **Integrations**: third-party vendors, external APIs, and the failure modes they introduce
* **Deploy & Release**: CI/CD pipelines, rollout patterns, and release mechanics
* **Developer Workflow**: source repositories, code and config locations, team ownership, and development conventions
* **Domain & Product**: terminology, acronyms, business rules, and customer or company specifics
* **Agent Behavior**: how Cleric should respond, including language, format, scope, and output conventions

Cleric organizes the broader knowledge it gathers into these same categories. See [How Cleric Learns](/learning/how-cleric-learns.md#topics).

## Memory Proposals

After you send a follow-up message during an investigation, Cleric may propose a memory based on what you shared.

### Example: Accepting a Memory

During an investigation, you might share context:

{% code overflow="wrap" %}

```
@Cleric The checkout service depends on inventory-api and pricing-api for real-time stock and price validation. If checkout is slow, always check those two services first.
```

{% endcode %}

Cleric will propose a memory:

{% code overflow="wrap" %}

```
Would you like me to remember this?

"The checkout service depends on inventory-api and pricing-api for stock and price validation. When investigating checkout performance issues, check these dependencies first."

[Remember]  [Reject]
```

{% endcode %}

Click **Remember** to save the fact. Cleric confirms:

{% code overflow="wrap" %}

```
👍 Memory saved.
```

{% endcode %}

### Example: Rejecting a Memory

Sometimes Cleric might propose a memory that's not quite accurate:

{% code overflow="wrap" %}

```
Would you like me to remember this?

"High memory usage in the recommendation-engine always indicates a problem"

[Remember]  [Reject]
```

{% endcode %}

If this isn't accurate (maybe high memory usage is normal during certain operations), click **Reject**:

{% code overflow="wrap" %}

```
👍 Memory rejected.
```

{% endcode %}

You can then provide the correct context:

{% code overflow="wrap" %}

```
@Cleric Actually, the recommendation-engine uses 6-8GB during cache warming between 5-7am daily. This is expected behavior, not a problem.
```

{% endcode %}

Cleric will propose a corrected memory based on your clarification.

## Saving and Deleting Memories Directly

In addition to memory proposals, you can directly tell Cleric what to remember or forget during any conversation.

### Saving a Memory

{% code overflow="wrap" %}

```
@Cleric Remember that the checkout service depends on inventory-api and pricing-api
```

{% endcode %}

Cleric saves the fact immediately and confirms. This is useful when you want to teach Cleric something without waiting for it to propose a memory.

### Deleting a Memory

{% code overflow="wrap" %}

```
@Cleric Forget what you know about the staging database being shared with dev
```

{% endcode %}

Cleric finds the matching memory and removes it. Use this to correct outdated information or remove facts that no longer apply.

## Managing Memories from the Web App

Open **Knowledge > Memories** in the sidebar to browse, search, and filter every memory Cleric has stored. Click **Add memory** to save a fact directly, or hover a row and click the trash icon to delete one. These are the same operations as `@Cleric Remember…` and `@Cleric Forget…` in Slack.

## How Memories Are Used

During investigations, Cleric automatically searches its memory for relevant facts based on the services, environments, and topics involved.

For example, if Cleric is investigating an issue with the checkout service, it will search for any memories related to:

* The checkout service specifically
* Services that checkout depends on
* The environment where the issue occurred
* Similar alert patterns

This helps Cleric:

* Identify dependencies that aren't visible in monitoring data
* Apply your preferred investigation approaches
* Avoid paths you've indicated aren't useful
* Recognize known patterns and false positives

## Querying Memories

You can ask Cleric what it remembers about specific services, environments, or topics.

### Example: Service-Specific Memories

{% code overflow="wrap" %}

```
@Cleric What do you remember about the checkout service?
```

{% endcode %}

**Cleric's response:**

{% code overflow="wrap" %}

```
**Dependencies:**
• inventory-api, pricing-api (stock/price validation)
• payment-gateway (transaction processing)
• Check dependencies first when investigating performance

**Known Behaviors:**
• Connection pool: 25-30 connections during high traffic (from Jan 15 incident)
• Memory: 1.2-1.5GB typical, 2GB spikes during flash sales (normal)

**Operational:**
• Owner: payments team (#payments-oncall)
• 99.9% SLO, deploy window: Tue/Thu 10am-2pm PST

**Investigation:**
• Check recent deployments first for performance issues
• Check read replicas before primary for database issues
```

{% endcode %}

### Example: Environment-Specific Memories

{% code overflow="wrap" %}

```
@Cleric What do you know about our staging environment?
```

{% endcode %}

**Cleric's response:**

{% code overflow="wrap" %}

```
**Naming:**
• Services: *-staging suffix (checkout-service-staging)
• Namespaces: staging, staging-eu

**Differences from prod:**
• Smaller instance types
• Shares DB with dev (performance impact)
• Cache disabled
• External APIs use sandbox endpoints

**Investigation:**
• Error rates 10-15% expected (vs <1% prod)
• Performance 2-3x slower than prod
```

{% endcode %}

## Memory Cleanup

Cleric reviews its memories after investigations to keep them accurate and relevant. Memories are removed when they:

* Haven't been relevant to recent investigations
* Are contradicted by newer information you've provided
* No longer apply due to infrastructure changes