Company Brain — architecture map
A local AI layer that learns: an orchestrator and several specialist models, each with its own system prompt and rules, a memory layer, and a CRM — one app, one UI. Today the AI part is done by EMODA AI and the CRM by Compass; these maps show the target. High level: no technology is chosen yet. Details in the README .
1 · The whole system 2 · Where each part comes from 3 · Flow 5: the AI in the CRM 4 · The memory layer
Solid arrow: request or data moving forward · dashed arrow: result coming back · coloured arrow: CRM, memory or offline flow.
1 · The whole system
Flow 1 (a question), Flow 5 (the AI using the CRM), Flows 2–3 (onboarding a source), Flow 4 (nightly reinforcement) and the shared training and promotion.
DAYTIME · FLOW 1 — a question, end to end · FLOW 5 — the AI working in the CRM FLOWS 2–3 · ONBOARDING A SOURCE (once per source) FLOW 4 · NIGHTLY REINFORCEMENT (asynchronous) TRAINING & PROMOTION — Flow 3 (v0) and Flow 4 Domain owner / staff approve rules · review sources User one app, nothing to select Unified UI — one app chat: streaming · votes · corrections · exports CRM pages: leads · deals · projects · tasks Conversation log every turn: question, calls, results, answer, votes Orchestrator own system prompt + rules · tools plan · route · bounded loop · compose answers only from data read in the turn CRM API leads · deals · finances · projects tasks · hours · history grant-only permissions CRM database the brain's own data, read and written through the CRM API only MEMORY LAYER (map 4) Prompts & rules a system prompt per model rules by scope: orchestrator, each specialist, review model proposed → active → integrated Knowledge definitions · aliases · known names glossary · formula hints source documentation RAG over documents & files facts · entities SPECIALIST MODELS — one per source, own prompt + rules DB → SQL for its schema Customer CRM → its API calls ERP → its API calls Other tools ClickUp, Office… → API calls Files → search and read documents Guard / executor read-only · allowed tables, endpoints, folders user's permissions · size and time limits Connectors database · API · file share · cloud drive CUSTOMER SOURCES (read-only) Databases / BI customer schemas Customer CRM via API ERP via API ClickUp · Office · … any system with an API Local files file shares Cloud files Drive and similar approvals question · vote · correction answer (streamed) CRM pages question + recent turns answer + table + record links saves every turn CRM tools reads / writes system prompt + rules proposed rules (corrections) tools: definitions, aliases sub-question rows / docs + summary proposed action result · error → one retry validated action rows / documents query · request · read indexed for RAG ② Automatic exploration DB: tables, columns, keys, relations, samples API: endpoints, auth, filters, pagination, rate limits files: folders, formats, update frequency Domain expert review what is real, what it means, which rules are fixed Source contract + docs what can be asked, what returns, fixed rules, access examples ③ Training examples question → correct action verified by running them ③ Test bench questions + expected results never used for training reads structure source documentation Review model (large, slow) ~200B, fits the 128 GB at night own system prompt + review rules re-reads every turn of the day judges each call, checks figures on the source, blames the right component: specialist, orchestrator, memory, prompt or rule Memory updates aliases, definitions, rule proposals Positive examples confirmed good calls Corrected examples wrong call + right one Example pool per specialist de-duplicated · checked against active rules threshold not reached → wait next night turns + votes + implicit signals memory updates Training small base model fine-tuned previous dataset + new examples reproducible: same data, same model Evaluation test bench (Flow 3) replay of real past chats (Flow 4) score per rule and question type Promote or discard only if better on both 0.0 → 0.x pilot → 1.x production fail → revise examples Model registry every version of every model active one per specialist older kept for rollback examples bench threshold reached active version served to the specialists 2 · Where each part comes from today
EMODA AI already runs the AI loop for one customer; Compass already is the CRM. The Company Brain merges them into one app and generalises the AI to any source.
EMODA AI — today Company Brain — target block Compass — today AI over one customer's BI · Rust, Loco, llama-server · on-premise DGX Spark dashed outline = new, built by neither advanced CRM · Rust, Loco, PostgreSQL · compass.hawkings.it Unified UI — one app chat + CRM pages, one layout, one login Chat UI SSE streaming · votes · full table · exports staff pages: users, rules, SQL console, sync Server-rendered UI 25 pages over one layout · Kanban boards side panels saving one field at a time Accounts & permissions who may see and do what, in UI and AI Accounts users and staff · signed session · CSRF staff see non-staff chats, write only their own Grant-only permissions organisations · nested groups · per-project grants API tokens act as their person · TOTP Orchestrator + tools plans, calls tools and specialists, composes Orchestrator with tools Qwen3-30B-A3B · interroga_db · cerca_valore definizioni · export · proponi_regola · ≤ 8 steps CRM tools for the AI the AI uses CRM functions as tools MCP server — 15 tools projects · deliverables · tasks · bulk action thin calls on the HTTP API · stdio + HTTP CRM module (API + database) the brain's own read/write data CRM domain + HTTP API Discovery → Lead → Deal → Project · tasks hours · instalments · expenses · lead history Memory layer — prompts & rules a system prompt + rules for every model Prompts & learned rules orchestrator_system.txt · db_system.txt rules by scope, author, keywords · states Memory layer — knowledge definitions · aliases · RAG · source docs Glossary, checks, lookup fields definitions · formula hints · fuzzy name lookup domain views v_movimenti · v_sellout · … Specialist models one per source, trained on it Fine-tuned query model ft-xi-db: LoRA on XiYanSQL-QwenCoder-7B writes the SQL for that one database Guard / executor validates and runs every action SQL guard + patches SELECT only · allowed tables and columns read-only transaction · 60 s timeout Connectors & sync databases · APIs · files · webhooks BI sync MS SQL → PostgreSQL mirror, every morning full · window · incremental Webhooks & scheduled jobs Cal.com bookings · GitHub READMEs timed rules (advance bookings) Credentials & settings secrets sealed · settings without redeploy Credential vault + settings AES-256-GCM under one installation key settings table · notifications · reports Training & evaluation examples · bench · replay · promotion Training & benchmark deterministic LoRA (seed 42) · 767 versioned tests replay of real chats before production Model registry every version of every model Models kept for rollback previous GGUFs in /opt/emoda/models one llama-server unit per model Nightly review model judges the day's chats, writes examples Source exploration & contracts Flows 2–3 for any new source 3 · Flow 5 — the AI working in the CRM
One question that needs both the CRM and a customer database, the system prompt and rules each model receives, and how a correction becomes a rule.
User asks in the unified UI “Which deals in negotiation have an overdue instalment, what did those customers buy last season? Follow them up.” Unified UI — chat + CRM pages same login and permissions for chat and CRM answer links open the CRM records in place Orchestrator loads its system prompt + active rules plans: CRM tools for deals and finances, DB specialist for last season's purchases Knowledge (memory layer) definitions: “overdue” = due date passed, unpaid aliases: customer names in CRM ↔ in the ERP glossary · formula hints · source docs read through tools, never pasted whole lookups PROMPTS & RULES (memory layer) Orchestrator system prompt + rules of scope orchestrator DB specialist system prompt + rules of scope DB Every other specialist own system prompt + rules of its scope Review model system prompt + review rules a rule reaches its author first, everyone once approved prompt + rules CRM tools (from Compass) search deals by stage · read finances create a task · update a record CRM API acts with the asking user's permissions writes: confirmation policy open CRM database leads · deals · instalments · projects · tasks overdue deals · create follow-up tasks records DB specialist “purchases of these customers last season” → SQL Guard / executor read-only · allowlists · limits Customer database / BI sales, orders, sell-out real names rows + summary answer + table + record links RULE LIFECYCLE — how a correction becomes a rule, then training (from EMODA) Correction in chat “overdue means unpaid after the due date” Proposed orchestrator calls propose_rule author accepts, edits or rejects Active for its author in that model's prompt for that user at once Active for everyone staff approve with one click (staff corrections: at once) Integrated absorbed by a training, rule switched off side states: trial (only in the replays that test it) · rejected active rules 4 · The memory layer
Ten parts: levels, typed items, entity graph, context assembler, conversation state, episodic memory, memory tools, nightly consolidation, effect measurement, permissions. The numbers match the README.
writes into memory → chat corrections source contracts documents → RAG sources → entities Orchestrator uses the memory tools and gets an assembled prompt Specialist models get their slice: schema docs, rules of their scope, aliases Review model (nightly) gets its prompt + review rules ⑦ Memory tools recall(query, scope) · remember(fact) propose_rule(text, scope) · resolve(name) the orchestrator decides when to look up ④ Context assembler collects the candidates for this call ranks: scope · entities · similarity · recency · how often it helped fits the model's token budget logs what went in, and why ⑩ Permission filter a memory inherits its source's permissions dropped if the asking user may not see it prompt read / write candidates allowed only MEMORY STORE ① Levels — the most specific wins turn — what this call is about conversation — focus, summary user — preferences, personal rules team — rules approved for a group company — definitions, fixed rules, facts source — contracts, schemas, docs ② Typed memory item type: rule · definition · alias · fact · preference provenance: correction · staff · review · document scope (level + model) · confidence valid from – to · version state: proposed · trial · active · integrated · expired permissions inherited from its source ③ Entity graph one customer, product, store across sources: CRM id ⇄ ERP code ⇄ DB name ⇄ file aliases and misspellings are edges “that customer” resolves across turns ⑤ Conversation state focus: entities · period · filters last query and its result “and last year?” → same focus, period moved back one year ⑥ Episodic memory solved cases: question → calls → approved answer similar ones become examples in the prompt and training data for Flow 4 System prompts — one per model orchestrator · every specialist · review model versioned, edited without a release; rules and knowledge are added per call by ④ NIGHTLY — keeping the memory clean (part of Flow 4) Conversation log every turn: calls, results, answer, votes, signals + the assembler's log ④ ⑧ Consolidation merges duplicates · finds contradictions promotes often-used memories up a level retires integrated, unused or expired ones rebuilds the entity graph from the sources Staff review queue contradictions to settle promotions to team or company rules proposed by the review ⑨ Effect measurement replay real chats with and without each rule or memory item no effect or worse → retire it better → keep, candidate for training merge · promote · retire decisions keep / retire