OpenExp
Description
Q-learning memory for Claude Code. Persistent memory that learns which context helps you get work done. Memories that lead to productive sessions (commits, PRs, tests) earn higher retrieval rank automatically. 16 MCP tools, hybrid BM25 + vector + Q-value scoring, local-first…
About
Q-learning memory for Claude Code. Persistent memory that learns which context helps you get work done. Memories that lead to productive sessions (commits, PRs, tests) earn higher retrieval rank automatically. 16 MCP tools, hybrid BM25 + vector + Q-value scoring, local-first with Qdrant + FastEmbed.
Details
- Author
- anthroos
- Categories
- Developer Tools, AI, Knowledge Base, Other
Jump to
Setup
Install OpenExp in your MCP client (Claude Desktop, Cursor, Windsurf, and others).
Repository: https://github.com/anthroos/openexp
Follow the installation instructions in the repository README, then restart your MCP client.
How did this happen? — a hippocampus for AI agents.
Capture trajectories raw. Grade only when reality returns its verdict. Build a labeled corpus of human-AI decisions tied to grounded outcomes.
Quick Start·How It Works·Pipeline·Publish·MCP Tools·Status
git clone https://github.com/anthroos/openexp.git cd openexp ./setup.sh
That installs the four hooks into Claude Code, brings up Qdrant in Docker, and registers the MCP server.
Prerequisites:Python 3.11+, Docker, jq.
No API key required for core functionality. Embeddings run locally via FastEmbed. An Anthropic API key is optional and only powers the two-prompt pipeline (anonymize + extract experience) when you publish.
To install the seed pack (a real 57-day B2B sales arc, anonymized) and try retrieval against a worked example, seeexp-inbound-acquisition-with-free-pilot— install instructions in its README.
When you close a deal, ship a feature, or lose a client —how did it happen? Which decisions, in what order, against which context, on which hypotheses? Today's AI agents can't answer that. They follow skills and instructions perfectly, but they don't accumulate grounded knowledge about how outcomes actually arrived.
OpenExp captures every human-AI decision as a step in a trajectory, links those steps into coherent journeys, and grades each journey retroactively when reality returns its verdict — a deal closes, a sprint ships, a payment lands. The result is a continuously growing labeled dataset of decisions tied to outcomes, ready to train domain-specific intuition.
A few terms repeat throughout. Settling them up front:
- Trajectory— an ordered timeline of decisions a human and AI made together over the life of one closed arc (a deal, a feature, an incident). The unit of data.
- Pack— a published, anonymized trajectory plus itsmeta.yaml. The unit of distribution. Lives in its own GitHub repo.
- Skill— how Claude Code installs and invokes a pack. Naming convention:openexp:<author>:<slug>.
- openexp-use— the universal applier skill that, given an installed pack, reads its trajectory and answers your situation with a cited day.
- Not a Q-learning memory system.We tried Q-values for 8 months. Mean Q-value across 27,000 memories was 0.006; 90% of memories never received any reward signal. Removed on 2026-04-26.
- Not Mem0 / Zep / Letta.Those are storage layers. Storage is the easy part — semantic search alone doesn't tell you which memory actually led to a result.
- Not a replacement for skills or CLAUDE.md.Those sayhowto do something. OpenExp captureswhat happenedandhow it ended.
The Methodological Core: No Pre-Labeling
We donothand-craft features at step level (tone: urgent,signal: positive,hypothesis: probable). Pre-labeling injects the labeler's biases and corrupts the eventual training signal. Same hygiene as credit scoring: collect rich features per applicant, label only the terminal outcome (paid / didn't), let the model learn what predicts repayment from data alone.
- outcome—closed_won/closed_lost/failed/abandoned
- grade—0.0to1.0, school-style
Steps are stored raw. Authors annotate their own intent, hypotheses, and decisions ("I believed X at this point", "I chose Y because Z"). They do not label thesignal qualityof individual events — that's what the eventual model learns.
Casual analogy: kids in school don't get annotations on every homework problem. They turn in work, get a grade at the end of the term, and develop intuition over hundreds of grades.
Four hooks run automatically inside Claude Code:
Retrieval ranks via semantic similarity + BM25 + recency. No magic numbers. No Q-value scoring component.
When you decide to publish an experience — turn a real, terminal trajectory into a shareable artifact — two prompts do the work:
-
prompts/anonymize.md— takes raw trajectory data (transcripts, emails, decisions) and produces an anonymized YAML trajectory. PII is replaced by category tokens (<counterparty_cto>,<regulated_industry>,<value:10k-100k>,<local_currency>,day_+5) while structural features are preserved. The prompt enforces a reverse-identification rule: tokens narrow enough to identify a counterparty in jurisdiction must be generalized one level up before publication.
prompts/extract_experience.md— reads the anonymized trajectory plus the terminal outcome label and produces a facts-onlymeta.yaml(id, outcome label, duration, step count, category tokens, license). It deliberately refuses to writeapplies_when,searchable_summary, or a grade reason — those are interpretations and belong to the reader's Claude at use time, not to the publisher at publish time.
You run both prompts inside your own Claude Code, against your own Qdrant. Nothing is sent to a central server.
A published experience is itsown GitHub repo(one repo per pack), containing four files:
exp-<slug>/ ├── meta.yaml # facts only: id, outcome label, duration, category tokens, license ├── trajectory.anonymized.yaml # raw ordered timeline of N steps, anonymized ├── README.md # human-readable face for the catalog └── SKILL.md # Claude entry point — read first when skill is invoked
Each pack has its own repo so authors own their content (issues, license, versioning), and the engine repo stays focused on the runtime. Seedocs/publishing-a-pack.mdfor the author guide.
meta.yamlshape (abridged from the seed packexp-inbound-acquisition-with-free-pilot):
pack: id: d49e0997-8455-4d3c-90ca-d6cf54d0f662 author: ivan-pasichnyk license: MIT schema_version: 3 outcome: label: closed_won # fact, not interpretation closed_at: day_+57 duration_days: 57 step_count: 26 category_tokens: # what appears in the trajectory - <counterparty_cto> - <counterparty_pm> - <regulated_industry> - <e_signing_platform_local> # ...
Noapplies_when, nosearchable_summary, nograde_reason.Earlier schemas (v2) baked the publisher's read of the timeline into the artifact — one Claude's interpretation, frozen. Schema v3 inverts that: the pack ships raw, and the reader's Claude derives match on the fly against the reader's actual situation. Different readers, different contexts, different inferences from the same trajectory. SeeCHANGELOG.mdfor the full v2 → v3 transition rationale.
A published experience is anamespaced Claude Code skill:
openexp:<author-handle>:<experience-slug>
Drop the pack into~/.claude/skills/openexp:<author>:<slug>/(rename the directory to the skill-namespaced form on copy). Claude Code auto-discovers it on the next session.
# Install the seed pack as a skill git clone https://github.com/anthroos/exp-inbound-acquisition-with-free-pilot.git ln -s "$PWD/exp-inbound-acquisition-with-free-pilot" \ ~/.claude/skills/openexp:ivan-pasichnyk:inbound-acquisition-with-free-pilot
- Author identity is public— it signs the pack, like authorship on a research paper.
- Counterparty identity stays anonymized— the skill name reveals who created the pack, never who they were dealing with.
SKILL.mdinside the pack is the entry point — it tells the user's Claude when to invoke, how to use the trajectory, and what not to do (no fabrication, no de-anonymization, attribution required).
Seedocs/skill-architecture.mdfor the full naming convention, install flow, and design rationale.
This engine repo is the runtime — it does not bundle packs. Each published pack lives in its own repo (see theseed packas the reference shape). A web catalog atopenexp.aiaggregates published packs; an automated registry index is on the roadmap. A directory of installable experiences is the eventual surface, not a built product today.
Five focused tools (hippocampus model — write everything, retrieve selectively):
Pack-grounded predictions are how the system learns whether a published experience pack actually moves real-world outcomes. Without prediction/outcome pairs, pack value cannot be measured against any baseline, and any future experiment (cross-pack voting, embedding retrieval, new packs from new authors) is unfalsifiable.
Trigger criterion is sharp.Logging fires only when the assistant cites a pack's specificrelative_dayas the reason for an action recommendation. No day-citation → no log. Description of a situation without a recommendation → no log. This keeps the dataset honest and the cost low.
log_prediction(new path, schema_version 2)
log_outcome(new path, schema_version 2)
What's deliberately NOT in the schema:confidence(Claude-side confidence is uncalibrated until ≥30 outcome datapoints),alternative_action_if_no_packandpredicted_outcome_alternative(the same Claude that writes the prediction would invent the counterfactual, biased toward "the pack helped" — real ablation needs a pack-blind run, separate track).
Backward compatibility.The legacy schema (prediction,confidence,strategic_value,memory_ids_used) is still accepted by both tools. Callinglog_outcomewithoutcome+rewardcontinues to update Q-values formemory_ids_usedexactly as before. New-path entries are markedschema_version: 2in the JSONL row.
openexp search -q "stalled enterprise procurement" -n 5 openexp ingest # ingest pending transcripts into Qdrant openexp stats # Q-cache + collection stats
Pilot. Architecture freeze landed 2026-04-26.First experience seed published as a standalone repo:exp-inbound-acquisition-with-free-pilot— a 57-day inbound acquisition that closed at grade 1.0 (author's own assessment), anonymized to category tokens.
- The marketplace UI is just a directory in this repo. No web surface yet.
- Anonymization is conservative but not bulletproof for readers with deep domain knowledge.
- Schema may iterate — author-annotation fields (author_intent,author_hypothesis,author_decision) are a likely near-term addition.
- The eventual ML model trained on this corpus does not exist yet. ≥30 graded trajectories first.
Seedocs/redesign-2026-04-26.mdfor the full architecture freeze anddocs/claude-design-brief.mdfor the v2 product framing.
This project is in early stages. SeeCONTRIBUTING.mdfor setup and workflow.
The most useful contribution right now ispublishing a real experience. Take one of your own closed trajectories, run it throughprompts/anonymize.mdandprompts/extract_experience.md, and open a PR adding a new directory underexperiences/.
This is a web browser that enables your coding agent, such as Claude Code, to visit websites on your behalf and assist you in identifying bugs or creating UI test cases.
A server for Zero-Vector's hybrid vector-graph persona and memory management system, featuring advanced LangGraph workflow capabilities.
Provides AI assistants with persistent memory using ChromaDB vector storage.
Highly efficient context management for agentic AI: MCP code search, evidence packs, graph context, and memory for large projects.
Self-hosted long-term memory for AI agents: MCP server with hierarchical recall over pgvector.
A production-ready Model Context Protocol (MCP) server that provides a powerful, vector-native memory bank for AI agents. Built with the Protocol-Lattice Go Agent Framework, this server offers persistent, searchable, and shareable memory with multiple database backends.
Adaptive error memory & code intelligence MCP server with Hebbian synapse network, cross-project learning, and auto-error detection
A persistent memory server for Large Language Models, designed to integrate with the Claude desktop application. It supports tiered memory, semantic search, and automatic memory management.
Provides perfect memory for AI-assisted development by capturing project context snapshots, enabling natural language search, evolution tracking, and code intelligence.
A version-aware MCP server that prevents AI coding hallucinations by validating suggestions against your actual installed packages.
Sign in to leave a review
Use Google, GitHub, or an email account so ratings stay tied to real people.
No reviews posted yet.





