rta-smriti-brain Keeps Agent Memory Local

rta-smriti-brain is Sulabh Dubey’s MIT-licensed Python project for local-first, evidence-aware project memory for AI coding agents. It deals with a very ordinary annoyance: agents forget, chats get stale, and repo facts need to be inspectable before code changes. The takeaway is simple: treat it as a project-reality layer beside Codex, not as an agent runner. For Codex, OpenAI’s coding agent, the interesting part is the boundary around CLI and MCP server launchers, not a promise that memory can replace review.

Check what the memory layer actually owns

Local-first project memory is project knowledge stored and reconciled on the developer’s machine, with evidence the agent can inspect instead of silently trusting a remote chat history.

That is the pitch in rta-smriti-brain’s v1 line. As of the August 31, 2026 source signal, the repo had 6 GitHub stars, was mainly Python, used the MIT license, and had last been pushed on August 27, 2026. Small project, sharp problem.

The current README describes v1.0.4-alpha as a maintenance prerelease for the v1 release line. The headline feature is not “a better search box.” It is what the project calls a deterministic Project Cognition projection: a way to reconcile indexed sources, bitemporal truth, observations, structured work state, decisions, and local multimodal evidence.

In plainer words: it tries to answer, “What does this project currently believe, and what evidence supports that?” That matters when a coding agent proposes a refactor based on an old design note, a half-finished ticket, or a file that changed yesterday.

The trap is to read “memory” as “autonomy.” The README is explicit that v1 does not execute project work, route models, or replace an agent harness. A harness such as Codex or Codex, Anysphere’s AI code editor, still does the acting. rta-smriti-brain is the inspectable layer beside it.

Notice the boundary around agent work

The most useful part of the project is its refusal to be everything.

It reports readiness, coverage, change impact, conflicts, and decision debt under explicit output budgets. Those are review-shaped outputs. They help a developer decide whether an agent has enough grounded context to continue.

That is a different mental model from “give the agent a bigger context window.” Bigger context can still be wrong, stale, or untraceable. A local project memory layer asks for evidence and conflict handling before the agent edits code.

This is why the project sits in the same conversation as smaller memory experiments like Decispher Gives Coding Agents Memory. Developers are not only asking agents to write code. They are asking them to remember what the repo has already decided.

The trap is to let memory calcify bad assumptions. If the memory layer says an old API is canonical, the agent may repeat that mistake with confidence. The useful pattern is not “trust memory.” It is “ask memory what it knows, then verify against the repo.”

Put it beside AGENTS.md, not inside one huge prompt

For Codex users, the natural place to connect this idea is the repo boundary.

AGENTS.md should still carry durable instructions: architecture constraints, test commands, style rules, permission notes, and review expectations. rta-smriti-brain is better imagined as evidence history and project state. One tells the agent how to behave in this repo. The other helps it understand what the repo currently appears to know.

A small rule can make that boundary clear:

# AGENTS.md

- Treat local project memory as evidence, not authority.
- Before editing code, state which files, decisions, or observations support the plan.
- If memory conflicts with the current working tree, trust the working tree and flag the conflict.
- Do not update memory, run MCP write actions, or change indexed sources unless the task explicitly asks for it.
- After edits, run the repo verification command and summarize failures before proposing more changes.

That is boring on purpose. It gives Codex a narrow operating contract without stuffing the whole memory system into every prompt.

A good first Codex loop is: ask for the relevant evidence, make one small change, run the repo’s normal tests, then ask the agent to compare the result against the original evidence. If your org is building stricter review habits around coding agents, the related training topic goes deeper on code review guardrails without turning every experiment into process theater.

The trap is prompt hoarding. Dumping every decision, ticket, transcript, and index hit into the agent prompt makes the run feel informed while hiding the thing you actually need: which evidence changed the plan.

Run it locally without trusting it yet

The safest first run is not on the repo you care about. Use a disposable copy, read the README and release notes, and keep the first connection read-only.

Here is a lightweight setup note you can paste into an issue or scratchpad before trying rta-smriti-brain with Codex:

## rta-smriti-brain local test note

Goal:
- See whether the memory layer can explain current project state with evidence.

Repo:
- Use a disposable clone or small fixture repo.
- Do not index secrets, customer data, private tickets, or production logs.

Agent boundary:
- Codex may read AGENTS.md and inspect generated memory outputs.
- Codex may not update memory or call write-capable MCP tools during this test.
- Any MCP server connection starts read-only.

Test prompt:
- Ask: What files and decisions matter for changing <small feature>?
- Ask: What evidence is stale, conflicting, or missing?
- Then make one low-risk edit and run the repo verification command.

Gotcha:
- Local-first does not mean risk-free. A local index can still expose secrets to an agent session if you index the wrong files.

If the repo has a normal verification loop, keep it boring:

git status --short
# run the repo's normal test or typecheck command here
git diff --stat

Do not skip that last git diff check. Memory tools can make an agent sound more certain, but the working tree is still where damage shows up.

Try the smallest useful loop

Clone it only after reading the current README, then run one read-only memory check against a disposable repo. If the output cannot explain its evidence and conflicts, do not let an agent use it to justify code changes.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Practical starter checklist

- [ ] Name the Codex artifact first: an AGENTS.md instruction, a Codex CLI verification loop, an MCP boundary note, or a skills handoff.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• How should teams start with Codex?

  Start by writing down one visible team rule for Codex, not a loose preference. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Codex artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a AGENTS.md instruction, MCP note, or verification checklist. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Codex teams deciding which AGENTS.md instruction, CLI workflow, MCP boundary, or verification loop to standardize next around “rta-smriti-brain Keeps Agent Memory Local.”
• Best first artifact: turn the named fix into an AGENTS.md rule, verification checklist, MCP note, or review receipt before the next automated run.
• Best comparison angle: compare the workflow against the current Codex CLI review loop, shell boundary, and evidence trail; keep the path that leaves the shortest auditable trail.

Further reading

• rta-smriti-brain — source
• Codex — Agent
• Google Search Central — helpful, people-first content
• developers.google.com: fundamentals using gen ai content

Where to go next

Start from the related training topic and make the first exercise prove scope, verification, and ownership in the PR body.