Most AI interfaces are glorified text boxes. You type a question, you get an answer, and the system immediately forgets the entire interaction. The next time you need help, you start from scratch.
LUNA — Local Understanding & Navigation Assistant — takes a fundamentally different approach. It is not a destination you visit. It is the connective tissue between your team and Odin's entire hub ecosystem.
What LUNA Actually Does
LUNA serves as the primary interface for interacting with Odin. But "interface" undersells it. LUNA is the entry point where unstructured human intent gets transformed into structured action across specialized hubs.
When you speak to LUNA or type a message, three things happen:
- Capture: Your input is transcribed (if voice) and preserved with full provenance — who said it, when, in what context.
- Classification: Odin's Router analyzes your intent and determines which hub or combination of hubs should handle the request.
- Routing: Your request is dispatched to the appropriate hub with the relevant context from BrainDB attached.
This means a single natural language request like "draft a contract for the Acme proposal we discussed yesterday" triggers a chain: LUNA captures the request, the Router identifies Legal Hub as the target, BrainDB provides the context from yesterday's discussion, and the Legal Hub generates the artifact.
The routing is not static. The Router is a trained intent classifier that understands the difference between "what does our vendor contract say about liability?" (Legal Hub), "what has our team decided about vendor risk policy?" (Compass Hub), and "write a script to extract liability clauses from PDFs" (Coding Hub). These three requests use similar vocabulary but require fundamentally different handling — and LUNA routes them correctly without you needing to know which hub does what.
The Local-First Stack
LUNA runs entirely on your infrastructure. This is not a philosophical preference; it is an architectural decision with concrete implications for compliance, latency, and data governance.
European organizations operating under GDPR face a specific challenge: voice interactions and conversational AI often contain the most candid and context-rich information in an organization — and under GDPR, that data must have a lawful basis for processing and must not leave the EU without appropriate safeguards. By running the entire LUNA stack on-premise, this concern is resolved architecturally rather than contractually.
Voice: Whisper (Local)
Speech-to-text uses OpenAI's Whisper model, running locally. The 150MB model provides production-quality transcription without sending audio to any external service. Your voice interactions — which often contain the most candid and context-rich information — never leave your servers.
Whisper is available in multiple model sizes (tiny, base, small, medium, large). The default deployment uses the small model, which provides an excellent balance between accuracy and inference speed. For organizations with strict latency requirements or limited compute, the tiny model processes audio in near real-time on CPU. For organizations handling technical jargon, specialized vocabulary, or multiple languages, the large model provides significantly better accuracy. The tradeoff is inference time and memory: the large model requires approximately 10GB of VRAM versus 1GB for the tiny model.
Critically, Whisper runs in a gunicorn worker process on the same server as the rest of the Odin stack. There is no external API call, no network hop, and no audio data leaving your network perimeter.
Language: Ollama (Local)
LUNA's conversational intelligence runs on Ollama with Llama 3.2 (3B parameters). This local model handles intent classification, context extraction, and conversational flow with approximately 2GB of memory overhead. It is fast, private, and does not require internet connectivity.
The 3B parameter model is deliberately chosen for this role. Larger models provide better reasoning for complex tasks — and Odin routes complex tasks to those larger models via the appropriate hubs. But LUNA's job is conversational interface and intent routing, not deep reasoning. A 3B model handles this with sub-200ms response times on modern hardware, giving interactions a natural, responsive feel.
For organizations that want more capable local conversation, Odin supports swapping the LUNA model to any Ollama-compatible model: Llama 3.1 (8B or 70B), Mistral, Phi-3, or Qwen 2.5. The tradeoff is memory and latency. The architecture is designed so this is a configuration change, not a code change.
Embeddings: nomic-embed-text (Local)
Semantic understanding uses the nomic-embed-text model (274MB) for local embedding generation. When LUNA needs to find relevant context from BrainDB or match your request against organizational knowledge, it does so without external API calls.
Text embeddings are vector representations of text that capture semantic meaning — allowing the system to find contextually relevant information even when the exact words don't match. This is what enables LUNA to understand that "the Q3 vendor negotiation" and "the Acme contract discussions in September" refer to the same thing.
Embeddings are generated at write time (when context is stored in BrainDB) and at query time (when LUNA searches for relevant context). Both operations happen locally, which means your organizational knowledge graph — the accumulated semantic structure of what your company knows and has decided — never leaves your network.
Fallback: Cloud (When Necessary)
For tasks that genuinely require frontier model capabilities — complex reasoning, nuanced document analysis, creative generation — LUNA can fall back to Claude or other cloud providers. But this fallback is explicit, audited, and opt-in. The default path is always local.
When a cloud fallback occurs, LUNA logs it as a distinct audit event with the rationale. Your GDPR Data Protection Officer can review exactly which requests were processed by cloud providers and make an informed assessment of the legal basis. This is categorically different from a cloud-first system where you have no visibility into where data went.
Surfaces
LUNA is available wherever your team works:
- Command Center: Integrated chat interface within Odin's web application, with conversation history and hub dispatch visualization
- REST and WebSocket APIs: For custom integrations, automated workflows, and embedding LUNA in your own internal tools
- CLI: The
cliffcommand-line tool for developers who live in the terminal
Each surface connects to the same underlying LUNA service, which means context is shared across all interaction modes. A conversation started in the Command Center can be continued from the CLI without losing context. A work order created via API is visible in the Command Center alongside those created through voice.
This surface-agnostic architecture matters for adoption. Different roles in your organization work differently. Developers prefer the CLI. Managers prefer the web interface. Voice suits the moments between focused work blocks — a quick request while reviewing documents, a status query during a commute. LUNA meets people where they are without creating isolated data silos per surface.
Intent Classification: How LUNA Decides Where to Send Things
The routing layer deserves more attention than it typically gets in product descriptions. When LUNA receives a request, the Router performs a multi-step classification:
- Domain identification: Is this a technical task (Coding Hub), a governance task (Compass Hub), a legal task (Legal Hub), a learning task (Academy Hub), a financial task (Finance Hub), or a general query?
- Artifact identification: Does this request require generating a document, writing code, making a decision, or retrieving information?
- Context attachment: What organizational memory is relevant to this request? Which prior decisions, which team preferences, which known constraints should be included in the hub dispatch?
- Escalation check: Does this request involve a decision that exceeds the agent's authority? Does it touch a restricted area? Does it conflict with an existing governance rule?
Steps 3 and 4 are what separate Odin's routing from simple intent classification. A routing system that just identifies domain and dispatches is straightforward to build. A routing system that also attaches relevant organizational memory and applies governance rules is what makes the difference between an AI interface and an AI governance layer.
Governance by Default
Every interaction with LUNA creates an audit event. This is non-negotiable and cannot be disabled. The rationale is simple: if your AI interface is capturing organizational context and routing decisions, there must be a record of what happened.
Specifically, LUNA logs:
- Every transcription with source attribution
- Every routing decision with the classification rationale
- Every hub dispatch with the context provided
- Every response returned to the user
This audit trail is not about surveillance. It is about organizational learning. When a routing decision was wrong, when a hub response was inadequate, when context was missing — the audit trail tells you exactly what happened so you can improve the system.
This architecture aligns directly with the EU AI Act requirements for transparency and record-keeping on high-risk AI systems. Article 12 of the AI Act requires that high-risk AI systems automatically record events (logging) "to the extent such logs are technically feasible." LUNA's audit architecture satisfies this requirement by design. Organizations subject to the AI Act's high-risk classification — which includes AI used for employment decisions, credit assessments, and critical infrastructure management — can demonstrate compliance through Odin's immutable audit trail.
For a detailed look at how the audit architecture works and what the logs contain, see our security and compliance documentation.
What LUNA Is Not
LUNA is not an autonomous agent that takes actions without approval. When a request requires action — generating a contract, writing code, making a purchase decision — LUNA routes to the appropriate hub, which applies its own governance rules including approval workflows and risk flagging.
LUNA is not a replacement for thinking. It captures and routes, but the judgment calls remain with your team. The Compass Hub can flag that a decision increases founder dependency. The Legal Hub can veto a Sales promise. LUNA facilitates these governance checks; it does not override them.
LUNA is not a data silo. Everything it captures flows into BrainDB's governed namespace structure, where it becomes part of the organization's queryable memory with full rationale, ownership, and dependency tracking.
LUNA is not a general-purpose chatbot that tries to answer every question itself. When you ask about something that requires specialized reasoning — legal interpretation, financial modeling, architectural decisions — LUNA routes to the appropriate expert hub rather than generating a plausible-sounding but potentially incorrect answer on its own. This is a deliberate design choice: the value is in routing correctly, not in appearing capable of everything.
Practical Integration Patterns
Organizations that get the most value from LUNA typically integrate it into three workflow patterns:
Capture during meetings: LUNA's voice interface is particularly valuable during discussions where important context and decisions are generated but rarely systematically captured. A project review meeting produces decisions, risks, and action items. With LUNA active, these flow directly into BrainDB with speaker attribution — creating an organizational record that survives personnel changes.
Query before deciding: Before making a significant decision, querying LUNA for relevant organizational memory surfaces what has already been decided in adjacent areas, what constraints exist, and what the current consensus is on related topics. This reduces contradictory decisions and speeds up the process of getting context for new team members.
Delegate routine tasks: Requests that follow predictable patterns — status summaries, document drafts from templates, code snippets following established patterns — are ideal for LUNA delegation. The agent handles the mechanical work while your team focuses on judgment-intensive tasks.
The Interface Your Organization Deserves
The difference between LUNA and a conventional chatbot is the difference between a switchboard operator and a sticky note. One understands context, routes intelligently, and creates a record. The other gives you an answer and moves on.
Your organization's collective intelligence deserves an interface that treats every interaction as valuable context — not disposable chat. To understand how LUNA fits into the broader hub architecture, read about six hubs, one brain: how Odin thinks. If your team includes non-technical members who are new to AI tools, see not technical? no problem for how LUNA is designed for the whole organization. For data sovereignty considerations specific to European organizations, our AI data sovereignty guide is directly relevant.
Explore how Odin is designed on our product overview page, or request access to discuss your specific deployment context.
Want to see LUNA in action? Request a demo and experience the difference.