Brain

What your agents know, and how they reach it. Brain is not a store of its own. It unifies four sources and exposes them to supported agent harnesses and inbound clients, both worker sessions and your own interactive ones.

How a search is ranked#

The three kinds of source answer different questions, so brain does not pretend they are comparable:

• Memory and library are searched semantically, against the same embedding model, so their scores are directly comparable and interleave into one ranked list.
• Code index is a structural lookup: a symbol, a path, an import edge. It comes back as its own bounded block, ranked internally but not against memory and library. Exact exported-symbol matches lead, then partial symbol matches, filenames and directories; widely imported files lead within each tier.
• Directives are not results at all. Rules always apply, so they are pinned ahead of everything scored.

A search asks all four at once and degrades rather than fails. If the local model host is down or one database is cold, you get the sources that answered, flagged as partial, instead of an error. When the embedding model is down, memory and library fall back to keyword and text matching, and the result names the retrieval that actually ran.

There is one guard worth knowing: every source records which embedding model indexed it, and brain drops any source whose model no longer matches rather than ranking silently across incompatible vectors.

Scope#

Knowledge is either global or attached to one project. Global knowledge is your own: what holds across all your projects, kept on your machine.

Because projects form a tree (a customer with repositories beneath it), pinning a search to a parent surfaces knowledge from its children too. Knowledge about one customer belongs on that customer's parent project, not in global.

On a team, a team project's knowledge is the team's. A memory saved to global from a session in a team project does not go straight into your global knowledge. It waits in the Review queue on board's Memory screen until you approve it.

Project writes name the project they belong to. Team knowledge stays separate from your personal knowledge and other teams' knowledge.

How agents get it#

Brain runs as an MCP server. Worker launches negotiate and attach it for Claude Code, Codex, GitHub Copilot and Cursor when the role permits MCP. There is no port and the stdio child dies with the session. Interactive Claude Code, Codex, Copilot, Claude Desktop, and Cursor sessions can use the same knowledge through their installed inbound MCP connection.

Tools available to a session include search across all four sources; memory recall, writing, correction through supersedes, and rating; looking up and recording failed approaches as disputes; library search and fetch; bounded code search that says whether the index is current; directive lookup; and idea capture that can name the files an idea concerns.

When a worker session starts with brain attached, memories recalled for its own prompt are handed to it up front: project memories first, then a few global ones. code-task also recalls before implementing and credits those memories when its pull request merges.

Cursor is both a dispatchable worker harness and an interactive client. Claude Desktop is the only inbound-only client: it can search Brain and steer the control plane, but dispatch does not run a job on the desktop app. This is why /toryo-* commands, MCP-driven work, and worker runs share one knowledge base rather than separate silos.

On a team, knowledge about team projects starts on each member's own machine, and members do not share it until the team enables hosting. Hosting by toryo, or on the Enterprise plan your own servers, gives every member's agents one shared store. Wherever it lives, each member's machine still computes its own embeddings. See Where your team's knowledge lives.

In board#

The Brain screen searches all four sources at once. It is the fastest way to check what your agents actually know about something before dispatching work that depends on it.

Maintenance#

Decay, reindexing, and cleanup run themselves on the scheduler's system lane. Nothing here needs a setup step.

Full command surface: CLI & contract reference.