An 8-package monorepo wiring Claude Code hooks, local memory, a code knowledge graph, and an SDK-backed org runtime together. Every number below is checked against the current source, not carried over from an old design doc.
Architecture
Claude Code talks to the CLI package over a hand-rolled stdio JSON-RPC loop. The CLI dynamically imports the other 7 packages as needed — most are libraries, not always-running services.
Modules
6 live under packages/@monomind/ (cli, hooks, mcp, memory, monograph, routing) — all but cli publish under the @monoes/ npm scope despite the @monomind/ directory name. 2 live under packages/@monoes/ (monobrowse, monodesign), where path and publish scope match.
CLI Entry Point
packages/@monomind/cli/
The published CLI package (installed as the `monomind` umbrella from repo root). 32 top-level commands, in-process agent/swarm lifecycle, and a hand-rolled stdio JSON-RPC MCP server — no separate MCP process required for the default transport.
Hooks & Workers
packages/@monomind/hooks/
Typed HookEvent registry/executor library plus a WorkerManager running 15 background workers (14 statically configured + the always-on progress worker). Bridged into the live dispatch path via .claude/helpers, which is the mechanism Claude Code actually calls.
MCP Framework
packages/@monomind/mcp/
MCP server framework powering `mcp start -t http`/`-t websocket` and stdio/in-process transports, with session, connection, resource, prompt, and rate-limiting support. The default stdio setup Claude Code connects to does not import this package — it uses the CLI's own hand-rolled loop.
Memory Backend
packages/@monomind/memory/
Lower-level memory backend library — SQLite (better-sqlite3, sql.js WASM fallback) and a pure-JS HNSW index. The live bridge that CLI memory commands and MCP memory tools actually call lives in the CLI package, dynamically importing this one. LanceDB was fully removed in v2.3.1.
Knowledge Graph
packages/@monomind/monograph/
Tree-sitter + SQLite code dependency graph. 14 full tree-sitter grammars (TypeScript's covers JS/JSX/MJS/CJS) plus 5 lightweight regex-based symbol extractors. 19 default MCP tools, 27 more behind MONOGRAPH_MCP_ADVANCED=1 — 46 total.
Semantic Routing
packages/@monomind/routing/
Opt-in RouteLayer algorithm: keyword pre-filter, then real embeddings via an isolated worker process, then cosine similarity, then a Haiku LLM fallback below threshold. Reached via `route semantic`, `agent --task`, or MCP hooks_route_semantic — bare `monomind route` uses a separate keyword-only stub instead.
Browser Automation
packages/@monoes/monobrowse/
Standalone Chrome DevTools Protocol (CDP) client for browser automation — no Playwright, Puppeteer, or Selenium dependency. Powers `monomind browse` and the agent-browser-testing workflow.
Design Intelligence
packages/@monoes/monodesign/
Independent frontend design intelligence package — design tokens, antipattern detection, and the monodesign skill. Replaced the earlier set of separate design-agent roles (UI Designer, UX Architect, Brand Guardian, etc.) with one unified system.
Memory
Three genuinely separate mechanisms share the word "memory" in this codebase. Here's what each one actually is.
The default memory engine is local SQLite with embedded vectors — better-sqlite3 primary, sql.js WASM as fallback. Embeddings are computed locally with Xenova/all-MiniLM-L6-v2 (384 dimensions). This backs CLI memory store/search, the MCP memory tools, and the Second Brain.
LanceDB (~600MB of native dependencies) was fully removed in v2.3.1 (2026-07-18) once the local SQLite engine was measured to work for Second Brain retrieval. Some internal comments and a health-check label still say "lancedb" as a stale string literal — cosmetic, not a live dependency.
A pure-JS HNSW index ships in the memory package, but it is not on the default search path. It's reachable explicitly via `memory search --build-hnsw`. Don't expect vector-index speedups on a default `memory search` call.
Hook and trajectory learning (routing outcomes, edit patterns) is stored in JSON files (patterns.json, auto-memory-store.json), independent of the SQLite backend above. These are three genuinely separate mechanisms that happen to all be called "memory" — not yet consolidated into one system.
Routing
The routing story has two distinct paths — don't mistake the default for the semantic one.
The default, zero-config path is a lightweight keyword-only router (createKeywordRouter): a fixed if/else chain over ~8 hardcoded categories, always returns confidence 0.75, no embeddings, no learning. It lives in the CLI package, not in @monoes/routing.
These entry points use @monoes/routing's RouteLayer: a keyword pre-filter first (first match wins, deterministic), then a real embedding model run in an isolated worker process (kept out-of-process because loading onnxruntime in-process causes SIGSEGVs), scored by cosine similarity against each route's centroid.
If the best semantic match scores below the configured threshold (default 0.5), routing falls back to a Haiku LLM classification call instead of guessing. This is the only place an LLM call is part of routing itself.
Every routing decision (from either path) can be recorded to route-outcomes.jsonl and later joined against what actually happened, producing accuracy/adherence metrics surfaced by `monomind doctor`.
Hook System
29 CLI subcommands and 20 typed registry events are different mechanisms that happen to share a name — plus 15 background workers underneath both.
Org Runtime v2
monomind org run/serve replaces the older prompt-orchestrated runorg path — each role is a live agent session, not a scripted prompt loop.
Runtime
SDK-backed daemon
monomind org run/serve — each role is a live, in-process Claude Agent SDK session, not a subprocess.
Subcommands
16
run [--dry-run], stop, status, serve, test-loop, logs, report, memory, questions, answer, create, validate, migrate, list, delete, mark-complete.
Inter-agent channel
org_send / Mailbox
The only way roles communicate — plus ask_human for human-in-the-loop and org_recall/org_remember/org_learn for cross-run memory.
Config
.monomind/orgs/<name>.json
Parsed against a zod schema: goal, schedule, run_config (budget, concurrency), and a role list with per-role tool/file/web policy.
Honesty Notes
A short list of things that are easy to overstate. We'd rather say them plainly here than have you find out later.