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.
Two tiers: workspace and project
Memory has a base layer and a project layer. Workspace memory is the house rules for everything you do here (stack, conventions that hold everywhere), and it gets injected into every chat in the workspace. Project memory adds on top for chats scoped to that project, layering conventions specific to “the mobile app” on top of, not instead of, the workspace base. A chat with no project attached still gets workspace memory; you don’t need a project to start benefiting from it.
How memory is managed
Memory is plain files, not a black box. What Masaro learns lives as markdown files. Open Settings → Memory to read every file, workspace and each project side by side, 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 project’s context comes with it, before the first line of code. Concretely, agents call get_project_context and receive memory (stack, conventions, decisions) alongside the task’s own details; get_workspace_context covers the board’s shape. The agent doesn’t have to ask which ORM you use. It knows, because you decided, once, and the decision stuck.
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.