Overview
Nectr uses Mem0 to remember project patterns, architectural decisions, and developer-specific habits across PRs. Unlike the Neo4j knowledge graph (which tracks structural relationships), Mem0 stores semantic memories — natural language insights that Claude extracts after each review. Every time Nectr reviews a PR, it:- Searches Mem0 for relevant memories to include as context
- Extracts new learnings from the completed review and stores them for future PRs
Mem0 memories are scoped by
project_id=repo and user_id=developer. This means each repo has its own context, and each developer has a personal profile within that repo.Memory Types
Nectr extracts six types of memories (defined inmemory_extractor.py:17-24):
project_pattern
Architectural patterns confirmed by this PRExample: “This repo uses dependency injection via FastAPI Depends for database sessions”
decision
Approaches approved or rejectedExample: “PR #42: Rejected eager-loading users with all posts due to N+1 risk; approved lazy loading”
developer_pattern
Recurring issues for this developerExample: “@alice often forgets to close database connections in exception handlers”
developer_strength
Things this developer does wellExample: “@bob consistently writes comprehensive test coverage for edge cases”
risk_module
Fragile or security-critical filesExample: “app/auth/token_service.py is security-critical; changes here need extra scrutiny”
contributor_profile
Aggregated profile for this developerExample: “@charlie works on backend services (auth, payments). Strengths: API design, testing. Feedback: occasionally misses edge cases in error handling. Languages: Python, TypeScript.”
Memory Lifecycle
1. Search (Before Review)
When building context for a new PR, Nectr queries Mem0 for relevant memories.context_service.py:74):
- Project memories: Patterns/decisions relevant to this PR’s topic and files
- Developer memories: Patterns/strengths specific to the PR author
2. Inject Into Review Context
The retrieved memories are serialized and injected into Claude’s prompt.3. Agentic Tool Access
In agentic review mode, Claude can search memories on-demand via tools instead of receiving them upfront.search_project_memory
pr_review_service.py:302-309):
search_developer_memory
pr_review_service.py:311-318):
4. Extract (After Review)
After Nectr posts the review, it asks Claude to extract structured learnings.memory_extractor.py:26-58):
5. Store in Mem0
Each extracted memory is stored with project/developer scoping.project_id=repo_full_name(e.g.,"nectr-ai/nectr")user_id=developerfor developer-scoped memories,"project"for repo-wide memories
Implementation Details
MemoryAdapter
Thin async wrapper around Mem0’s sync client._run_sync() wraps calls in asyncio.to_thread() to avoid blocking the async event loop.
Graceful Degradation
If Mem0 is not configured (noMEM0_API_KEY), all operations no-op silently.
Configuration
Mem0 Setup
Set your Mem0 API key:Memory Management API
Nectr provides REST endpoints to view and manage memories:List Memories
Add Custom Memory
Delete Memory
View Project Map
Contributor Profile Updates
Special behavior:contributor_profile memories are additive — each new PR absorbs the existing profile and updates it.
Performance
Search Latency
Project memories: 200-500msDeveloper memories: 100-300msParallel: both complete in ~500ms
Extraction Time
Extraction prompt: 2-4 secondsStorage (5 memories): 500ms-1sTotal: ~3-5 seconds per PR
Example Workflow
Result: By PR #3, Nectr has built a rich context about the project’s auth patterns and Alice’s strengths/weaknesses. Future reviews will be more tailored.Related Files
app/services/memory_adapter.py— Mem0 client wrapper (view source)app/services/memory_extractor.py— Post-review extraction (view source)app/services/context_service.py— Context building for reviews (view source)app/api/v1/memory.py— Memory management API (view source)