Brain

Brain is OCTYN's own internal system. It is the premise the rest of the operation rests on, and it has never had a public surface.

1. The situation

Twenty-one codebases, and one person in front of all of them. The limit is not typing speed and it is not compute. It is that every morning the context has to be rebuilt: what state was that project in, what was decided about it, what was the reason for the decision that now looks strange.

That is the same arithmetic this site puts on the cost page, applied to ourselves. The workspace audited on 2026-07-24 held more than twenty repositories and roughly 34,853 files, with 141 markdown notes across 15 subprojects, 63 files on the agency side and 22 planning documents. Nobody holds that in their head, and nothing useful comes from a system that tries to hold all of it at once either.

2. Why it was hard

The obvious build is a search over everything, and it is the wrong one twice over.

First, because the failure that costs the most is not a missing answer, it is a blended one. Ask about a deploy step and get a confident reply that quietly merges how two different projects deploy, and the mistake is invisible until it is executed. A system that draws from everything will do this, and it will do it fluently.

Second, because context is not free. Loading the whole workspace to answer one question is the expensive habit the tool is supposed to cure, not the mechanism it should be built on.

There is a third problem, which is the one that kills most internal tools of this shape: a planning layer that can also act will eventually act at the wrong moment, and then nobody trusts it with planning either.

3. What was built

One workspace over everything, and a hard rule at the centre of it: Brain plans and Brain learns, and Brain never builds or deploys. That constraint is not a limitation waiting to be lifted. It is what makes the thing safe to consult, because the worst outcome of a wrong answer is a wrong answer.

Two roles that stay out of each other's way, both visible on the internal map. The Planner stays across every project, loads context cheapest source first, stops when it has enough to answer, and is explicit that it never mixes context between projects. The Learning Partner teaches one idea at a time, always tied to what is being built that week, and writes progress back into the notes as backlinks rather than into a chat log that nobody reads again.

Underneath both sits a tiered context model, five tiers deep on the map as captured on 2026-09-14. Each tier is a wider and more expensive read than the one before it, and the point of the tiering is to make stopping early the default rather than an optimisation.

The memory layer moved to Alchemyst AI, as recorded on the work page. What that changed is persistence: company context now carries between sessions rather than being rebuilt each morning, and what it recalls can be traced back to where it came from, which is the property that makes a recalled fact arguable instead of merely confident.

The business side runs as a sibling workspace on the same memory layer, pointed at lanes, positioning, pricing and pipeline instead of at products. It can read the product side when a question needs it, and it is not allowed to blur the two into a single answer. Same rule, applied to a different pair of contexts.

4. What it does under load

The load here is corpus size, not requests, and the figures are the ones from the 2026-07-24 audit above: 20 plus repositories, roughly 34,853 files, 141 notes, 15 subprojects.

What is not measured, and should be said plainly: there is no eval set for context selection. Nobody can currently state what percentage of answers pulled the right project's material, because there is no fixed set of questions with known right answers to run it against. That is the single biggest gap in this system, and it is a gap in exactly the place where the whole design lives.

The thing that is observable without instrumentation is the negative case. A blended answer is obvious to the person who asked, because they know which two projects got merged. It is caught, it is just caught by a human rather than by a test.

5. What happens when it breaks

Three failures, in increasing order of how much they cost.

A miss is cheap. The context loader stops too early, the answer is thin, and the person asks again with a pointer. That is the failure the tiering deliberately biases towards, because it is the recoverable one.

A blend is expensive. Two projects merged into one answer, delivered fluently. The defence is structural rather than statistical: separate workspaces, and a rule against mixing them that is stated rather than hoped for. There is no automated detection of it, which is the honest state on 2026-09-14.

A stale recall is the one to watch as the memory layer does more. A fact that was true in July and is recalled in September with no sense of its age is worse than no memory at all, which is why traceability back to the source mattered more in that choice than recall quality did.

The failure that cannot happen is the useful part of the design: Brain cannot deploy the wrong thing, because Brain cannot deploy.

6. Who maintains it, and what that costs in attention

It maintains itself as a by-product of being used, which is the only arrangement that survives. The progress log gets written because the next session needs it. The project list is accurate because an inaccurate one is felt within a day.

The standing cost is the reading order. A workspace this size is only navigable because there is a documented order to read it in, and that order goes stale quietly when a project changes shape. Nothing warns you. You find out when an answer comes back built on an old picture.

7. What changes when requirements change in six months

Configuration, no code: adding a project, adding a learning track, changing the reading order.

A small change: another role. The two roles are separate by construction, so a third with its own boundaries is an addition rather than a refactor.

A larger change: letting Brain act. Every property described above depends on it not acting, so this is not a feature to be added later. It is a different system that would need its own containment, and the right move is almost certainly to keep Brain as it is and let something else hold the permissions.

A rebuild: more than one person using it at once. Everything here assumes a single reader with a single context at a time, and concurrent readers with different permissions is a different data model, not a bigger one.

8. What we would do differently

Build the eval set first. The central claim is that it never mixes two projects, and that claim is currently supported by the fact that nobody has noticed it happening. A fixed set of questions with known answers, run whenever the retrieval changes, would turn the claim into something we could show.

Pick the memory layer before the corpus grows. Moving memory underneath a workspace with tens of thousands of files is a migration; doing it at the start is a decision.

And write the reading order as a file that changes with the code rather than as a document that describes it. Every doc that describes a system it does not live inside eventually describes a system that no longer exists.