Experience Cards: Team-Owned repo Memory for CoCo

Autonomous software engineering (SWE) agents are fundamentally changing how we program. However, they remain constrained by a "closed-world" perspective: when attempting to resolve bugs, they rely strictly on local context or start entirely from scratch, bypassing the vast reservoir of historical human expertise preserved on platforms like GitHub.

Integrating memory into AI agents demonstrates that coding assistants need not remain stateless—they can capture knowledge from a session and retrieve it when needed. Yet, introducing a memory module is merely an initial step. As soon as agent memory is deployed within a real-world engineering team, two major challenges emerge:

1. Autonomous memory triggering is unreliable: Relying on the model to spontaneously identify what is "worth remembering" results in sparse, noisy retention. The most critical insights are precisely those the agent overlooks while fully occupied with task execution.
2. Maintenance poses significant overhead: Centralized server-side data stores act as shared, mutable blobs that demand continuous curation and impose an administrative burden on service operators. Unlike standard codebases, runbooks, and team standards, server-side memory lacks clear ownership. Consequently, git-project-specific memories are far more effectively owned and managed directly by the development team.

Experience Cards address both issues by serving as local, client-side memory that enhances an agent's session-level context. Stored locally with user approval, these cards are neither processed nor retained by Snowflake (server-side). Experience Cards complements agent memory and provides workflow-integrated intelligence. By extracting insights directly from pull requests and review comments, cards resurface key architectural decisions or bug patterns at the precise moment they are needed. Rather than relying on unpredictable agent triggers, we use harness hooks to ensure relevance. This approach acknowledges that a single memory module cannot address every need. Instead of replacing existing server-side memory, Experience Cards provide a customizable, complementary layer that empowers teams to own and derive direct value from their collective engineering knowledge.

Agent memory has moved beyond simple recall to a harder question: what human experience should an agent learn from, and how do we govern it? Inspired by MemGovern (Wang et al., 2026), which showed that structured experience cards measurably improve code agents, we apply this to enterprise GitHub projects. Our goal is to enhance code review by predicting expert feedback, saving significant developer effort and review cycles.

What is an Experience Card?

An Experience Card is a small, structured, reviewable unit of team knowledge distilled from a merged PR and the concerns its reviewers raised. While SnowMem's Tier 2 facts are private to a workspace and auto-extracted for one agent's benefit, an Experience Card is a shared, portable artifact meant to elevate every agent working in that repository.

Every card uses a fixed seven-field schema, eliminating the ambiguity of free-form blobs and helping ensure that cards can be validated, deduped, and shared.
Fields of Experience Cards:

1. Problem Summary: One-sentence, repository-agnostic statement of the bug pattern.
2. Signals: 10–18 high-signal keywords, symptoms or component names.
3. Root Cause: Causal chain from trigger to failure, grounded in the diff and review.
4. Fix Strategy: Solution methodology and tradeoffs considered.
5. Patch Digest: Changed areas and key chunks (a semantic digest, never a raw diff).
6. Verification: Methods for reproducing and testing the fix.
7. Review Feedback: Transferable reviewer principles (for example, "When X, do Y").

Here is a real card

The Review Feedback field is the primary payload for transfer. A second LLM pass over the raw review comments extracts 0–3 transferable principles—the institutional knowledge a senior reviewer carries in their head—making it explicit and retrievable for future PRs.

Capturing institutional knowledge via PRs

The core insight behind Experience Cards is that memory quality is a triggering problem before it is a modeling problem. We do not ask the agent to remember; instead, we hook into the highest-signal artifact a team already produces: the merged PR and its review comments. A reviewer catching a subtle concern on a PR provides ground truth about what a high-quality review looks like. We distill exactly that.

Capture runs as a reusable pipeline, filtering heavily at intake to ensure only high-quality memories land.

Figure 1: The Experience Card capture pipeline: a structured process that transforms merged PRs into governed, team-owned memory by filtering for high-signal content and using an LLM to generate actionable, structured cards.

We filter bot author comments, PRs with fewer than three review comments, non-code changes, diffs outside a 50–5000-line-of-code (LOC) band and anything whose pre-review commit can't be fetched. Because capture is anchored to this structural signal rather than the model's discretion, the pipeline sees the right moments every time — that is what lets us save quality memories instead of a pile of "the agent thought this was interesting."

Retrieval workflow: augmenting code review

Given a new PR, the reviewer requires only the few cards that apply, drawn from an ever-growing pool. A single query against this pool dilutes results quickly. To address this, retrieval expands the PR into several sub-queries and fuses the results.

Figure 2: Workflow for augmented code review: using hybrid search to retrieve and inject relevant team-owned Experience Cards into the baseline review process.

Retrieval is deliberately simple. We expand the PR into a few sub-queries covering its title, the code area and the likely kind of issue, then run a hybrid search over the card pool and fuse the results into a small top-K set of candidate cards.

The manner in which these cards are used is critical. The reviewer operates in an augmented mode, consisting of two passes. The first pass is identical to the standard review and produces a baseline set of comments. The second pass reads only the retrieved cards and appends new, card-grounded comments. It does not edit, reorder, or drop anything from the baseline. Because the second pass can only append, the final output is a strict superset of the no-memory review. Empirically we found memory increased or maintained the reviewer's recall. However, in other practical settings memory may hurt end performance as well.

