Building Persistent AI Memory for Every Software Project

In the era of Generative AI, tools like Cursor and Claude Code have become indispensable for modern software engineers. However, a persistent friction point remains: the "Amnesia Effect." Every time you start a new session or switch projects, the AI loses the nuanced context of your architecture, coding conventions, and specific business logic. You spend the first ten minutes "warming up" the AI, explaining the same stack and rules repeatedly. Moreover, using these tools in a corporate environment presents a challenge: how do you utilize powerful AI configurations without polluting the company’s shared repository with your personal toolchain?

This article details how I engineered a "Persistent AI Memory" system. By integrating two powerful open-source toolkits—ai-devkit and antigravity-kit—and leveraging advanced filesystem techniques like Git Subtrees and Windows Junctions, I created a workflow that provides instant, project-specific context while keeping the core repositories clean.

The Problem: The AI Context Gap and Repo Pollution

Working on multiple projects simultaneously—ranging from complex enterprise C#/.NET systems to personal Vite/React side projects—exposed two major bottlenecks in the standard AI-assisted workflow:

1. The Cold Start Problem

Standard LLM-based editors rely on the files they can "see" in the current workspace. If your project doesn't have explicit documentation tailored for AI consumption, the AI makes guesses. It might suggest a functional component pattern when your project uses Class-based components, or suggest a library that conflicts with your existing dependencies. The result is a 5-10 minute manual briefing session for every new task.

2. The Configuration Pollution

To make AI tools effective, you often need to add configuration files (like .cursorrules, .claudeprompt, or specific instruction folders). In a team setting, committing these personal or tool-specific files into the main Git repository is often discouraged or prohibited. You need a way to keep your "AI brain" attached to the project locally without it ever appearing in the git status of the shared repo.

The Foundation: Leveraging Two Vietnamese Power-Tools

My solution is built on the shoulders of two excellent toolkits developed within the Vietnamese tech community. They solve two different but complementary aspects of the AI workflow.

ai-devkit: The Long-Term Memory

Developed by codeaholicguy, ai-devkit functions as a structured documentation framework. By running npx ai-devkit init, it generates a docs/ai/ directory with templates for seven critical stages of software development:

Requirements: Business logic and user stories.
Design: System architecture and UI/UX specs.
Planning: Task breakdowns and milestones.
Implementation: Coding conventions and tech stack details.
Testing: Strategy and test cases.
Deployment: CI/CD and infrastructure.
Monitoring: Observability and logging rules.

This ensures that when you ask an AI to "write a new feature," it looks into these files to understand how you write code before it generates a single line.

antigravity-kit: The Expert Agency

Developed by vudovn, antigravity-kit takes a different approach. It provides a modular system of 20+ specialized agents (e.g., @security-auditor, @performance-specialist) and 30+ skill modules. It uses a sophisticated prompt-routing mechanism where the system analyzes your request and "hires" the correct expert agent to handle it.

By combining these two, ai-devkit provides the Context (the "What" and "Where"), while antigravity-kit provides the Capability (the "How").

The Architecture: Centralizing the Toolkit

Instead of installing these toolkits manually in every project, I created a central management repository named my-ai-toolkit. This allows for centralized updates and a single source of truth for my AI configurations.

Using Git Subtree for Dependency Management

I chose Git Subtree over Submodules because it actually merges the code into your repository while keeping the history separate. This makes it easier to manage and less prone to the "detached HEAD" issues common with submodules.

# Initialize the central toolkit repo
mkdir my-ai-toolkit && cd my-ai-toolkit
git init

# Add ai-devkit as a subtree
git remote add ai-devkit-src https://github.com/codeaholicguy/ai-devkit
git subtree add --prefix=ai-devkit ai-devkit-src main --squash

# Add antigravity-kit as a subtree
git remote add antigravity-src https://github.com/vudovn/antigravity-kit
git subtree add --prefix=antigravity-kit antigravity-src main --squash

The Implementation: Zero-Pollution Linking

The "Secret Sauce" of this setup is using Windows Junctions (or Symlinks on Unix-like systems). A Junction is a symbolic link to a directory that behaves like a local folder but actually points to another location on the disk.

The Directory Structure

I organized my central toolkit to separate shared logic from project-specific memory:

my-ai-toolkit/
├── configs/
│   ├── .agent/              # Shared agent logic from antigravity-kit
│   ├── .cursor/             # Shared Cursor rules
│   └── projects/
│       ├── enterprise-app/
│       │   └── docs/ai/     # Context for the company project
│       └── side-hustle/
│           └── docs/ai/     # Context for the personal project

Linking Without Committing

To attach the AI memory to a company project without committing files, I use the following PowerShell commands:

