Not installable yet, as of 10 August 2026

Coldstart is in final cutover and has not been released. The behavior on this page runs in the development build; there is no release you can install today.

Some text is in the session before you type anything. Not because a rule loaded it, but because the tool you are running injects it: for every command you could type, every routing skill that could fire and every agent that could be delegated to, its name and its one-line description are present from the first message.

That set is the resident floor. It is the only part of the guidance system with a permanent price, and it is the reason the rest of the library can be as large as it needs to be.

[Visual 4.1 — The top band from the section opener, enlarged to fill the frame. It is drawn as a single horizontal strip divided into three labelled runs: "routers", "command wrappers", "agent definitions". Each run holds identical small tags, and one tag is drawn large beside the strip, showing exactly two parts: a short name and one line of description text, with a hard right edge marked "ceiling — about two kilobytes, per description". Under the strip, a single wide arrow labelled "measured on every run" points to a small readout showing a count and a byte total beside a fainter recorded baseline, tagged "reported, not a verdict". Below the strip, greyed and clearly outside it, sits the library from the section opener with a label reading "bodies — not here, not paid for". A caption reads "one description too long fails the tree; a roster too large does not".]

What is on it, and what is deliberately not

Three kinds of thing put a description on the floor: the routers that decide which discipline applies to a request, the wrappers behind the commands you type, and the agent definitions work can be delegated to.

What each of them contributes is exactly one line: what this is for, and when to reach for it. Their actual contents are not on the floor. The body of a routing skill, the procedure behind a command, the full brief an agent gets — all of it stays on disk until something selects it.

Measured in the development build on 10 August 2026, that is twenty-five descriptions standing in front of roughly a hundred and thirty files they can lead to. The ratio is the point of the design, not a coincidence of this month's contents.

Why descriptions and not instructions

The temptation is to put the actual rules on the floor. If a rule matters, keep it in front of the agent permanently, and it can never be missed.

That fails for a reason that has nothing to do with cost. A permanent instruction is one that applies to every session, including all the sessions it is wrong for. Guidance about hardening a container is not neutral in a session about copy on a landing page; it is noise competing for attention with the actual job. Making it permanent does not make it more likely to be followed. It makes everything permanent slightly less likely to be followed.

A description does not have that problem, because it is not asking for anything. It says a thing exists and names the situation it is for. The decision to load it happens later, with the actual request in hand.

The single ceiling, and the caps that were removed

There is exactly one size rule that fails the build, and it applies to a single description rather than to the set: no one description may run past roughly two kilobytes. The reasoning is that a description that long is not a description. It is payload wearing a trigger's clothes, and it has put the body back on the floor by the side door.

What used to exist and was deliberately taken away is a cap on the roster: a limit on how many routers or agents there may be, and a matching limit on their combined size. Both were removed for the same reason. A headcount was only ever a proxy for the bytes a surface costs, and a fixed combined byte band with a little headroom for rewording is that same headcount cap expressed in a different unit — the next router fails on bytes exactly as it failed on count. Routers and agents are product surfaces meant to grow, and capping the roster caps the product.

What replaced the caps is measurement. Every run reports each surface's count and its resident byte total against a recorded baseline. Past the baseline, the report says so more loudly. It never becomes a failure on its own, because the question "is this creep or is this the product growing" is a judgment, and the check's job is to make sure that judgment is made against a number rather than an impression.

Two things do still fail outright: a single description past the ceiling, and a file whose description cannot be read at all.

Why an unreadable file is a failure rather than a skip

The floor is parsed by exactly one piece of code, and everything downstream reads its output: the measurement, and the ranking that decides which router fires for a given request.

That single parser is what makes the second failure mode worth failing on. If a malformed file were quietly skipped, its router would silently leave the floor. The measurement would then report a smaller floor, which reads as good news, and the ranking would never consider that router, which reads as the router not matching. Both numbers would be lies, and they would be lies pointing away from the cause. Refusing the file instead puts the defect where the defect is.

The same single-parser rule is why the text that is measured is byte-for-byte the text that is ranked. Two readers of the same file that disagreed about, say, how a folded multi-line description is joined would mean the guard measuring one string while the router fires on another.

Limits

A small floor is not a good floor. Everything on this page is about size and readability, and none of it is evidence that a description describes its body accurately, that the situation it names is the situation it actually fires in, or that the set of routers is the right set.

The ceiling is on the description, not on the honesty of the description. A misleading one line passes every check here.

Nor does any of it establish that the resident floor is small in a way that matters to a session's outcome. The recorded baselines make growth visible over time. Whether the current total is helping or hurting the work is not something the measurement can answer.

Next

That is what is always present. What happens when the session needs something that is not: routed capability.

How current this page is

Checked on 10 August 2026 against the product's current resident surface, its floor measurement and its recorded release state. The counts are what the development build measured on that date, and they are expected to change. To ask whether a claim here still holds, or to report one that does not, write to [email protected].