Study 1: Impact on review recall

We evaluated the primary use case: PR code review. The question: With a repository's card set injected, does the agent catch more real concerns than a human reviewer would?

Setup: We utilized 15 merged PRs from a large internal platform repository, containing 71 ground-truth reviewer concerns (curated from 146 raw comments, excluding author self-replies and chatter). The 48-card pool was derived from a separate, earlier window to ensure the evaluation never included its own answers. Each configuration ran five times; results represent the five-run means with standard-deviation bands, scored by a deterministic judge (temp 0, binary alignment).

Figure 3: Comparison of baseline recall against recall with augmented Experience Card retrieval for both Haiku 4.5 and Opus 4.7 reviewer models.

Three key findings emerge:

• Small, fast models review like large ones: Haiku with cards (47.0%) closes most of the gap to unaided Opus (50.2%), making continuous, high-quality review viable at a fraction of Opus's cost and latency.
• Weaker models benefit more (+7.8pp vs +4.6pp): Memory provides the most value to the model that knows the least. Yet, Opus cites cards more often (51% vs 30%), using them more deliberately even when it requires them less.
• The gain is efficient: At ~7–9 LLM calls per-review compared to ~two, the cost is cents per PR—far less than the cost of one missed bug. Value tracks related history; greenfield subsystems default to baseline.

Study 2: Analyzing redundancy and rediscovery

In a Cortex code setting, we mined cards from 253 CoCo sessions across two sophisticated repositories to answer a blunt question: did a later session independently re-encounter a problem that an earlier session had already solved?
Every surviving card is backed by an observed recurrence—a verified rediscovery.

Roughly a quarter of agent turns were pure rediscovery —time spentre-deriving solutions the agent or a teammate had already discovered. A single PowerShell-portability pattern recurred across 24 separate sessions; the most extreme case burned ~40 turns re-hunting a GitHub-auth token. Some recurrences were cross-engineer—one person re-hitting a wall a teammate had already cleared. These 15 cases are the audited subset, each earned by a real recurrence. The pipeline scales; quality is prioritized, then volume.

Figure 4: Impact of Experience Cards on agent efficiency, highlighting the reduction in turn-based rediscovery across two distinct repositories.

This benchmark measures the floor—the efficiency gained simply by existing. The knowledge was present; it was merely not durable, forcing the team to "pay" for the same solution twice.

Production insights: The value of ownership

We did not start with the goal of proving team ownership was the superior design; we set out to measure lift. The production data confirmed the value of the ownership model.

Consider the recurrences: most were same-donor, where an engineer re-solved a problem their own earlier session had already cracked—proof that individual memory decays without a durable repository. However, a significant share were cross-engineer, where one person encountered a problem a teammate had already solved, unaware of the existing solution. This pattern cannot be captured by per-session or per-user memory; it requires team-owned knowledge. What began as a governance design choice became the primary mechanism for mitigating the most significant recurrences.

Once ownership is established, engineering payoffs follow:

• Safe to share: Beforestorage, a governance scrub replaces repo slugs with <REPO>, SHAs with <HASH>, and paths with <PATH>. This preserves the lesson while removing identifying details. A card is portable knowledge.
• No server to babysit: Cards are static, validated artifacts ingested into ArcticMem's existing hybrid store. There is no new stateful service to maintain, garbage-collect, or arbitrate for staleness. Each team's set remains as fresh as they keep it, motivated by the fact that it improves their own code review process.
• Compound benefits: One engineer's hard-won lesson becomes the team's default, shortening the ramp-up for every new reviewer—human or model. Knowledge accrues across the team, not merely within a single agent-session.

This approach applies a "solid instinct" to memory design: single ownership, an explicit interface (the seven-field card) and a shared retriever rather than a bespoke central service. We reached it not from principle but from watching the same wall get hit twice by two different people.

Conclusion: Experience Cards beyond CoCo

The approach is evolving. Cards currently skew fine-grained and require topic-level consolidation; a card set's breadth is limited by the engineers whose PRs feed it, and the ground-truth curator remains an imperfect LLM. However, these are fundamentally ownership problems—the kind a team that owns its cards is positioned to solve, unlike a centralized server.

The shape of memory should match the shape of the team. Hook the signal a team already produces, scrub it for safety, gate it by the review the team trusts and let the team own the result. The payoff is memory that triggers reliably, and stays fresh, and improves performance empirically. This pattern generalizes beyond code review. Any review-gated workflow can capture team-owned experience using the same hooks—whether incident retrospectives feeding an on-call agent, resolved tickets feeding a support agent or merged design docs feeding an architecture assistant. One memory module is insufficient. Snowflake's Cortex Sense (in-preview) makes a similar bet by grounding data agents in the query and dashboard signals a business already produces. Experience Cards apply this instinct to a different signal and owner: the team's review history. The frontier lies in the portfolio of memory forms—private vs. shared, automatic vs. reviewed, per-session vs. per-team—and how an agent integrates all of them simultaneously.