tylerrecall
One interesting challenge has been balancing recall speed vs. depth. Raw vector search is fast but misses context. Full graph traversal finds everything but kills latency. The tiered approach lets us start fast and go deeper only when needed.
Always curious to hear how others are tackling agent memory!
RecallBricks is plug-and-play memory infrastructure for AI agents. It lets agents store and retrieve durable context – preferences, decisions, feedback, and relationships – independently from the LLM or agent framework being used.
Most existing approaches treat memory as either raw vector search or framework-specific abstractions. That works for demos, but breaks down for long-running or multi-tool agents. We wanted something in between: structured memory with metadata, relationships, and lifecycle rules that persist across sessions and runs.
Under the hood, RecallBricks uses a multi-stage recall pipeline (fast heuristics → contextual retrieval → deeper reasoning when needed). This allows agents to retrieve relevant context without reloading everything into prompts, while keeping recall latency low using pgvector.
One meta detail: once it was usable, I connected Claude to RecallBricks via MCP. Claude now retains memory across the entire multi-month build of RecallBricks itself. I've been using RecallBricks to build RecallBricks.
This is early but live. People are already using it in agent workflows, and I'm actively refining how memories are ranked, linked, and decayed over time.
I'd love feedback from people building agents or long-running AI systems. What kinds of context do your agents lose today? Where do current memory patterns break down? What would make a separate memory layer not worth using?
Happy to answer questions and discuss tradeoffs.
I'm working on RecallBricks (memory infrastructure for AI coding tools) and seeing similar problems: AI tools are great at answering questions about code right now, but they don't remember the conversation you had last week about why you chose this architecture over that one.
For documentation specifically, have you thought about combining the AI-generated docs with a memory layer that captures decision history? Like "this API endpoint exists because of issue #247 where users needed X functionality." That context makes docs way more useful than just describing what the code does.
Curious how you're handling the "outdated docs" problem mentioned above - do you have triggers to regenerate when code changes significantly?
The problem: Every time you switch between Cursor, Claude, ChatGPT, your AI forgets everything. You spend half your time rebuilding context instead of coding.
RecallBricks automatically captures context from your coding sessions and makes it available across all AI tools via semantic search. Works with Cursor, Claude Code, Continue.dev, GitHub Copilot, or any LLM.
Built the entire stack with Claude Code (meta, I know). Gas utility worker who taught myself to code, now shipping production infrastructure. Currently in private beta, launching publicly in a few weeks.
Tech stack: Render API, Supabase (Postgres + pgvector), Python/TypeScript SDKs, VS Code extension, MCP connector.
Would love feedback - especially from folks juggling multiple AI coding assistants.