PandoraLM

# Why it exists

Most RAG systems rely on vector similarity alone. That works for simple factual questions, but it falls apart on questions that depend on relationships: who owns what, what changed after which meeting, which service calls which.

PandoraLM combines three ways of answering: vector RAG, GraphRAG over a knowledge graph, and agentic research through MCP tools. A Cognitive Router, inspired by Kahneman’s Thinking, Fast and Slow, decides which path each query deserves.

# How it works

• Pandora Core is the Node and React front end, built on AnythingLLM.
• Pandora Cortex is a Python FastAPI service that routes and orchestrates.
• MCP agents run as independent microservices, reached through an MCP bridge that turns stdio into SSE so they can scale as separate Kubernetes services.
• The data layer is PostgreSQL, LanceDB, Neo4j, Redis, MinIO and Keycloak.

Routing is tiered: a local semantic router answers in under 50 ms, a small gemma3:1b classifier in under 300 ms, and only the queries that need it reach a heavier solver model. Code is chunked along its syntax tree with tree-sitter. Meeting recordings stream to object storage and are transcribed and diarized, with workers scaling from zero on demand.

# Design decisions

• Knowledge layers. Content belongs to a System, Org, Team or User layer, and queries are pre-filtered by layer before retrieval, not filtered afterwards.
• Checked twice. Workers re-check relationship-based permissions to close time-of-check/time-of-use gaps.
• Safe ingestion. PII redaction and secret scanning run before anything is indexed.
• Quality gate in CI. Evaluation thresholds (faithfulness ≥ 0.8, answer relevance ≥ 0.7) fail the build when retrieval quality drops.

# Status

Maintained. The platform is complete as designed and kept as a reference system; it gets fixes rather than new features.