# Memories Memories are facts that Cleric learns from your conversations and uses to improve future investigations. They capture infrastructure details, service dependencies, investigation preferences, and other operational knowledge specific to your environment. ## How Memories Work When you interact with Cleric during an investigation, it identifies useful facts from your messages and offers to remember them. These memories are then used in future investigations to provide more accurate and contextual analysis. ### What Gets Remembered Cleric captures several types of information: * **Infrastructure details**: System architectures, service configurations, deployment patterns * **Service dependencies**: Relationships between services that aren't obvious from monitoring data * **Investigation preferences**: How you prefer to handle specific alert types or investigation approaches * **Incident patterns**: Alert idiosyncrasies, common root causes, known issues * **Tool preferences**: Preferred diagnostic tools, dashboard links, useful integrations ## 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. ## 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 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.cleric.ai/learning/memories.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.