Tutorial 2 of 729% complete
All tutorials
8 minBeginner

Fluent AI Memory

How context loading works when tools are available

Fluent AI Memory

How Continuity's RAG-based synthetic memory makes your AI assistants proactive.

How It Works

Continuity provides a unified synthetic memory system for your AI coding assistants. It generates instruction files that act as pointers to this memory, containing specific triggers that tell the AI when to query or update the project's knowledge base:

TriggerAI Action
User asks architectural questionSearch the synthetic memory for related decisions
User explains reasoningRecord the information into memory immediately
User considers changesCheck memory for potential conflicts with past decisions
User mentions being stuckUpdate short-term session memory with a blocker
Session endsSummarize progress into the long-term synthetic memory

When your AI assistant follows these instructions, it becomes a truly context-aware partner, proactively drawing on years of project history.

What The Instruction Files Contain

Continuity generates instruction files tailored to your specific AI tools — CLAUDE.md (for Claude Code), .cursorrules (for Cursor), .github/copilot-instructions.md (for GitHub Copilot), and others. These files serve as the "API documentation" for the AI to interact with Continuity's RAG-based memory.

Here's how they direct the AI to use the memory system:

markdown
## WHEN TO USE THE SYNTHETIC MEMORY SYSTEM

### When User Asks Architectural Questions
When the user asks "should we use X?" or "what about Y for Z?":
→ Search the project's synthetic memory (via RAG) BEFORE answering
→ Share what you found: "I found decision-X in the memory..."
→ Base your recommendation on the established project patterns

### When User Explains a Choice
When the user says "let's use X because Y" or explains their reasoning:
→ Immediately record this into the synthetic memory
→ Ensure the reasoning is preserved for future sessions

### When Suggesting Changes
Before recommending architecture changes or new dependencies:
→ Query the memory to check for existing decisions on this topic
→ If conflicts exist, flag them: "This would conflict with a prior decision..."
→ Let the user decide whether to override the existing memory

See The Proactive Behavior

Architectural questions

You: "Should we use WebSockets or polling for real-time updates?"

AI: Consults the synthetic memory system

"Let me check our project memory... I found decision-34 where we chose Firebase for push notifications to minimize infrastructure overhead. Given that established preference for managed services, we should probably look at a managed WebSocket solution rather than rolling our own."

Immediate memory updates

You: "Let's use Redis for the job queue because it has atomic operations and we're already using it for caching."

AI: "That aligns with our existing infrastructure. I'll record this decision into our project memory right away so we don't lose the rationale for consolidating on Redis."

Detecting conflicts with memory

You: "What if we use SQLite instead of PostgreSQL?"

AI: Queries the database-related decisions

"Before we switch, our project memory contains decision-12 where we specifically chose PostgreSQL for its ACID compliance with financial data. SQLite might not meet those same requirements. Do you want to proceed despite that, or should we look for more context on the original choice?"

Why This Works

The instruction files include:

  1. Specific triggers — "When the user asks X, do Y"
  2. Clear actions — Query, record immediately, check for memory conflicts
  3. Example dialogues — Shows the AI expected responses
  4. Tool syntax — How to interact with the synthetic memory surface

AI assistants follow instructions they read at conversation start. By framing Continuity as a project-specific memory system, we provide the AI with the long-term context it usually lacks.

What Gets Generated

The instruction files include:

  • Project statistics — Total decisions, memory health, last updated
  • Known topics — Top tags from your synthetic memory
  • Recent context — Last 10 decisions with IDs and summaries
  • Behavioral triggers — When to query or record into memory
  • Access protocol — How to call the synthetic memory tools (e.g., via MCP)

Files are regenerated:

  • On extension startup (if older than 24 hours)
  • After recording a new decision into memory
  • Manually via "Continuity: Regenerate Instruction Files"

If Your AI Isn't Proactive

Some AI tools don't reliably read instruction files. If the proactive behavior isn't happening:

Check the files exist

bash
# Check for the instruction file used by your AI tool:
# Claude Code
ls CLAUDE.md
# Cursor
ls .cursorrules
# GitHub Copilot
ls .github/copilot-instructions.md

Regenerate memory pointers

output
Cmd+Shift+P → "Continuity: Regenerate Instruction Files"

Remind your AI

You: "Consult the project's synthetic memory system (check CLAUDE.md/ .cursorrules) for our established decisions."

Fall back to explicit requests

The memory system tools work when you ask directly on clients that support native tool mounting:

  • "Query the project memory about authentication"
  • "Record this into our project memory: [your reasoning]"
  • "Show me the summarized project context from memory"

If the client is in degraded mode, use the repo-local fallback files in .continuity/ to provide the same context manually.

Customizing The Behavior

The generated section is marked and won't overwrite your own content. You can add custom instructions above the marker:

markdown
# My Project

## Custom Rules
- Always use TypeScript strict mode
- Prefer functional components

<!-- AUTO-GENERATED BY CONTINUITY - DO NOT EDIT BELOW THIS LINE -->
[generated content here]

Your custom rules will be preserved when Continuity regenerates.

Key Takeaways

  1. Instruction files drive behavior — AI reads them at session start when the client mounts tools
  2. Specific triggers work best — "When X happens, do Y"
  3. Files auto-regenerate — Kept fresh with recent decisions
  4. Fallback to explicit — Direct requests always work on mounted clients, and repo-local files cover degraded mode
  5. Custom rules preserved — Add your own above the marker

← Quick Start | Decision Logging →