Project memory

Project memory is what Masaro knows about your project beyond any single task: your stack, your conventions, the decisions you’ve made and why. It’s the difference between an agent that starts every session from zero and one that shows up already briefed.

The problem it solves

Every agent session starts amnesiac. You’ve told it “we use Drizzle, not Prisma” five times. You settled the error-handling pattern weeks ago, but tonight’s session cheerfully invents a new one. Without shared memory, every session re-derives (or re-guesses) your project’s ground rules, and no two sessions guess alike. That’s drift, and it compounds.

What memory holds

  • Stack and tooling: languages, frameworks, the libraries you’ve blessed and the ones you’ve banned.
  • Conventions: naming, file layout, testing patterns, “how we do things here.”
  • Decisions: the choices you’ve made and the reasoning, so they don’t get silently relitigated.

Memory accumulates as you work, from brainstorm sessions, task activity, and what you record. By session ten, Masaro knows your architecture; it isn’t a form you fill out on day one.

How memory is managed

Memory is plain files, not a black box. What Masaro learns lives as markdown files in your project. Open Settings → Memory to read every file, edit any of them, or delete what’s wrong. What an agent sees is exactly what you see.

Masaro is deliberately conservative about what gets written. Facts are captured only when they were explicitly stated or clearly agreed: “we’re using Drizzle” is memory; a passing question about Prisma is not. Generic programming knowledge never gets stored; your agent already knows how to center a div. And when a file grows unwieldy, Masaro compacts it (same decisions, denser prose) so the context agents pull stays sharp instead of sprawling.

How agents use it

When an agent connects over MCP and pulls a task, the workspace and project context comes with it, before the first line of code. Concretely, agents call get_workspace_context / get_project_context and receive memory alongside the task’s own details. The agent doesn’t have to ask which ORM you use. It knows, because you decided, once, and the decision stuck.

Memory keeps agents on the rails; it doesn’t drive. The task’s acceptance criteria define what done means; memory defines the house rules it gets built under. You can review and edit what Masaro has learned; it’s your project’s memory, not a black box.

What it isn’t

Not a copy of your codebase, and not a RAG index over your repo. Masaro stores intent and decisions: the things that aren’t in the code, or that the code alone can’t justify. Your agent already reads your code; what it can’t read is why.

Next: Epics, tasks & dependencies · The MCP hand-off