Skip to main content
Every time the Superlog AI agent investigates an incident, it starts fresh — unless you’ve taught it things worth remembering. Agent memory lets you store facts that are injected into every investigation automatically: domain terminology your team uses, infrastructure details the agent needs to interpret stack traces, or corrections to past reasoning mistakes. Over time, these memories make investigations progressively more accurate.

​
Memory kinds

Each memory has a kind that describes the type of fact it captures:

feedback

A correction or preference for how the agent should work. Use this when the agent drew the wrong conclusion or used a pattern you want to change.Example: “Don’t suggest retries for the order-processor service — it’s intentionally fire-and-forget. Missing messages are handled by the upstream queue’s dead-letter policy.”

terminology

A domain term or acronym that the agent might misinterpret without context.Example: “TXN refers to our internal transaction ID, not a database transaction. Always look for it in the txn_id span attribute, not in db.statement.”

infra

How your system is deployed and runs. Helps the agent give concrete, actionable recommendations instead of generic advice.Example: “The orders service runs on ECS Fargate in us-east-1. Its database is RDS Postgres (db.t3.medium). There is no connection pooling — each task opens its own pool via pg.”

project

General project or team facts that span multiple services or aren’t naturally infra or terminology.Example: “This project is the B2B API. All tenants are identified by tenant_id in resource attributes. SLA breaches above 500ms affect enterprise tier only.”

​
Adding memories

​
In the dashboard

1

Open Agent Memories

Navigate to Settings → Agent Memories in your project.
2

Click Add Memory

Choose a kind, write a short title, and enter the body text. Click Save.

​
Via MCP

The create_agent_memory tool accepts kind, title, and body:
Before creating a new memory, call list_agent_memories to check whether a similar fact already exists. Duplicate memories don’t cause errors, but they waste context window space in investigations.

​
Memory fields

Keep the body specific and reusable — write it as if you’re briefing a new engineer who will investigate every future incident, not as a narrative about one past incident.

​
Project context

For high-level system architecture that applies to every investigation, use project context instead of individual memories. Project context is a single freeform text block (max 8,000 characters) that’s always injected first, before individual memories. Use it for:
  • System architecture diagrams in text form
  • Key services and their responsibilities
  • Deployment regions and topology
  • Critical third-party dependencies
You can read and write project context via the MCP tools get_project_context and set_project_context, or in the dashboard at Settings → Project Context.
set_project_context replaces the entire context field. Call get_project_context first and edit the returned text if you want to preserve existing content.

​
Archiving stale memories

When a memory is no longer accurate — for example, you’ve migrated away from the infrastructure it describes — archive it instead of deleting it. Archived memories stop being injected into investigations but are retained for your records. Via MCP:
To permanently remove a memory, use the delete_agent_memory tool.

​
Scope

Memories are scoped to your organization and are shared across all projects within it. A memory you add in the orders project is also available to the payments project in the same org. Use the kind and title fields to make it clear which system a memory applies to.