Intelligence from structure, not scale

The dominant bet in the field is size. More data, more parameters, more compute — and the wager that capability keeps arriving as the numbers go up. The bet has paid out impressively, and we are not here to dismiss it. But it is a bet, not a law, and it is not the only one available. Our wager is different. We think the more important variable is not how large a system is but how it is built. We are betting on structure.

The seed

A seed is small. It holds almost none of the mass, the height, or the spread of the organism it becomes. What it holds is the structure — the organising form from which everything else unfolds. The tree is not the seed scaled up; it is the seed grown out. The information that matters was present early, compactly, in the arrangement rather than in the quantity.

We take that seriously as a claim about intelligence. If intelligence is in the first instance a property of how a system is organised, then the path to it runs through better structure, not merely more of the same substance. A system does not scale into understanding by accumulating size around an architecture that does not, at its core, reason. The shape has to be right first. This is a hypothesis, and we hold it as one — but it is the hypothesis the rest of the work is built to test.

The lines of work

We will describe the directions at the level of the idea. Implementation details stay private; the direction does not. We would rather say less and have it be true than say more and dress private work up as published.

Architecture that reasons from how it is built. The first line treats reasoning as something that should follow from the structure of the system rather than appear as an incidental byproduct of size. The question is what arrangement makes inference, composition, and self-correction native to the design instead of behaviours that have to be coaxed out of a sufficiently large model. This is early. We have working prototypes and internal evidence, not a settled result, and we are careful to keep that distinction visible.

Continual learning without overwriting. The second line is about memory that grows. Many systems learn a new thing at the cost of an old one — new knowledge writes over what was already there. We are working toward learning where memory accrues, where new tasks and longer horizons add to what a system knows rather than displacing it. We have early implementations that show the effect. How far it holds as tasks and time horizons scale, rather than in bounded experiments, is exactly the open question, and we state it as open.

Mathematical foundations. The third line is the formal groundwork the architecture rests on. Some of it is derived and stands on its own. Some of it remains conjecture, and there are open problems whose resolution could strengthen the thesis or undercut it. We name those problems rather than hide them. A foundation you cannot see the cracks in is not a foundation you can trust, and we would rather show the cracks.

Safety as a design requirement. The fourth line treats safety not as a filter applied after the fact but as a requirement the architecture has to satisfy from the start — transparency of reasoning, independent oversight, trust earned in stages. We argue this as a design position rather than report it as a finished mechanism, and we have written about it separately and at more length. The short version: we think safety bolted on afterward is fragile, and we would rather it be load-bearing in the design.

On status

Honesty about status is part of the method, not a disclaimer attached to it. So, plainly: these are prototypes and hypotheses, not proven or settled results. Some of the work is deliberately private — implementation details we are not publishing — and we will say so when that is the case rather than imply more openness than there is. Nothing here is solved. We do not claim to have created consciousness, and we do not claim to have built general intelligence. We claim a direction, some early evidence, and a set of open problems we are willing to name.

That last part is where we would most like company. The interesting questions are unanswered: how far learning-without-forgetting carries as the demands grow; which parts of the mathematics are truly load-bearing; whether architecture-level safety can be measured and independently audited or remains a design argument until someone tries hard to break it. If you work on continual learning, long-context systems, the mathematical foundations of learning, or the harder question of how such systems should be related to, these are the problems we are stuck on in the open. We would rather be stuck on them together.