lac agent Remembers Your Project So You Don't Have To

The Re-Explaining Problem

There's a specific kind of friction that comes up every single day when you're using AI for coding. You open a new session, start asking questions about your project, and within two messages you're already typing something like: "Oh and by the way, this is a Django project, we use Postgres, all API responses follow this envelope format, and we never use print() for logging, we use structlog."

You're not asking the AI anything new. You're just re-establishing context you already established yesterday. And the day before that.

It's not a dealbreaker on its own. But it adds up. It breaks flow. And it means every session starts cold, even when the project is warm.

What .lac-memory.json Actually Is

When you run lac agent inside a project directory, it looks for a file called .lac-memory.json at the root of that directory. If it finds one, it reads it before doing anything else and loads that context into the session automatically. If it doesn't find one, it creates an empty shell you can start filling in.

The file is plain JSON. You can edit it by hand, or let the agent update it as you work. Here's what a real one might look like for a mid-sized API project:

{
  "project": "Evara API",
  "stack": ["Django 4.2", "PostgreSQL", "Redis", "Celery"],
  "conventions": [
    "All responses use the standard envelope: { data, error, meta }",
    "Use structlog everywhere — never print()",
    "Feature branches only, never commit directly to main",
    "Tests live in tests/ and mirror the app/ directory structure"
  ],
  "key_files": [
    "app/core/response.py",
    "app/users/serializers.py",
    "config/settings/base.py"
  ],
  "current_focus": "Migrating auth from session-based to JWT",
  "notes": [
    "The payments module is frozen — don't touch it without asking",
    "Redis is only used for rate limiting right now, not caching"
  ]
}

That's it. No special syntax. No proprietary format. Just a JSON file that lives at the root of your repo alongside your .gitignore and README.

How It Changes a Session

The difference in practice is immediate. Instead of starting every lac agent session with a paragraph of context-setting, you just start working. The agent already knows your stack. It already knows you use structlog. It already knows the payments module is frozen. You skip straight to the actual problem.

When I added a current_focus field for a recent auth migration, the agent started anchoring suggestions around JWT without me having to remind it every time I jumped between the user serializer and the auth middleware. Small thing, but it saves the mental overhead of tracking what the AI does and doesn't know about your current sprint.

The key_files list is particularly useful. When you name files there, the agent prioritizes reading them for context when you ask something ambiguous. Ask "how does response formatting work?" and instead of guessing, it goes straight to app/core/response.py.

Letting the Agent Update Its Own Memory

You don't have to maintain .lac-memory.json yourself. During a session, you can just tell the agent to remember something:

remember that we added a new shared utility at app/utils/pagination.py — it handles all cursor-based pagination

The agent will write that into .lac-memory.json on its own. Next time you open a session, that utility is already in context. It's the closest thing I've found to a codebase that actually accumulates knowledge over time rather than resetting every morning.

You can also ask it to review what it currently knows:

what do you remember about this project?

It'll read back the memory file in plain language. Useful when you haven't opened the project in a week and you want a fast re-orientation before diving in.

It Plays Well with the Rest of lac agent

Project memory doesn't exist in isolation. It stacks with the other things lac agent already does.

When you use PlanMode — which forces the agent to lay out a full plan before touching files — it builds that plan informed by what's in memory. So if you've noted that your test directory mirrors the app directory, the plan will include the correct test file paths without you having to spell them out.

When you use /multi to split a task across parallel agents, each agent in that pool gets the same memory context loaded in. They're not starting from scratch. They know the project conventions before they write a single line.

And because the memory file is just a JSON file in your project root, it can go into version control. Your whole team can share it. Someone new joins the project, clones the repo, runs lac agent, and the AI already knows how the project works. That's a genuinely useful artifact to ship alongside a codebase.

A Few Things Worth Knowing

Keep the memory file focused. I made the mistake early on of dumping everything into it — full architecture diagrams, long historical notes, decisions we made six months ago. It slowed things down and diluted the actually useful context. The sweet spot is concise conventions, current focus, and key files. Maybe 30 to 50 lines of JSON at most.

The notes array is where I put things that don't fit elsewhere but are genuinely important. "Don't touch the payments module" is the kind of guardrail that prevents a costly mistake, so it earns a spot there. Random historical trivia does not.

If you're working across multiple projects on the same machine, each project gets its own .lac-memory.json in its own directory. The agent reads from wherever you launched it. No cross-contamination.

Getting Started

If you don't have lac-cli installed yet:

pip install lac-cli

Then navigate into any project and run:

lac agent

If there's no .lac-memory.json, you'll get a prompt to set one up, or you can create it manually and drop it in. Either way, by the end of your first session you'll have a memory file worth keeping. Commit it, iterate on it, and stop re-explaining your own project to your own tools.