The most common architecture for AI platforms is the monolith. One large application that does everything: chat, code generation, document analysis, project management. It starts simple and ends in a tangled mess of competing concerns, where a bug in the sales module takes down the code editor.
ODIN takes a fundamentally different approach. Instead of one system that does everything, ODIN is six specialized hubs — each with a clear boundary, a defined contract, and a single area of expertise — connected by a shared memory layer called BrainDB and orchestrated by an intent-aware Router.
Why Hubs, Not a Monolith
The monolith problem is well-understood in traditional software engineering: tight coupling makes systems fragile, hard to extend, and impossible to reason about. The same problem applies to AI platforms, but with an additional dimension: AI systems need to maintain context across specialized domains without leaking responsibilities between them.
A legal analysis module should not silently modify sales commitments. A code generation tool should not override governance constraints. Each domain has its own rules, its own risk profile, and its own audit requirements. Mixing them in a single system means the lowest common denominator wins.
The architecture pattern ODIN follows is closer to what Martin Fowler describes as a bounded context in Domain-Driven Design: each hub owns its domain completely, with explicit interfaces at the boundaries. The difference is that ODIN's hubs share a governed memory layer (BrainDB) that provides cross-domain context without cross-domain coupling.
Hubs solve this by enforcing boundaries. Each hub has:
- A defined input/output contract: Every hub accepts structured intent and returns structured output with artifacts, memory writes, risk flags, and audit events
- Isolated responsibility: Hubs do not leak responsibilities or silently override each other
- Escalation protocols: If a hub is uncertain, it escalates rather than guesses
- Independent lifecycle: Each hub can be deployed, updated, and scaled independently without affecting the others
The Six Hubs
Academy Hub (Port 3001)
The training and onboarding engine. Role-based learning paths, governance-aware exercises, and progress tracking. Academy does not just teach people how to use AI — it teaches them how to use AI within a governance framework.
In practice, this means Academy adapts its curriculum based on the learner's role. A legal team member sees compliance-focused exercises. A developer sees coding-governance exercises. A sales manager sees data-handling and CRM governance exercises. Each path is generated from the same underlying knowledge base in BrainDB, but filtered through role-appropriate governance constraints.
Compass Hub (Port 3002)
The decision integrity engine. Captures every significant decision with rationale, alternatives, constraints, and stakeholder approval. Scores decisions on dependency impact and reversibility. Identifies organizational bottlenecks in decision flow. For a deep dive into how Compass works, see Compass: The Decision Integrity Engine.
What makes Compass distinctive is that it does not just record decisions — it evaluates them. Every decision gets scored on dimensions like reversibility (how easily can this be undone?), dependency impact (how many downstream systems are affected?), and stakeholder coverage (were the right people consulted?). Over time, Compass builds an organizational profile of decision quality that identifies structural bottlenecks: teams that are slow to decide, individuals who are decision bottlenecks, and patterns where decisions are made without adequate stakeholder input.
Assistant Engine — LUNA (Port 3003)
The universal interface. Voice and chat access to the entire Odin ecosystem. LUNA captures intent, classifies it via the Router, and dispatches to the appropriate hub with relevant context. Runs on local infrastructure (Whisper + Ollama) with cloud fallback for complex tasks.
LUNA is deliberately not a "smart chatbot." It is a dispatch layer with a conversational interface. When a user says "prepare for the Acme meeting tomorrow," LUNA does not try to handle the entire request itself. It classifies the intent (meeting preparation), identifies the relevant hubs (Sales Engine for materials, Legal Hub for contract status, BrainDB for Acme context), orchestrates the cross-hub workflow, and presents the aggregated result. The intelligence lives in the hubs. LUNA provides the interface.
Legal Hub (Port 3004)
Contract analysis, compliance validation, and legal guardrails. The Legal Hub can veto promises made by other hubs — if the Sales Engine generates a claim that violates compliance constraints, Legal flags it before it reaches the prospect.
This veto power is not a theoretical safeguard. It is an active part of the request pipeline. When the Sales Engine generates a proposal, the Legal Hub reviews it for commitments that exceed contractual authority, claims that violate regulatory constraints, and terms that contradict existing agreements. The review happens before the output reaches the user, not after. This prevents the common enterprise failure mode where sales promises create legal exposure that is only discovered during contract negotiation.
Sales Engine (Port 3005)
Context-aware sales material generation. Pulls from BrainDB for organizational knowledge, validates through Legal for compliance, and produces auditable artifacts with full provenance tracking. Every generated document carries metadata about what context informed it, what model generated it, and what governance checks it passed.
Coding Hub (Port 3008)
AI-assisted code generation, architecture decision records, and pull request management. Integrated with the Work Order system so every code change traces back to a defined objective. For the complete workflow from work order to deployed code, see From Work Orders to Shipped Code.
The Router: Intent Classification
When a user interacts with ODIN — typically through LUNA — their request hits the Router (Port 3010). The Router does not just pattern-match keywords. It classifies intent and determines which hub or combination of hubs should handle the request.
A request like "draft a contract for the Acme proposal" gets routed to the Legal Hub with context from BrainDB about the Acme prospect. A request like "is our authentication middleware following best practices?" gets routed to the Coding Hub with relevant codebase context.
How Intent Classification Works
The Router uses a classification model running locally (via Ollama) to analyze incoming requests across several dimensions:
- Primary domain: Which hub's expertise is most relevant?
- Secondary domains: Are there cross-hub dependencies?
- Context requirements: What BrainDB namespaces should be loaded?
- Risk profile: Does this request touch regulated or sensitive areas?
Multi-hub requests are also supported. "Prepare for the Acme meeting tomorrow" might trigger the Sales Engine for meeting materials and the Legal Hub for contract review, with results aggregated and presented through LUNA.
The Router's classification is itself audited. If you later need to understand why a request was handled by the Legal Hub instead of the Sales Engine, the classification rationale is in the audit trail.
BrainDB: The Shared Memory Layer
BrainDB is what makes the hub architecture work as a unified system rather than six disconnected tools. It is the organizational memory layer — a governed knowledge store where every hub can read and write context.
Key principles:
- Governed writes: Every write to BrainDB includes rationale (why this was written), ownership (who can change it), and dependencies (what relies on it)
- Namespaced storage: Knowledge is organized into namespaces (
brain/hubs/academy/config,brain/projects/acme/context,brain/decisions/auth-approach) so hubs access only relevant context - Provenance tracking: Every piece of knowledge has a complete history — who wrote it, when, what triggered the write, and what has changed since
This means when the Sales Engine generates a proposal, it draws on the same organizational knowledge that the Legal Hub uses for compliance checks and the Academy Hub uses for training materials. There is one source of truth, not six copies that drift apart.
The Namespace Model
BrainDB's namespace system deserves a closer look because it is the mechanism that prevents the "shared database" anti-pattern. In a naive shared memory architecture, every component reads and writes to the same tables, creating implicit coupling. BrainDB avoids this through structured namespaces:
brain/global/* # Organizational identity, mission, constraints
brain/hubs/<hub>/* # Hub-specific configuration and knowledge
brain/projects/<id>/* # Project-scoped context
brain/decisions/* # Cross-organizational decision log
brain/sessions/YYYY-MM-DD/* # Session-scoped memory (auto-expiring)
Each namespace has defined access patterns. The Sales Engine reads from brain/projects/<prospect>/* but cannot write to brain/hubs/legal/*. The Legal Hub can read any namespace (it needs full context for compliance review) but only writes to its own hub namespace and the decisions namespace. These access patterns are enforced, not conventional.
This model is inspired by the principle of least privilege applied to organizational knowledge, similar to how RBAC (Role-Based Access Control) works in identity management systems, but applied to AI agent memory instead of user permissions.
Semantic Search
BrainDB also supports semantic search via vector embeddings. When a hub needs context, it does not just query by namespace and key — it can search by meaning. "Find all decisions related to authentication architecture" returns relevant entries even if they use different terminology (SSO, OAuth, login, identity provider). This semantic layer is what makes cross-hub context assembly practical at scale. For a broader look at how ODIN handles organizational knowledge, see Enterprise Knowledge Management with AI in 2026.
Hub Rules
The hub architecture is governed by explicit rules:
- Hubs do not leak responsibilities — the Coding Hub does not make legal judgments
- Hubs do not silently override other hubs — if the Sales Engine and Legal Hub disagree, it surfaces as a conflict, not a silent override
- If uncertain, hubs escalate — guessing is not an acceptable failure mode
- Legal Hub can veto Sales promises — compliance trumps convenience
- Sentinel Hub can gate risky dependencies — supply chain security is a first-class concern
These rules are not guidelines. They are enforced at the architectural level. A hub that attempts to write outside its governed namespace will have the write rejected. A hub that returns output without the required audit events will trigger a governance alert. The system is designed so that violating these rules is harder than following them.
Cross-Hub Collaboration
The most powerful interactions happen when hubs collaborate:
- A work order in the Coding Hub triggers Compass to capture the architectural decision and Audit to record the governance trail
- A sales proposal from the Sales Engine gets validated by Legal and enriched with context from BrainDB
- A training completion in Academy informs Compass about team capability for future decision assignments
- An escalation from any hub triggers governance workflows that span multiple hubs with full audit trails
A Collaboration Example
Consider a practical cross-hub scenario. A product manager asks LUNA: "We need to add SAML SSO support for the enterprise tier. What would that involve?"
- Router classifies this as a multi-hub request: Coding Hub (technical assessment), Compass (decision capture), Legal (compliance implications).
- BrainDB provides context: existing authentication architecture, prior decisions about identity management, current customer commitments.
- Coding Hub analyzes the codebase and estimates scope: affected modules, required libraries, estimated effort.
- Compass surfaces related decisions: "Decision D-047 established OAuth2 as the primary authentication protocol. SAML support would need to coexist with this, not replace it."
- Legal Hub flags: "Enterprise SSO commitments may trigger data processing agreement amendments for tenant-specific identity providers."
- LUNA aggregates these responses into a structured assessment with technical scope, decision context, and compliance considerations.
No single hub could have produced this assessment alone. The value comes from the governed collaboration.
The Result
Six hubs, one brain. Each hub does one thing exceptionally well. BrainDB ensures they share context without sharing responsibility. The Router ensures intent reaches the right hub. And the audit trail ensures nothing happens in the dark.
This is not a modular monolith with artificial boundaries. It is a genuine service architecture where each component can evolve, scale, and be governed independently — while participating in a unified organizational intelligence layer. For a deeper exploration of how these specialized components create compounding intelligence, read the beehive effect: scaling organizational intelligence. And to understand the governance architecture underpinning this system, see AI governance without the bureaucracy.
The architecture is designed for organizations that take AI seriously enough to demand structure, governance, and auditability — without sacrificing the flexibility to evolve. To see how the hub ecosystem works with your data, on your infrastructure, visit our product page or schedule a demo.
The full hub ecosystem is available in every Odin deployment. Schedule a demo to see how six specialized hubs work as one system.