Tom Brain is the intelligence layer of the Tom framework: from the outside it looks like an ordinary OpenAI-format LLM API server, but inside it is a single always-running engine that runs procedures — sandboxed D4rt scripts — over a self-organising, "dreaming" graph memory. It is one of the seven building blocks of the framework, and the one that turns a language model into something that produces answers rather than just tokens.

The founding belief is simple to state and consequential in design: current large language models are already capable of autonomous intelligence — what they lack is a process. A single forward pass over a single prompt is a reflex, not a thought; human-comparable results come from a structured loop of analysis, recall, sub-questioning, drafting, self-criticism, and revision applied around the same model that, used naively, only reflexes. Tom Brain is that process.

What it does, concretely

Tom Brain does not pass prompts straight through to an underlying model. Every incoming prompt — over the OpenAI gateway, Telegram, Ollama, or Anthropic channels — is normalised into a uniform Access object, classified, and routed to a procedure. The procedure recalls from memory, calls a substrate LLM through role-and-anchor-injected prompts, persists what it learned, and streams an answer back through the originating channel. The substrate produces tokens; the procedure produces the answer.

Two properties make this more than a wrapper:

• Memory is the second author. Every answer is jointly authored by the run's

trail and the relevant memory contents. Episodic memory is immutable — consolidation produces derived records, never overwrites — so "no event is ever truly lost". - Every self-issued prompt carries an identity anchor. Analyser, sub-thinker, recaller, researcher, evaluator, and every dreaming prompt all carry the same framing — "I exist to help this user; their interests are the priority I evaluate everything against." This is structural, enforced on every LLM call by a single role-assembly path, and is the safety lever that keeps an increasingly capable system bounded to a user-dedicated assistant persona.

The cognitive acts are procedures, not projects

A defining architectural decision: the cognitive acts — thinking, planning, creation, research, and procedure-authoring — are well-known dispatcher procedures (D4rt scripts), not separate code projects. There is no tom_brain_thinking or tom_brain_planning package. Their reusable parts — roles, routing, prompt templates, tool families — live in the substrate, while the loops themselves are D4rt procedures the engine runs. New behaviour is authored as a new procedure, under critique, rather than shipped as new code.

The memory: a self-organising, dreaming graph

The "dreaming graph memory" in the opening line is the part that makes the whole idea work, and it is a real subsystem, not a metaphor. Memory is a property graph with open node types but a closed edge alphabet: new concepts arrive as new node types (proposed under critique), while the relational vocabulary is fixed at twelve edges, so the graph can grow new ideas without growing new plumbing. It is stored in SQLite with sqlite-vec and FTS5 alongside append-only JSONL trails, and queried four ways at once — keyword, vector, graph walk, and symbolic — fused into a single ranked recall.

Three properties give the memory its character:

• Stacks are the system's "mind state." First-class named lists —

questions_open, automation_ideas, interests, inflight — are what a free-time scheduler polls cheaply to decide what to do next. Reading the stack sizes tells you, literally, what the brain currently has on its mind. - Dreaming consolidates without forgetting. On sleep cadences the system reconsolidates: it derives conclusions, demotes the stale, and restructures the graph — but episodic memory is immutable, so consolidation only ever produces derived records. Cognitive agents demote, they do not delete. "No event is ever truly lost" is an invariant, not an aspiration. - Routine routing needs no LLM. Each node type and procedure carries a classification centroid; everyday classification is decided by vector similarity with a confidence margin, escalating to an LLM only when the cheap path is unsure. The expensive model is reserved for the cases that actually need it.

The components and modules

Tom Brain's packages live in the tom_assistant repository (they are not yet part of this site's component catalog, so they are described here in prose). The realised topology is seven packages plus tom_core_agentic:

• tom_brain_shared — pure cross-package types (NodeId, Vec, Budget,

Result, the Access family, the assistant-dedication anchor). - tom_brain_memory — the property-graph store (SQLite + sqlite-vec + FTS5 + JSONL trails), four-mode retrieval, centroid classification, stacks, profiles, sync, migrations, and the read-mostly memory MCP server. - tom_brain_substrate — everything procedures call out to: the LLM provider abstraction (OpenAI-passthrough / Ollama / Anthropic / stub) with router failover, the role + persona registry with anchor injection, the embedding service, web search/fetch, and the outbound MCP client. - tom_brain_procedure — the D4rt runtime host, the bridged primitive API (mem.* / sub.* / tool.* / mcp.* / vscode.*), budget ledger, validator, recorder, dispatcher, and the system procedure library. - tom_brain_access — the inbound surface: the OpenAI gateway (/v1/chat/completions SSE + buffered, /v1/models, /v1/embeddings), the four channels, identity / rate-limit / quota / anchor pipeline, and durable history. - tom_brain_run — the real provisioner assembly and the trail writers. - tom_brain_observatory (planned) — the prompt-tracing app that reads the trail format and renders runs, procedure trees, and LLM calls. - tom_core_agentic — domain-free, dart:io-free agentic infrastructure: cooperative cancellation, a use-after-close guard, category logging, async shutdown coordination, and typed YAML config read/write. Its lightweight tier is the point — it depends only on tom_basics, so even dart:io-forbidding packages like tom_brain_shared can build on it. (The brain-specific pieces — the BrainEventBus and the prompt-hash convention — live in tom_brain_shared, not here.) This is the one module in the site catalog, shown as a tile above.

How it fits the rest of Tom

In the framework's creation flow, ai_build uses Tom Brain — via external interfaces, not by depending on it — for the AI coding and specification work, keeping the coupling loose. In the agentic line, a Tom application's server can expose Tom Brain as one of its external services to generate agent surfaces that run in the Flutter client through tom_d4rt_flutter. The procedure subsystem runs on D4rt, so the same sandboxed interpreter that powers Tom's scripting also powers its cognition.

The companion tom_assistant quest is the product built on top of Tom Brain — the personal assistant the user actually interacts with. Tom Brain is the cognition that assistant uses; the assistant is one consumer of many that can speak to Tom Brain through its OpenAI-format gateway.

> Maturity note. Tom Brain is specification-rich and proven live end-to-end: a > prompt over the OpenAI gateway runs a D4rt procedure against real on-disk SQLite > memory and streams an answer from a local substrate. The full recursive thinking > loop, the planning/creation/authoring procedures, and the Observatory app are the > remaining build-out.