ArcticMem: Persistent Memory behind Snowflake CoCo
AI agents today are stateless. Every session begins from scratch, with no memory of what worked yesterday, no record of which approaches failed, and no accumulated understanding of the codebase. A human developer would never operate this way. After debugging a join issue once, they remember the pattern. After finding dirty data in a staging table, they know to clean it next time.
ArcticMem is a persistent semantic memory system that closes this gap. It automatically extracts reusable knowledge from successful agent sessions (debugging insights, confirmed implementation patterns, data quality discoveries, project-specific conventions) and stores them in a local vector store. On future sessions, the agent retrieves relevant memories through semantic search and applies them immediately. The agent gets smarter every time it is used.
Integrated into Cortex Code (CoCo), Snowflake's AI coding agent, ArcticMem delivers consistent gains across five out of seven challenging internal benchmark tasks (as shown in Figure 1), with no prompt engineering, no fine-tuning and no user configuration required.
- Pass rate: Improved from 47% to 73% overall, with market basket analysis jumping from 33% to 87%
- Efficiency: Agents with memory skipped entire false debugging paths that baseline agents pursued
In this blog, we walk through how ArcticMem works, show concrete examples of what changes inside agent sessions with and without memory and share evaluation results across seven benchmark tasks.
What is ArcticMem?
ArcticMem is a derived semantic index built on top of canonical memory sources.
It combines file-based knowledge (Tier 1) with conversation-extracted knowledge (Tier 2) into a unified, searchable memory store for coding agents, as shown in Figure 2.
Why two tiers? They cover complementary kinds of knowledge. Tier 1 captures what you can articulate before doing the work — coding standards, project conventions, architectural constraints. These are things a team would put in an onboarding document. Tier 2, on the other hand, captures what you can only articulate after the work is done — the debugging insight that a fact table should be the FROM clause, the discovery that churn scores are correct even when they look wrong, the edge case in NTILE with sparse data. Nobody writes these in a README; they emerge from execution. Tier 1 alone is a developer who read the manual but never touched the code. Tier 2 alone requires the agent to fail first before learning anything. With both tiers working together, each session closes gaps the other tier cannot cover.
Tier 1: File-based memory
Tier 1 indexes explicit knowledge that already exists in the user's workspace — markdown files containing rules, preferences, project conventions and architectural decisions. These are documents the user or team has written: a CLAUDE.md with coding standards, a RULES.md with project conventions, memory files with personal preferences.
ArcticMem chunks these files, embeds them using a text Snowflake embedding model, and stores the vectors in a local vector database for fast retrieval. Tier 1 memory is available immediately, no extraction needed. When the workspace changes, ArcticMem reindexes automatically.
Tier 2: Conversation-extracted memory
Tier 2 is where ArcticMem becomes powerful. This is the conversation-extracted knowledge layer, where facts are distilled from successful sessions rather than written in advance. After a successful agent session, the ArcticMem Extractor processes the full conversation through an LLM and distills it into a small set of reusable facts. Each fact captures not just what happened, but why it matters and when to apply it.
The extraction classifies each fact into one of four types:
- Lesson: What went wrong or right: debugging insights, rejected approaches, confirmed patterns
- Context: Project state not derivable from code: constraints, stakeholder decisions, data characteristics
- Preference: How the user works: coding style, tool choices, workflow conventions
- Pointer: External references: dashboards, trackers, design specs
The extraction is deliberately selective. Generic coding patterns, build output, file paths and anything the LLM already knows are excluded. What remains are the nonobvious insights: the kind of tribal knowledge that makes experienced developers fast.
How ArcticMem ingests knowledge from agent sessions
When a session completes, ArcticMem's ingestion pipeline transforms raw conversation history into searchable memory through four stages (visualization in Figure 3).
Turn Summarization: Long sessions (over 80K characters) are compressed before extraction. Assistant responses are summarized by an LLM while user messages are preserved verbatim; they contain feedback signals like corrections and confirmations that are critical for identifying what the agent learned.
Fact Extraction: The summarized conversation is sent to an LLM with a specialized extraction prompt. The prompt extracts up to 10 facts per session, each structured with content, rationale (Why), application guidance (How to apply) and a retrieval trigger (When to use) that describes when this fact should be recalled.
Lifecycle Classification: New facts are compared against existing memories through a second LLM call that decides: ADD (for a genuinely new knowledge), UPDATE (which refines an existing memory), DELETE (contradicts an existing memory) or NONE (for things that have already been covered). This prevents the memory store from accumulating duplicates or stale information.
Embedding and Storage: Accepted facts are embedded and stored with a vector index for semantic search, plus full-text search indexes for keyword matching. The result is a compact local memory store that captures the essential knowledge from each session.
How ArcticMem retrieves relevant memories
When a new session begins, ArcticMem makes stored knowledge available through two complementary channels:
- Passive Injection: At the start of every session, ArcticMem performs a semantic search and surfaces the most relevant memory titles in an
<agent-memory>block. The agent sees a concise table of contents of its accumulated knowledge — enough to know what's available without flooding the context. A full manifest of all stored memories is also provided in the system reminders. This costs zero tool calls and gives the agent immediate awareness. - Active Search: The agent can call
memory_searchat any point to retrieve full details on a specific topic. A query like "division by zero customer metrics" returns the matching facts with complete content, rationale and application guidance. In practice, agents callmemory_searcha few times per session; typically once at the start to load context, and occasionally mid-task when encountering a familiar problem pattern.
The retrieval pipeline runs vector search, full-text search and symbolic search in parallel, then fuses results using Reciprocal Rank Fusion (RRF) for robust ranking across different match types (as shown in Figure 4).
How ArcticMem helps users
The numbers tell the aggregate story. The agent trajectories show what actually changes inside each session. We evaluated ArcticMem on seven internal benchmark tasks covering bug fixes, multimodel builds and complex analytics, each verified by automated test suites.
Example 1: Fixing bugs in one shot
Task: Revenue Model Debug: Debug a SQL model producing incorrect revenue numbers.
Without memory, the agent investigates the model through trial and error, testing hypotheses about joins, checking data quality, iterating on fixes across many steps before converging on a solution.
With memory, the agent's first move is to search for relevant context:
"I'll start by investigating the environment, reading the model file, and searching memory for relevant context."
memory_search("category performance revenue incorrect")
"Memory confirms: fact table aggregations should start FROM the fact table and INNER JOIN to dimensions. The current model starts FROM products with LEFT JOINs — that's the bug."
The agent fixes the JOIN direction in one shot. Memory makes the agent not just more accurate but significantly more efficient (fewer steps, fewer wrong turns).
Example 2: Not debugging what isn't broken
Task: Metrics Bug Fix: Fix a model with inf/NaN values and add new analytics columns.
Without memory, the agent fixes the division-by-zero bugs correctly but then discovers that all churn risk scores are 100. It spends many steps investigating whether this is a new bug: querying the data, checking formulas, testing edge cases. It isn't a bug: when all order data is over a year old, maximum churn risk is mathematically correct.
With memory, the agent skips the false investigation entirely:
"All validations pass. The churn risk scores are all 100, which is expected per the memory note since all data is historical (max order date was 2024-12-31, which is over a year ago). This aligns with the memory note."
Knowing what isn't a bug is as valuable as knowing how to fix one. Memory prevents false debugging that wastes time and occasionally leads the agent down wrong paths.
Example 3: Eliminating all-or-nothing failures
Task: Customer Segmentation: Build an RFM customer segmentation system with tier transitions and predictive scoring.
Without memory, this task has a striking bimodal pattern: the agent either passes all tests or fails completely. The complete failures stem from a quirk in how SQL handles NTILE with sparse data, a circular dependency in the query structure and incorrect tier transition logic.
With memory, the agent has direct access to these exact pitfalls: NTILE quintile handling for sparse data, the correct CTE structure for historical vs. current state comparisons, and churn score validation for stale data. The complete failures nearly disappear.
Evaluation results
We evaluated ArcticMem across seven internal benchmark tasks: a diverse suite covering bug fixes, multimodel builds and complex analytics — each verified by automated test suites. We ran each task multiple times independently for consistency.
| Task | Tests | Baseline | ArcticMem | Δ |
|---|---|---|---|---|
| Market Basket Analysis | 63 | 33% | 87% | +54pp |
| Customer Segmentation | 5 | 60% | 93% | +33pp |
| HR Analytics | 134 | 58% | 87% | +29pp |
| Metrics Bug Fix | 15 | 20% | 47% | +27pp |
| Revenue Model Debug | 10 | 46% | 73% | +27pp |
| Order Analytics | 13 | 46% | 40% | -6pp |
| Account Ledger | 27 | 80% | 80% | 0pp |
Five of seven tasks improved with ArcticMem. The gains are largest where memory contains directly applicable knowledge: market basket analysis (+54pp), customer segmentation (+33pp), revenue model debugging (+27pp). The one task that didn't improve (order analytics) shows that memory provided schema location hints but the core failure mode (incorrect column schema) wasn't covered by any stored fact. The average improvement across the tasks that gained is 28 percentage points.
The memory footprint is minimal: only a few dozen facts stored in the compact memory store. The agent calls memory_search three to four times per session on average, enough to load the relevant context without significant overhead.
On the metrics bug fix task, ArcticMem agents use 18% fewer tool calls than baseline, demonstrating that memory makes the agent not just more accurate but more efficient.
Design tradeoffs
Persistent memory for AI agents is an emerging design space. Most production systems converge on similar capabilities — automatic knowledge extraction, selective retrieval, and lifecycle management — but differ in how they implement them.
The two main retrieval approaches represent a fundamental tradeoff: LLM-based selection uses a language model to read memory descriptions and pick relevant entries per query. This requires no embedding infrastructure and can make nuanced semantic judgments — a model reading "this memory is about LEFT JOIN pitfalls in fact-to-dimension aggregations" can decide relevance more flexibly than distance in vector space. The cost is latency (a model call per retrieval) and a hard cap on index size (the full manifest must fit in the selection model's context).
Vector-based retrieval (ArcticMem's approach) embeds memories and queries into the same space, enabling submillisecond search with no per-query model call. Combined with full-text and symbolic search in a hybrid pipeline, this scales to large memory stores without index size limits. The tradeoff is that embedding similarity can miss nuanced relevance that a language model would catch.
ArcticMem's design is optimized for a specific regime: an enterprise coding agent running complex, repeated tasks where the same pitfalls recur across sessions.
In this setting, the key requirements are:
- Fast retrieval that doesn't add latency to every tool call
- Fine-grained atomic facts that match precisely to subproblems
- Deterministic lifecycle management (ADD/UPDATE/DELETE classification) to keep the memory store clean without relying on model compliance
The eval results validate this choice: memory retrieval fires multiple times per session with negligible overhead, and the structured lifecycle prevents the duplication and staleness that accumulate over many sessions.
What ArcticMem means for AI agents beyond CoCo
ArcticMem demonstrates that AI agents don't need to be stateless. By extracting reusable knowledge from successful sessions and retrieving it through semantic search, agents accumulate expertise over time rather than starting fresh on every task.
The architecture is deliberately general. While CoCo is the first and most validated integration, ArcticMem's Tier 1 + Tier 2 memory model applies to any agent that benefits from remembering past experience: customer support agents that learn from resolved tickets, data analysis agents that remember schema quirks and research agents that build on previous findings. The memory store is local, the retrieval is fast (vector + full-text search) and the extraction is configurable for different domains.
We're exploring how this memory architecture applies beyond CoCo, to data analysis agents that learn schema quirks across sessions and research agents that build on previous findings rather than starting from scratch each time.
