The Brain
PartialRouting and dispatch. Regex first, a model-based planner when that misses. Verified in parts, currently scaled down.
The Brain turns an intent into a decision about who should act, and then runs that decision. Most of what it does is routing and dispatch; for simple requests it can also answer directly, and it assembles the final reply from what the dispatched steps returned.
The matching ladder
Routing escalates step by step and stops at the first step that resolves. The order is right; the middle step is currently broken.
| Step | Method | State today |
|---|---|---|
| 1 | Regex match against the capability registry, first hit wins | Works — verified 27 October 2026 |
| 2 | Semantic match against capability descriptions and anchor phrases | In the code, but broken: the embedder fails to initialise, so this step never fires |
| 3 | No match: a classifier picks a path — a direct model answer, or a planner model that breaks the request into steps | In the code; not verified end to end |
The capability registry is a single configuration file. It holds 119 capabilities, 109 of them enabled. Each entry carries its routing patterns and an execution target, and most carry a validator that checks the result after the fact. It is the source of truth for what the system can do, and it is readable without running anything. This site previously said 66 capabilities; that number was out of date.
Dispatch happens inside the Brain
Once a capability or a plan is chosen, the Brain’s plan executor runs each step against an execution target. The code knows eleven kinds of target — among them the database, direct Python calls, OpenFang agents, MCP tools, plain HTTP, n8n, the coding engine, the forecasting space and research. The registry currently uses seven of them, and the database is by far the most common.
Steps addressed to an OpenFang agent need a validated handoff bundle. With one, the Brain writes a job into a queue; a separate runner picks it up, hands it to the agent, a follow-up loop checks the result and the job is marked delivered. That chain is the one we verified on 27 October 2026. It works, and it is slower than designed: pickup took about half a minute where a few seconds were expected.
Inference and learning are separate
The Brain is designed to run in separate roles. An inference role answers routing requests and never writes. A learner role owns every write — centroid updates, vector store changes, checkpoints. Background loops run in a service of their own.
This exists because of a specific failure. Background learning loops are CPU-bound, and when they shared a process with the HTTP path they starved the requests users were waiting on. Moving them into their own worker fixed it. The lesson generalises: anything that runs continuously should not share a process with anything a person is waiting for.
In the current deployment the dedicated inference and learner services are scaled to zero, like the request service. The background-loop service and a worker that drains queued training work are running.
How it is meant to improve
The code has endpoints for rewarding a routing decision and for training the routing matrix offline, so that phrasings which led to good outcomes get associated with the right place. The mechanism is in the code. Whether it improves routing in practice is something we have not measured, and with the learner scaled down it is not happening today.
What it depends on
A vector store for routing history and decisions, an embedding service backed by a local model runner, the database that most capabilities execute against, OpenFang for agent work, and the coding engine for coding capabilities. Part of the Brain’s tree is a third-party research model under a non-commercial licence — see Licensing.