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
Memory
Long-form markdown. Architecture, the running work log of a vibe-coding session, anything a future reader needs in paragraphs.
Notes
Short sticky notes. One fact, one warning, one decision — too small for a document, too important to lose.
Everything else
Issues, requirements, specs, test cases, releases. The agent reads and writes these through the same connection.
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.
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_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://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 Read the guides