Memory

Ante has a persistent memory system that lets the agent build up knowledge across conversations. Insights, patterns, and lessons learned are stored in memory files and automatically loaded into the system prompt for future sessions.

How it works

Each project has a memory directory at ~/.ante/projects/<project-id>/memory/, where <project-id> is a sanitized form of the project's absolute path. The key file is MEMORY.md — its contents are injected into the system prompt at the start of every conversation.

Auto-memory is enabled by default in the interactive TUI and disabled by default in headless -p runs. Use --enable-auto-memory to opt a headless run into memory, or --disable-auto-memory to turn it off for a TUI session.

Automatic behavior

As the agent works on your project, it:

1. Consults existing memory files to build on previous experience
2. Records new insights when it encounters common mistakes or useful patterns
3. Updates or removes memories that turn out to be wrong or outdated

MEMORY.md

The main memory file. It is injected into the system prompt up to a cap of 200 lines or 25 KB, whichever comes first (a truncation note is appended when it overflows). Keep it concise — link to separate topic files for details.

# Project patterns

- Use `anyhow::Result` for all fallible functions
- Tests go in `#[cfg(test)]` modules alongside code
- See [debugging.md](debugging.md) for common issues

# Known issues

- The auth module needs refactoring (tracked in #123)

Topic files

For detailed notes, create separate files and reference them from MEMORY.md:

memory/
├── MEMORY.md           # Main file (auto-loaded, max 200 lines)
├── debugging.md        # Detailed debugging notes
├── patterns.md         # Code patterns and conventions
└── architecture.md     # Architecture decisions

Memory types

When auto-memory is on, the agent is taught to save typed memories — each topic file carries name, description, and type frontmatter so future sessions can decide what is relevant. There are four types:

Type	What it captures
user	The user's role, expertise, goals, and preferences — so explanations and defaults can be tailored to them.
feedback	Guidance on how to work in this project, drawn from corrections and confirmations alike. Leads with the rule, then a Why and How to apply line.
project	Ongoing work, decisions, or constraints not derivable from code or git. Same Why / How to apply structure; relative dates are stored as absolute.
reference	Pointers to where current truth lives in external systems (a Linear project, a Grafana board, a Slack channel).

A typed topic file looks like:

---
name: bundle-refactors
description: Prefer one bundled PR for refactors in this area
type: feedback
---

For multi-file refactors here, prefer a single bundled PR over splitting.

**Why:** the user confirmed it — a validated call, not a correction.
**How to apply:** multi-file refactors touching this area.

The agent deliberately does not save secrets, in-progress task state, or anything already re-readable from the repo (code structure, file paths, conventions — those belong in AGENTS.md). Recalled memory is treated as background context that reflects a past moment, so the agent re-verifies any file, flag, or function a memory names before acting on it.

Guidelines

The memory system follows these principles:

• Concise — MEMORY.md is truncated after 200 lines, so keep it focused
• Semantic — Organize by topic, not chronologically
• Accurate — Update or remove outdated information
• Actionable — Record what worked, what didn't, and why

Memory is per-project

Memory is scoped to each project directory. Different projects have independent memory directories. This means the agent's accumulated knowledge about your React frontend won't interfere with its knowledge about your Rust backend.

Manual editing

You can edit memory files directly — they are plain markdown. The agent can also update them using the Write and Edit tools during a session.