The thing that kills AI coding sessions
You open a terminal, fire up an AI assistant, and the first five minutes are wasted typing the same setup paragraph you typed yesterday. "This is an Express API, we use TypeScript, the auth layer is JWT, don't touch the legacy routes in /v1." Every. Single. Time.
It's not a huge deal in isolation. But it adds up, and more importantly it's the kind of friction that makes you reach for the AI less often than you should. If re-orienting the tool costs you five minutes, you start reserving it for "big" tasks and miss the smaller wins.
lac agent solves this with .lac-memory.json — a plain JSON file that lives at the root of your project and gets loaded automatically every time you run lac agent in that directory.
What the file actually does
When lac agent starts, it checks for .lac-memory.json in the current working directory. If it finds one, that content gets injected into the agent's context before anything else happens. Your stack, your conventions, your current task list — all of it is already there when the first prompt runs.
The file is just JSON. There's no special schema you have to follow to get basic value out of it. Here's a minimal version from one of my own projects:
{
"project": "inventory-api",
"stack": "Node 20, Express, TypeScript, Prisma, PostgreSQL",
"conventions": [
"Use zod for all request validation",
"Controllers stay thin — business logic goes in service files",
"All dates stored as UTC, converted at the API boundary",
"No raw SQL — Prisma only"
],
"do_not_touch": [
"src/legacy/v1 — kept for backward compat, frozen",
"prisma/migrations — never edit manually"
],
"current_focus": "Finishing the stock adjustment endpoint and its tests"
}That's it. The agent reads this and behaves accordingly from the first response. It won't suggest raw SQL. It won't propose adding logic directly in a controller. It won't wander into src/legacy/v1 unless you explicitly tell it to.
It also writes to the file
This is the part I find most useful. The agent doesn't just read from .lac-memory.json — it can update it during a session when something worth remembering comes up.
Say you're midway through a session and you land on a decision: "We're switching from bcrypt to argon2 for password hashing." You can tell the agent to remember that:
remember: we moved from bcrypt to argon2 for password hashing — update the memory fileIt will write that into conventions (or wherever makes sense given your structure) and from that point forward — including future sessions — it knows. No copy-pasting notes into a doc somewhere. The memory lives next to the code.
You can also ask it to update current_focus at the end of a session so tomorrow's you has a clean handoff:
update current_focus in memory: stock adjustment endpoint is done, next is the reorder alert logicTask tracking inside memory
Some people lean on the memory file as a lightweight task list. I do this on solo projects where pulling up a full project management tool feels like overkill. The structure looks something like:
{
"tasks": [
{ "id": 1, "title": "Stock adjustment endpoint", "status": "done" },
{ "id": 2, "title": "Reorder alert logic", "status": "in_progress" },
{ "id": 3, "title": "Webhook for supplier updates", "status": "todo" }
]
}The agent can update statuses, add new tasks when it discovers subtasks during a coding session, and report on what's outstanding. It's not a replacement for proper project tracking on a team, but for a solo sprint it's genuinely useful.
Committing the file (or not)
Whether you commit .lac-memory.json to your repo depends on what you put in it.
If it contains project conventions and architectural decisions — commit it. That information is useful to every contributor, not just you. It's basically a machine-readable version of the "how we work" section of your README, and the agent on anyone else's machine will pick it up automatically.
If you're using it for personal notes or active task tracking, add it to .gitignore. Or split the concern: commit a .lac-memory.json with the shared conventions, and keep a .lac-memory.local.json ignored for personal context. The agent picks up both.
I tend to commit the conventions block and ignore the task list. Works well enough.
Works with PlanMode and /multi
The memory file isn't isolated to basic lac agent sessions. When you run PlanMode — where the agent proposes a full plan before touching any files — it reads from memory to make sure the plan respects your project's rules. You're not reviewing a plan that suggests wrong patterns and then correcting it; the constraints are baked in from the start.
Same with /multi. When you split a big task across parallel agents, each spawned agent gets the memory context. The specialized agents don't work in a vacuum — they already know the conventions the project manager would expect them to follow.
One thing to keep in mind
The memory file is part of the agent's context window. If you write a novel in it — hundreds of lines of detailed notes — you're burning tokens on every single prompt. Keep it tight. Bullet points over paragraphs. The conventions that matter, not every decision ever made. Think of it like a good .editorconfig: it should be short enough that someone could read it in two minutes.
Getting started
If you already have lac agent installed (if not: pip install lac-cli), just create the file in your project root and run the agent as normal:
touch .lac-memory.json
# add your stack, conventions, current focus
lac agentThat's the whole setup. No flags, no config option to flip. The agent finds the file and uses it.
If you want to start from scratch and let the agent build the memory file for you, just tell it about your project in the first session and ask it to write what it learned to .lac-memory.json. Next session, it already knows.