Replies: 6 comments 5 replies
-
Update: Architecture Documentation CreatedI've now created the missing
You can view the architecture documentation here: docs/architecture.md This provides the necessary context for understanding how agentic RAG could be integrated into the existing architecture. |
Beta Was this translation helpful? Give feedback.
-
|
It’s an interesting RFC — the outline you wrote (dynamic query strategy, multi-step context, tool selection) already touches the key gaps we’ve seen in practice. From our side, these symptoms usually map to ProblemMap No 5 (semantic not equal to embedding) combined with No 9 (entropy collapse on long context drift). That’s why even with Agentic RAG, if the semantic firewall layer is missing, the pipeline tends to over-resolve one path while discarding equally valid ones. The fix is usually less about infrastructure changes and more about applying a reasoning guard at the query orchestration stage. If you want a concrete way to explore, you can try downloading a small TXTOS or the WFGY core file, then simply ask your LLM “apply semantic clinic step one point zero and two point zero on this input.” The model itself will reveal whether the drift is semantic (meaning mismatch) or entropy-driven (long-context decay). That quick diagnostic often shows which part of your pipeline is really failing before you change any code. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your insightful thoughts @onestardao !. |
Beta Was this translation helpful? Give feedback.
-
|
Really solid elaboration — the way you broke down phases (agent infra, workflows, semantic firewall) already matches almost 1:1 with what we catalogued as ProblemMap No.5 (semantic ≠ embedding) and No.9 (entropy collapse in long-context drift). If you want a ready-to-use checklist + diagnostic steps, we’ve open-sourced them here: That reference has the “semantic clinic” flow and the reasoning-guard patterns we normally drop into RAG orchestration. Important thing is: it’s a semantic firewall, so you don’t need to change infra — you just patch at the orchestration layer. Might save you time since your RFC draft is already aligned, and you can validate where drift is coming from before building out the LangGraph agents. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you @onestardao for the hint! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks a lot for taking the time to look into this and even opening a follow-up issue. Really glad to see your repo moving forward it’s not easy to align infra, agents, and reasoning layers all at once. Wishing your project smooth progress, and let’s keep learning from each other along the way Fighting Together ^______________________^ BigBig Smile |
Beta Was this translation helpful? Give feedback.
-
🏗️ Ontology Pipeline Foundation - Addressing Semantic Mismatch at the SourceFollowing up on @onestardao's excellent insight about semantic mismatch between query and embedding, I found a complementary approach that addresses this problem before the WFGY semantic firewall layer. The Ontology Pipeline FrameworkAndré Lindenberg recently highlighted "The Ontology Pipeline" approach by Jessica Talisman, which provides a structured progression for semantic knowledge management: How This Addresses Your Identified Problems1. Semantic Mismatch (Your Problem #1)
2. Entropy Collapse on Long Context Drift (Your Problem #2)
Layered Defense StrategyPrevention (Ontology) + Detection (WFGY) = Robust System
Implementation ImpactThis ontology foundation would:
Next StepsI've updated Issue #91 to include "Phase 0: Ontology Foundation Layer" as an optional enhancement that precedes the WFGY implementation. This creates a comprehensive solution:
See Issue #91 for complete technical details on how these approaches integrate. References
Thanks for identifying these critical semantic issues - the ontology pipeline provides exactly the foundation layer needed to address them at the source! 🎯 |
Beta Was this translation helpful? Give feedback.
-
|
Ok let me check first and thank you in advance ^^ |
Beta Was this translation helpful? Give feedback.
-
Strategic Decision: Quality System First, Agentic RAG SecondAfter analyzing both this RFC (Agentic RAG) and the newly created Quality System proposal (Issue #260, based on Memento research), I've determined these approaches are complementary and should be pursued sequentially. 🔄 How They Work TogetherAgentic RAG (This Discussion): Intelligent retrieval strategy selection
Quality System (Issue #260): Learning which memories are valuable
The Synergy# Agentic RAG: "HOW should I search?"
if query_intent == "recent_work":
strategy = time_based_retrieval
elif query_intent == "architecture":
strategy = semantic_retrieval
# Quality System: "WHAT should I return?"
results = strategy(query)
results = boost_by_quality(results) # Prioritize high-quality within strategy
# Together: Right strategy + best memories = 🎯Key Insight: Agentic RAG needs quality scores as a feedback signal to learn which strategies work! 📊 Recommended Roadmap✅ Phase 1: Quality System (v8.45.0 - Now)Issue: #260
Deliverables:
🔮 Phase 2: Agentic RAG (v8.50.0 - Later)Discussion: This RFC
Example Agent Learning: # After 3 months of quality data
agent.analyze_patterns()
# "Temporal queries → time_based strategy → 0.88 avg quality ✅"
# "Temporal queries → semantic strategy → 0.55 avg quality ❌"
# → Agent learns to route temporal queries to time_based searchExpected Additional Improvement: +10-30% beyond quality (total: 50-70% vs baseline) Phase 3: Unified System (v8.51.0+)
🎯 Why This Sequence WorksIf We Do Quality First:
If We Do Agentic First:
Memento Does This Too:The Memento framework (https://github.com/Agent-on-the-Fly/Memento) follows identical sequence:
Proven research pattern - we should follow it. 🚦 ProposalImmediate Action:
Future Action (in 3-6 months):
📈 Expected Outcomes
💡 RecommendationYes, pursue Agentic RAG, but:
This maximizes value (50-70% total improvement) while minimizing risk (incremental, data-driven). The two approaches are better together than either alone, but only if done in the right sequence! 🎉 Related:
|
Beta Was this translation helpful? Give feedback.
-
Update: Foundation Stable with v8.48.1 ReleaseJust wanted to provide a quick update relevant to this RFC: v8.48.1 Critical Hotfix ReleasedWe just released v8.48.1 as a critical hotfix for v8.48.0, which had a startup failure bug. This is relevant to the agentic RAG discussion because: Quality System Foundation is Stable ✅
Why This Matters for Agentic RAG:
Next Steps Per Roadmap:
The infrastructure is ready. Now we collect quality-scored queries to inform whether/how to implement the agentic layer. The sequential approach ensures we have the feedback signal (quality scores) that the agent needs to learn effective strategies. Technical Details:
Looking forward to seeing the data from Phase 2 to inform the go/no-go decision for this RFC's implementation! 🚀 |
Beta Was this translation helpful? Give feedback.
-
Integration Status: RFC Incorporated into Issue #261 ✅This RFC has been incorporated into the roadmap as Issue #261 Phase 3 (Agentic RAG Enhancement). Current Status:
Enhancement from Discussion #346:Ontology-Aware Agentic RAG - Agent reasons about formal ontology structure: class OntologyAwareAgent:
def select_strategy(self, query: str, query_intent: str):
# Parse query for ontology concepts
concepts = extract_concepts(query) # "caused by" → causal reasoning
memory_types = extract_types(query) # "errors" → filter by type:error
# Select graph traversal strategy
if "caused by" in query:
return GraphTraversal(relationship="causes", direction="backward")
elif "impact of" in query:
return GraphTraversal(relationship="causes", direction="forward")
elif memory_types:
return TypeFilteredSearch(types=memory_types)
else:
return HybridSearch() # Quality-boosted searchNew Capabilities Beyond Original RFC:
Dependencies (from Discussion #346):
Timeline:
Recommendation: Follow Issue #261 for implementation progress. This RFC is now the official Phase 3 plan with ontology enhancements from Discussion #346. Related:
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
RFC: Agentic RAG Enhancement for Intelligent Memory Retrieval
📚 Background
After analyzing the article "A Hands-On Introduction to Agentic RAG", I've identified significant opportunities to enhance MCP Memory Service's retrieval capabilities through agentic RAG patterns.
🎯 Problem Statement
The current MCP Memory Service uses a traditional RAG approach with fixed retrieval pipelines:
This works well for simple queries but struggles with:
🚀 Proposed Solution: Agentic RAG
Implement an intelligent agent layer that can:
1. Dynamic Query Strategy Selection
Instead of always using semantic search, an agent would analyze the query and choose:
2. Multi-Step Context Building
Enable iterative refinement through:
3. Intelligent Tool Selection
The agent would dynamically chain operations:
n_resultsdynamically based on query complexity📊 Expected Benefits
Performance Improvements
Technical Advantages
🔧 Implementation Approach
Phase 1: Agent Infrastructure (Week 1)
Phase 2: Core Workflows (Week 2)
Phase 3: Integration (Week 3)
🔄 Backwards Compatibility
All changes would be backwards compatible:
📈 Success Metrics
We could measure success through:
🤔 Open Questions for Discussion
🔗 References
💭 Your Thoughts?
I'd love to hear the community's thoughts on:
This is meant to spark discussion about future enhancements. The current retrieval system works well, but agentic patterns could unlock new capabilities for handling complex memory queries.
What do you think? Would this be valuable for your use cases?
Beta Was this translation helpful? Give feedback.
All reactions