The problem is not that agents forget. It is that nobody wrote it down.
An AI coding session ends and its context evaporates. The reason you chose Postgres over Mongo, the migration that must run before the deploy, the endpoint that looks dead but is load-bearing — all of it lived in a conversation that is now gone. The next session, human or agent, starts from nothing and re-learns it the expensive way.
The usual answer is a pile of markdown in the repo. That works until two people edit it, until it goes stale, until it needs to be private to one project, or until you want to know when a decision was made and what it was attached to. Oprex holds that same knowledge inside the lifecycle — next to the requirements, issues, tests, and releases it is actually about — and hands it to your agent through MCP.
What "memory" means here
Documents
Long-form markdown. Architecture, the running work log of a vibe-coding session, anything a future reader needs in paragraphs. Written once, read whole.
Facts
Atoms that change. One sentence, one subject, a date it started being true. When it stops being true it is superseded by its replacement — kept, linked, and auditable, not overwritten.
Notes
Short sticky notes attached to an artifact. A warning, a “next time, don’t” — too small for a document, too important to lose.
Scoped, not shared by accident. Memory belongs to a tenant and can be gated to a project. An agent working on one client's project cannot read another's, and nothing is ever mixed into a model's training. See the Trust Center.
How an agent uses it, in four moves
Resolve the project
The agent turns the path you mention into a project id and pulls the memory index for it.
Load what matters
It reads the documents whose titles look relevant, plus the open issues — before writing a line of code.
Do the change
Now it is editing code with your architecture decisions and known traps already in context.
Write it back
What it learned becomes a memory update, a note, an issue, or a requirement — not a lost message.
A real session, shortened
The second session did not have to be told. That is the whole point: Oprex is the part of your AI workflow that persists.
What happens when a remembered fact stops being true
This is the part most “AI memory” features get wrong. They append. Six months later the project has three contradictory sentences about the same server and no way to tell which one is current — which is worse than having none, because now the agent confidently repeats the stale one.
melati are still active. The one saying it hosts the ecosystem is now wrong; the one about 6 GB is still true and is why it died.
→ oprex_remember { op: "add", kind: "incident", supersedes: ["mf_…"], reason: "Melati down 2026-08-06, workload moved" }
Recorded the incident, superseded the hosting fact, and confirmed the RAM fact rather than writing it again.Three things happened that appending cannot do: the outdated fact was replaced, not duplicated; the still-true fact was confirmed instead of restated; and the response told the agent which other facts on that subject it had left alive — so a third contradiction is visible immediately rather than three sessions later.
Oprex as the scribe for vibe-coding
Vibe-coding is fast and leaves no trail. You describe, the agent builds, it works, you move on — and three weeks later nobody can say what was decided or why. Oprex closes that gap without slowing you down, because the agent does the writing, not you.
- The work log writes itself. Ask the agent to keep a memory document for the session and it appends as it goes — what it tried, what failed, what it settled on.
- Bugs found in passing get filed. The thing the agent noticed but did not fix becomes an issue with a reproduction, instead of a sentence scrolled past.
- Intent survives the diff. A requirement records what the change was for; the test case and release link back to it, so the coverage matrix stays honest.
- Your teammates read it in the panel. Everything the agent wrote is normal Oprex data at member.oprex.id — editable, searchable, and visible to people who never opened a terminal.
Be explicit. Agents do not record by default and should not — silent capture of everything you type is a privacy problem, not a feature. Say what you want kept: "log this session to memory", "file that as an issue". A standing line in your CLAUDE.md makes it a habit.
The tools your agent gets
| Tool | What it does |
|---|---|
oprex_resolve_project | Turn a human path like indohrm/enterprise into the project id every other call needs. Always the first call. |
oprex_recall_memory | Search remembered facts — ranked over the statement itself, so a fact buried mid-paragraph is still found. The first call of a session, and the one that returns the ids you need to supersede something. |
oprex_remember | Write back what the session learned, as facts, in one transaction. A fact that replaces an older one must name it — the old one is superseded and linked, not quietly duplicated. |
oprex_memory_fact_history | One fact plus every change it went through, each revision holding the state before that change. Answers “when did we stop believing this, and why”. |
oprex_search | One ranked search across issues, tickets, requirements, specs, test cases, milestones and notes. Use before opening anything new, so the agent stops re-discovering what is already recorded. |
oprex_list_memories | List the long-form documents for a project — titles and slugs, cheap to scan before pulling one. |
oprex_get_memory | Read one document in full. This is where the agent gets architecture decisions, gotchas, and the running work log. |
oprex_create_memory | Write a new document. What an agent learns in one session survives into every session after it. |
oprex_update_memory | Amend an existing document instead of piling up near-duplicates. |
oprex_create_note | A short sticky note — a decision, a warning, a “next time, don’t”. Notes are for facts too small to deserve a document. |
oprex_create_issue | File the bug the agent just found, with the reproduction it already has in context. |
oprex_create_requirement | Record what the change was supposed to achieve, so tests and releases can be traced back to it. |
oprex_list_issues | Read the open backlog before proposing work, so the agent stops re-discovering known problems. |
The full set covers issues, requirements, specifications, test cases, milestones, releases, tickets, pipelines, and Autopilot — see MCP Integration for the complete list.
Connect it in one command
Create a key in your workspace under Settings → API keys, then:
claude mcp add --transport http oprex https://api.oprex.id/mcp \ --header "Authorization: Bearer <your-key>"
Cursor, Cline, Windsurf, and anything else that speaks MCP over HTTP use the same URL and header. The key carries your permissions — an agent can never see a project you cannot.
Give your agent a memory
The free plan includes MCP access. Connect it, work one session, and read back what it wrote.
Open your workspace See the numbers Read the guides