What is Organization Memory?
Corelayer keeps a per-organization memory of what it has learned about your systems. Every time you give feedback — closing an issue as a false positive, telling the assistant to ignore a class of alerts — and every time an incident is investigated, Corelayer distills the lesson into a durable memory. That memory is then applied automatically: it stops Corelayer from re-alerting on things you’ve already told it to ignore, and it gives every new investigation the context of what has happened before. Memory is scoped to your organization and isolated from every other tenant. Each memory is either anchored to a specific resource (a database, service, or integration) or kept organization-wide.Kinds of Memory
| Kind | What it captures | Example |
|---|---|---|
| Failure pattern | A recurring failure, its root cause, and the fix | ”Connection pool exhaustion on the orders DB during peak traffic — raise max_connections.” |
| Preference | What you want surfaced or ignored | ”Don’t alert on staging timeouts.” |
| Fact | Stable context about your systems | ”The payments service runs on Postgres 14.” |
| Decision | A standing policy | ”Retry three times before escalating.” |
How Memories Are Created
From your feedback on issues
When you close an issue with feedback, Corelayer reads the intent:- Feedback that means “don’t alert me about this again” — false positive, expected / by design, won’t fix, don’t alert — becomes a preference anchored to that issue. Corelayer will suppress matching signals going forward.
- Feedback that means “fixed / resolved / duplicate / still investigating” is not treated as suppression. A recurrence after a fix is a regression worth surfacing, so Corelayer keeps watching.
Reopening an issue is treated as a correction. If a memory was created or reinforced by closing that issue, reopening it weakens or removes that memory — so a mistaken “ignore” doesn’t keep hiding real problems.
From the assistant
You can teach Corelayer directly in chat. Tell the assistant something like “Remember that the nightly ETL job is expected to spike row counts on Mondays” and it saves the statement as the right kind of memory (preference, fact, or decision). If the new statement contradicts something Corelayer already believes, it surfaces the conflict for you to confirm rather than silently overwriting it.From incidents
Corelayer consolidates resolved issues on a recurring basis, turning repeated incidents into failure patterns with a root cause and fix. These accumulate over time so that the next occurrence of a known failure is recognized immediately.How Memory Is Used
Suppressing noise
Before Corelayer creates a new issue, it checks the signal against your preferences — both the exact recurrence of something you’ve closed before and anything semantically similar. If a standing preference clearly says to ignore it, the signal is suppressed and no issue is created. This is what keeps “I already told you about this” from happening twice.Sharper analysis
When Corelayer investigates a new signal, it recalls the most relevant memories for the systems involved — past failure patterns, known facts, and decisions — and feeds them into the analysis. Recall is ranked by relevance, confidence, and recency, so older or less certain memories fade in influence over time.Preflight: checking a change before you ship
Memory isn’t only applied after a signal arrives — you can ask it about a change before it ships. Preflight takes a pull request’s description and returns the failure modes, facts, and preferences the org has hit before for a change like that, as concrete reminders to double-check. Run it from the CLI inside a repository, with no arguments — it derives the PR context from the current branch:corelayer.preflight MCP tool takes a PR description, and with the Corelayer skill installed, asking your assistant to “check this PR against Corelayer” routes to it. See the CLI reference for flags and output.
Reviewing and Managing Memory
Open Cortex from the sidebar to see your organization’s memory. Cortex visualizes each system and the lessons attached to it, alongside organization-wide preferences, facts, and decisions. From Cortex you can:- Read what Corelayer has learned about each system
- Edit a memory’s wording
- Archive a memory to stop it from influencing suppression and analysis
- Restore an archived memory
Related
MCP Server
Search organization memory from AI agents and MCP-compatible tools.
Anomaly Detection
The signals that feed Corelayer’s investigations and memory.