# Variables
$PROJECT = "C:\workspace\company-project"
$SOURCE  = "C:\ai-workspace\my-ai-toolkit\configs"

# Create Junctions
New-Item -ItemType Junction -Path "$PROJECT\.agent"  -Target "$SOURCE\.agent"
New-Item -ItemType Junction -Path "$PROJECT\.cursor" -Target "$SOURCE\.cursor"
New-Item -ItemType Junction -Path "$PROJECT\docs\ai" -Target "$SOURCE\projects\company-project\docs\ai"

Crucially, I then use the .git/info/exclude file in the company project. Unlike .gitignore, this file is local to your machine and is never committed to the remote repository. This makes the AI folders invisible to Git.

# Add to local exclude
Add-Content "$PROJECT\.git\info\exclude" "`n.agent/"
Add-Content "$PROJECT\.git\info\exclude" "docs/ai/"
Add-Content "$PROJECT\.git\info\exclude" ".cursor/"

Automation: The setup-new-project.ps1 Script

To make this process repeatable, I developed a robust automation script. It handles directory creation, junction mapping, and Git exclusion in one go.

param (
    [Parameter(Mandatory=$true)] [string]$ProjectPath,
    [Parameter(Mandatory=$true)] [string]$ProjectName
)

$ToolkitRoot = "C:\ai-workspace\my-ai-toolkit"
$ProjectContextDir = "$ToolkitRoot\configs\projects\$ProjectName\docs\ai"

# 1. Ensure project context directory exists in toolkit
if (!(Test-Path $ProjectContextDir)) {
    New-Item -ItemType Directory -Path $ProjectContextDir -Force
    Write-Host "Created new context directory for $ProjectName" -ForegroundColor Cyan
}

# 2. Create local docs/ai path if it doesn't exist
$LocalAiPath = Join-Path $ProjectPath "docs\ai"
if (!(Test-Path (Split-Path $LocalAiPath))) {
    New-Item -ItemType Directory -Path (Split-Path $LocalAiPath) -Force
}

# 3. Create Junctions
$Mappings = @{
    ".agent"  = "$ToolkitRoot\configs\.agent"
    ".cursor" = "$ToolkitRoot\configs\.cursor"
    "docs\ai" = $ProjectContextDir
}

foreach ($Key in $Mappings.Keys) {
    $Dest = Join-Path $ProjectPath $Key
    if (!(Test-Path $Dest)) {
        New-Item -ItemType Junction -Path $Dest -Target $Mappings[$Key]
    }
}

# 4. Git Exclusion
$ExcludePath = Join-Path $ProjectPath ".git\info\exclude"
if (Test-Path $ExcludePath) {
    $Entries = @(".agent/", ".cursor/", "docs/ai/")
    foreach ($Entry in $Entries) {
        if (!(Select-String -Path $ExcludePath -Pattern [regex]::Escape($Entry))) {
            Add-Content $ExcludePath "`n$Entry"
        }
    }
}

Write-Host "Setup complete for $ProjectName. AI Memory is now active." -ForegroundColor Green

Strategic Insights: Optimizing the Workflow

Implementing the technical plumbing is only half the battle. To truly leverage "AI Memory," you must change how you interact with the IDE.

Context Management

AI models have a "context window" (the amount of text they can process at once). If you feed it too much irrelevant information, it loses focus. By separating docs/ai/ into specific files (Requirements vs. Implementation), tools like Cursor can use RAG (Retrieval-Augmented Generation) to only pull the relevant documentation for your current task.

Slash Command Synergy

With this setup, my daily workflow involves high-level slash commands:

/new-requirement: The AI reads the requirements/ doc, asks clarifying questions, and updates the planning/ phase.
/code-review: The @security-auditor agent scans my changes against the implementation/ guidelines stored in the AI memory.
/debug: The system activates specialized debugging agents that have full knowledge of our architectural patterns.

Troubleshooting Common Issues

Permissions: On Windows, creating Junctions usually requires an elevated PowerShell prompt. Run as Administrator.
Path Lengths: Deeply nested structures in docs/ai can sometimes hit the 260-character limit on older Windows versions. Enable "Long Paths" in Windows Registry if necessary.
Syncing Toolkits: When updating the subtrees in your central repo, you might need to re-verify that the Junctions haven't broken (though they rarely do unless the source folder is deleted).

Conclusion: The Future of Autonomous Development

By treating "AI Context" as a first-class engineering artifact—just like source code or infrastructure as code—we move away from using AI as a simple autocomplete tool. We transition into having a Digital Resident Engineer who understands our specific codebase as well as we do.

The combination of ai-devkit and antigravity-kit, managed via a centralized and isolated local setup, provides the perfect balance: deep contextual awareness for the AI and a clean, professional repository for the team.