Memory Engine for engineers
Your coding agent shouldn't start from zero.
Store the facts, history, and instructions behind your work, then retrieve them by keyword, meaning, time, metadata, hierarchy, or hybrid ranking from the tools you already use.
curl -sSfL https://install.memory.build | sh && me loginFor engineers who are tired of re-explaining the same architecture, conventions, and decisions every time a coding agent opens a new session.
The cold-start problem
Every new session forgets the work you already did.
Your coding agent can read files and search the repo. It still starts cold.
It does not remember why auth changed last week, which migration pattern your project prefers, or what you ruled out yesterday.
So the first part of every session becomes context reconstruction.
What it remembers
Facts, history, and instructions - the memory your agent actually needs.
Facts
What is true about the system.
Names, contracts, constraints, dependencies, and implementation details your agent should not rediscover.
“We use gRPC for service-to-service calls. JWTs are signed with RS256. Migrations live in /db/changes.”
History
What happened, when, and why.
Decisions, rejected alternatives, migrations, experiments, and the reasoning behind the current state.
“We switched from REST to gRPC because streaming latency mattered. GraphQL was ruled out because caching cost became unpredictable.”
Instructions
How work gets done here.
Runbooks, style guides, review expectations, implementation order, and project-specific agent guardrails.
“For new endpoints: add tracing first, write the handler, update contract tests, then include the RFC link in the PR.”
Store the context your agent keeps missing.
Capture project facts, decisions, and instructions once, then retrieve them from the coding tools you already use.
curl -sSfL https://install.memory.build | sh && me loginRetrieval that goes beyond vibes
Search memory six ways at once.
Engineering context is not only semantic. Sometimes you need the exact identifier, the decision from last Tuesday, or everything under one subsystem.
Semantic
Find context by meaning when the wording does not match.
Keyword
Match exact services, APIs, identifiers, packages, acronyms, and names.
Temporal
Recover what happened before, after, or during a specific work window.
Metadata
Filter by project, owner, service, status, source, environment, or policy.
Hierarchy
Scope context to nested teams, systems, services, domains, or paths.
Hybrid
Fuse multiple signals so ranking reflects the shape of the question.
Example workflow
Capture once. Retrieve when it matters.
Store the decision
Move a service from REST to gRPC because streaming latency matters. Store the reason and rejected alternatives.
Add the instruction
Define the implementation path: tracing first, handler second, contract tests third, RFC link in the PR.
Retrieve from your agent
Next week, the agent can answer why the change happened and follow the project path without another long prompt.
Inspectable by default
Memory you can see, edit, and trust.
Memory should not feel hidden. Your engineering context lives in PostgreSQL, where it can be queried, debugged, migrated, backed up, and refined.
Start with one project
Give your coding agent a memory that survives the session.
Store the facts, history, and instructions your agent should not have to rediscover.
curl -sSfL https://install.memory.build | sh && me loginFAQ
Is this a replacement for code search?
+-
No. Code search finds what exists in the repo. Memory stores the decisions, conventions, constraints, and history around the code.
Does it only work with one coding assistant?
+-
No. It works through MCP clients, including Claude Code, Cursor, Windsurf, Codex CLI, and Gemini CLI.
What should I store first?
+-
Start with high-reuse context: architecture facts, recent decisions, rejected approaches, setup instructions, runbooks, and implementation preferences.
Can I inspect the memory?
+-
Yes. Memory is backed by PostgreSQL, so it is stored in an inspectable system instead of a vague black box.