RoBrain is an open-source memory and judgment layer for teams that use AI coding agents. Its distinctive unit is not a chat transcript or a loose “fact,” but an engineering decision: what the team chose, why it chose it, which alternatives it rejected, which files were affected and whether the decision is still active. The same Postgres-backed record can be surfaced to Claude Code, Cursor, GitHub Copilot, Codex CLI and Hermes.
That focus solves a narrow but expensive problem. A coding agent may remember the current convention yet still recommend a library, migration or architecture the team previously rejected. Ordinary rules files often preserve the winner but omit the losing options and their reasons. RoBrain makes those vetoes queryable and can warn before work begins. It does not make stored decisions correct forever: capture errors, stale constraints and organizational disagreements still require human governance.
How the decision-memory loop works
developer + coding agent sessions
|
v
passive capture
redact -> classify -> extract
|
v
Postgres decision ledger
choice / rationale / rejected[] / files / state
| |
v v
pre-task recall scheduled synthesis
veto + context conflicts + drift
| |
'---------+----------'
v
review / supersede / export
|
git outcome signal
The diagram separates capture, storage, retrieval and judgment because each fails differently. A classifier can miss a decision. Extraction can invent a rationale. Retrieval can return a related but irrelevant veto. Synthesis can flag a legitimate change as a contradiction. A useful pilot measures every stage instead of treating “the agent remembered something” as sufficient evidence.
RoBrain versus simpler project memory
| Approach | Strength | Typical failure | Best fit |
|---|---|---|---|
| CLAUDE.md, AGENTS.md or editor rules | Transparent, reviewable in git, no service | Manual upkeep; rejected options and dates are often missing | Small or young repository with stable conventions |
| Chat or editor auto-memory | Low setup and personal continuity | Local to a user/tool; weak team governance | Solo work where cross-tool sharing is unnecessary |
| Generic vector memory | Flexible semantic recall | Chunks may retrieve prose without lifecycle or veto semantics | Broad knowledge recall beyond decisions |
| RoBrain | Structured rejected alternatives, lifecycle, cross-tool store and synthesis | Operational overhead and risk of polluted durable memory | Multiple developers, multiple agents and recurring architectural debates |
RoBrain’s own guidance is refreshingly specific: if a project does not have multiple developers or tools, enough history for contradictions to accumulate, or repeated rejected proposals, a static rules file may be enough. That is a useful disqualifier. Memory infrastructure should earn its place by reducing rework, not by adding another database because “agents need memory.”
What is actually stored
| Field | Why it matters | Review question |
|---|---|---|
| Decision | States the chosen constraint or approach | Is it specific enough to apply without freezing unrelated work? |
| Rationale | Preserves the conditions behind the choice | Is the reason observed evidence, preference or speculation? |
rejected[] | Lets retrieval target options that should not be casually reintroduced | Does each rejection include a dated, falsifiable reason? |
| Files and provenance | Connects memory to its source and affected surface | Can a reviewer trace the record back to a session or change? |
| Lifecycle | Distinguishes active, superseded and invalidated guidance | Who may change state, and is the replacement linked? |
| Relations | Connects conflicts, extensions and related decisions | Is the graph helping retrieval or merely producing noise? |
A rejected option should not become an eternal ban. “Do not use Redis” may have been correct during a cost freeze and wrong after the workload changed. The durable record should include scope, date, owner, evidence and an expiry or review trigger. RoBrain supports supersession and invalidation, but teams must define who exercises those controls.
Self-hosted architecture and data boundary
The free self-hosted path starts Postgres plus the Perception service in Docker, then wires supported editors through MCP, plugins or hooks. According to the official site, decisions remain in the team’s Postgres and full file contents are not ingested; short session excerpts, file paths and decision metadata may be stored. Secrets are scrubbed at capture and ingest. However, the default extraction and embedding path can still call external model providers using the operator’s API keys.
| Component | Data it sees | Operator control | Risk to test |
|---|---|---|---|
| Editor hook or MCP integration | Prompts, agent turns and project context selected for capture | Per-repository installation | Unexpected capture from sensitive sessions |
| Perception | Candidate turns and extracted decisions | Self-hosted container and API authentication | Misclassification, unpatched service or exposed endpoint |
| Postgres/pgvector | Decision corpus, excerpts, embeddings and metadata | Team infrastructure, backup and retention | Broad access, stale records and backup leakage |
| LLM/embedding provider | Payload required for extraction or vectorization | Provider choice; local models are supported | Third-party retention, residency and contractual limits |
| Rory Plans cloud | Cloud-tier processing and team data | Vendor account and plan | Verify current terms, region, roles and deletion path |
“Self-hosted” therefore does not automatically mean “no data leaves the network.” A fully local configuration using Ollama, LM Studio or vLLM can reduce outbound processing, but teams must verify the actual network trace and model configuration. Also protect database backups, API tokens, generated ledgers and observability logs; these may reveal architecture choices or past vulnerabilities even without source code.
Retrieval, veto scans and synthesis are different controls
The self-hosted Perception API exposes a deterministic POST /veto-scan that looks for literal mentions of active rejected options. This is predictable and inexpensive but can miss synonyms and indirect proposals. Supported integrations can add semantic retrieval for broader matching. At session start, an always-on summary supplies high-priority context. The scheduled robrain synth job scans the corpus for contradictions, stance drift and recurring entities; reviewers inspect results with robrain review.
| Mechanism | When it runs | Good at | Blind spot |
|---|---|---|---|
| Always-on summary | Session start | Stable high-level constraints | Context budget and stale ranking |
| Literal veto scan | Before a prompt/action in supported hooks | Known option names with deterministic behavior | Aliases, conceptual equivalents and vague prompts |
| Semantic search/inject | On demand or via integration | Related decisions expressed differently | False matches and missing provenance in the agent’s interpretation |
| Synthesis | Manual or scheduled batch | Corpus-wide drift and contradictions | Requires human review; not a real-time policy engine |
| Git outcome feedback | After reverts are observed | Demoting decisions associated with failed outcomes | A revert is an imperfect proxy for decision quality |
How to read the VetoBench claim
RoBrain publishes VetoBench, a benchmark designed around a useful question: when a task invites an approach the team previously rejected, does the coding agent propose it again and cite the earlier reason? The official July 2026 results report zero rejected re-proposals for RoBrain across archived test runs, while no-memory conditions repeatedly resurfaced vetoed approaches. The repository includes prompts, retrieved context, responses and verdicts, which is stronger evidence than an uninspectable marketing percentage.
It is still a vendor-created benchmark with synthetic scenarios, selected models and a particular ingestion pipeline. It demonstrates that structured veto retrieval can work under those conditions; it does not prove production incident reduction for every repository. Re-run a representative subset with your model, language, rules, history size and integration. Include adversarial cases: renamed libraries, a veto that has expired, two teams with conflicting constraints, and a decision whose rationale contains a secret-like string.
A practical two-week evaluation
- Choose one repository. Prefer a codebase older than six months with at least two active developers and documented reversals.
- Build a gold set. Select 20 decisions: ten active, five superseded and five rejected alternatives. Record the authoritative issue, ADR or pull request for each.
- Warm-start carefully. Import only reviewed decisions. Do not turn an entire chat archive into trusted memory.
- Run paired tasks. Give the same 15 realistic tasks to an agent with and without RoBrain context. Randomize order and keep model/settings fixed.
- Review every capture. Measure precision, missing rationale, wrong file scope, secret redaction and time to approve.
- Test lifecycle changes. Supersede three decisions and confirm old vetoes remain historical without blocking the replacement.
- Simulate failure. Stop Perception, rotate a token, restore a backup and confirm editor hooks fail safely without losing development work.
| Metric | How to calculate | Suggested pilot gate |
|---|---|---|
| Capture precision | Correct durable decisions / all captured records | At least 90% after review rules stabilize |
| Capture recall | Correctly captured gold decisions / decisions made | At least 80%; investigate misses by integration |
| Veto hit precision | Useful warnings / all warnings shown | At least 80% to avoid warning fatigue |
| Stale-memory rate | Invalid or superseded records surfaced as active / recalls | Below 5% |
| Repeated-rejection rate | Tasks that re-propose a known veto / eligible tasks | Materially lower than baseline |
| Review burden | Minutes spent reviewing per developer per week | Lower than time saved from repeated investigation |
These thresholds are starting points, not official guarantees. The business decision should use time saved and escaped rework. If the system prevents one costly reintroduced dependency but demands hours of weekly cleanup, its value depends on the cost distribution of those failures.
Governance: memory is shared infrastructure
| Role | Responsibility | Required control |
|---|---|---|
| Developer | Creates decisions and flags incorrect captures | Visible provenance and easy correction |
| Tech lead | Approves high-impact architecture memory | Review queue and ownership by subsystem |
| Security/privacy | Defines excluded repositories and data classes | Redaction tests, access logs, retention and deletion |
| Platform owner | Operates Postgres, Perception and integrations | Backups, upgrades, token rotation and monitoring |
| Auditor | Reconstructs why guidance changed | Immutable provenance plus supersession history |
Do not let passive capture silently establish policy. Label records as proposed, reviewed or authoritative; reserve automatic injection of strong vetoes for approved or high-confidence records. Segment projects and teams so a frontend experiment cannot become a company-wide prohibition. Add review triggers for dependency upgrades, incidents, regulatory changes and elapsed time.
Self-hosted versus Rory Plans cloud
The Apache-2.0 self-hosted edition provides the core decision system: capture, structured vetoes, lifecycle, synthesis, cross-tool retrieval, export and local operation. RoBrain’s official comparison says the Rory Plans cloud adds more automatic task-boundary injection, pre-commit conflict verdicts, team administration, a dashboard and richer conflict handling. Cloud access is tied to paid Rory Plans offerings rather than a simple standalone RoBrain price shown on the project page.
Before buying, verify the current live plan, included usage, overages, organization isolation, support, data controller, deletion process and export behavior. For self-hosting, price the less visible costs: Postgres, backups, model and embedding calls, upgrades, incident response and reviewer time.
Alternatives and when to choose them
| Option | Choose it when | Trade-off versus RoBrain |
|---|---|---|
| ADR files plus CLAUDE.md/AGENTS.md | You want git-native, human-authored decisions with minimal infrastructure | Stronger deliberate review; weaker passive capture and cross-tool proactive recall |
| Mem0 | You need a general-purpose memory API across applications | Broader memory primitives; rejected alternatives may require custom schema/governance |
| Zep/Graphiti | Temporal knowledge graphs and entity relationships are central | More general graph model; more work to create coding-decision workflows |
| OpenViking or file-oriented context systems | You want navigable project knowledge and explicit retrieval | Broader context organization; RoBrain is more specialized around vetoes and lifecycle |
| Custom Postgres + MCP | You have strong platform capacity and unusual policy needs | Maximum control; you own extraction, evaluation, hooks and maintenance |
RoBrain is most compelling when the rejected alternative is as important as the chosen convention. If the actual problem is documentation discovery, code search or personal notes, a narrower tool may have lower operational cost.
FAQ
Is RoBrain a coding agent?
No. It is a memory and judgment layer connected to existing coding agents. It stores and retrieves decisions; Claude Code, Cursor, Copilot, Codex CLI or Hermes still perform the coding work.
Can a solo developer benefit?
Yes, especially on a long-lived codebase where old mistakes recur across tools. However, a maintained rules file or ADR folder may be enough. Pilot against that simpler baseline.
Does self-hosting keep all data local?
The database and Perception service can run locally, but extraction and embeddings may call configured external providers. Use supported local models and verify network traffic if full locality is required.
Will a veto prevent the agent from acting?
Not universally. Literal scans and integration warnings supply context; behavior depends on the connected tool and tier. Treat them as decision support unless you have separately tested an enforcement path.
How should incorrect memory be handled?
Reject or edit the capture, preserve provenance, and mark obsolete records superseded or invalidated. Track false captures as an operational metric rather than quietly deleting evidence of pipeline errors.
Is VetoBench independent proof?
No. It is a transparent, vendor-maintained benchmark with archived receipts. It is useful evidence and a reproducible template, but production adoption should depend on a repository-specific paired evaluation.
Sources and verification
- Official RoBrain product page, architecture and comparison
- Official Apache-2.0 source repository
- Official concepts and memory model
- Official CLI and installation reference
- VetoBench methodology and archived evidence
- Official memory export format
- Product Hunt launch and maker explanations
- Model Context Protocol security guidance
- PostgreSQL client authentication documentation
Last reviewed July 26, 2026. RoBrain is evolving quickly. Confirm current integrations, commands, cloud terms, data processing and benchmark artifacts before production use.
