Launching today
scritty
Shared, searchable memory for every AI coding agent
92 followers
Shared, searchable memory for every AI coding agent
92 followers
scritty is a terminal emulator that captures every CLI agent's conversation (Claude, Codex, Copilot, Antigravity, Ollama), indexes it into one searchable corpus you control, and serves it back to your agents over MCP and to you over the CLI. One session across desktop, browser, and mobile. Your captures stay on your machine.
Interactive
Free Options
Launch Team / Built With
scritty
The context loss between agents is real and nobody talks about it
enough. I've been using Claude Code heavily and the moment you hit
a usage limit mid-session the mental overhead of rebuilding context
somewhere else is brutal — you spend the first 10 messages just
catching the new agent up instead of actually solving the problem.
The MCP angle is the part that makes this different from just
"searchable logs." Agents querying each other's past turns rather
than starting cold is a genuinely different model. Curious how the
retrieval quality holds up on longer sessions — does it surface
the right past context or do you find yourself still needing to
manually point it at the right conversation?
Also the prompt.toml injection is underrated. Maintaining consistent
rules and persona across agent switches without copy-pasting is
something I'd use daily.
scritty
@l_build appreciate this! retrieval quality question is the real one cause searchable logs alone aren’t enough. under the hood it’s hybrid keyword + vector retrieval over captured exchanges, exposed back to agents over MCP, so the goal is to surface the few prior turns that actually matter instead of making you reconstruct the session by hand. it might seem counter-intuitive but I let the retrieved results shape the context in the prompt vs try to shove all (what I deem) relevant context in myself
The case I would test hard is stale or wrong memory, not just recall. If one agent records a bad debugging hypothesis and another agent asks about the same repo tomorrow, can I mark that capture as superseded or incorrect so it stops being retrieved?
For coding agents, I would want each memory hit to show source session, repo/branch, timestamp, and whether it was later contradicted. Local storage is a good default, but stale local facts can still send the next agent down the wrong path.
scritty
@tang_weigang agreed bad memory can be more dangerous than no memory. there are levers like provenance, relevance/confidence decay, and mark_noise to demote bad hits, but I wouldn’t claim there’s an explicit “superseded/contradicted” the idea is the substrate improves upon itself dynamically via these tools rather than hard deletes.
how does it actually capture the conversation from agents like Codex and Copilot, do you have to wrap the calls or does it hook into the terminal session itself?
scritty
@beyzaokhan works by being the terminal the agents run inside, not depending on vendor API(s). scritty detects active agent from process itself, captures exchanges in that terminal session, tags by provider, and indexes them locally. important to me because I wanted memory layer upstream of vendor lock-in and avoid dependency on things like spinners that are subject to UI updates making detection at 1 level down brittle at best
The context loss when you switch from Claude Code to another agent mid problem is exactly what kills me, so pulling it all into one searchable memory over MCP is a great idea. Does it keep the full transcript searchable or summarize once a session gets big? Congrats on shipping.
scritty
@i_sanjay_gautam that mid prompt/problem agent switch pain was exactly the trigger for building it. raw exchanges stay searchable as a source of truth, and there are summary/compaction tools (I'm pretty wary of summaries replacing underlying turns) I want summaries to help navigation not become a lossy substitute for the actual transcribed session(s)
...and thanks :)
the piece i keep waiting for. every agent has its own memory silo which means every session gets rebuilt from scratch. cross-tool memory should be a standard everyone shares. also the fact that it stays local instead of getting phoned home makes this ok to leave running.
question for v2: does the index know when two conversations are about the same thing but happened in different tools, or is it just full text search? that dedupe is where this gets scary useful.
scritty
@thenameisarian exactly and for v2 this is why scritty does hybrid retrieval instead of semantic only search. fuses lexical + semantic results with RRF, and you can search across sessions/providers instead of being stuck in one agent thread. in practice helps a lot when you remember exact term/file/function name sometimes, and only rough idea or hazy memory other times.
If I'm working across multiple client projects that shouldn't ever mix, is the corpus scoped per project/repo by default, or is it one global memory that I'd have to manually wall off? Worried about an agent on project A accidentally surfacing something it learned while I was working on project B.
scritty
@galdayan good question. i don’t want one giant memory blob either. today the real hard boundary is tenants/data dirs, not automatic per-project walls. sessions are private by default, and team visibility is opt-in. if client separation really matters, i’d use separate tenants/data dirs