Fat Clones, Thin Clones, and the Strawberry Problem

Ask a chatbot how many times the letter "r" appears in "strawberry" and you will, sooner or later, get a confident wrong answer. Ask the same model the same question on a different day, in a different window, behind a different bit of plumbing, and you can get a different answer again. The unsettling part is not that it is wrong but that "the same AI" turns out to be a fiction. The model in your phone and the model in your browser and the model your colleague is using are not one consistent thing. The environment makes the agent.

I have been living inside a small version of this problem lately, and it has nothing to do with chatbots and everything to do with where work actually happens.

Two environments, one repository

A repository - the folder of files a team and its agents work in - is met by more than one kind of environment.

One is the fat clone: a full local checkout, everything present, every dependency installed, every linked component pulled down. On a fat clone an agent can see the whole estate and run every tool it carries. It is the complete picture.

The other is the thin clone: a stripped-down checkout, often in the cloud, spun up to do one job and then thrown away. It deliberately leaves most of the estate on the shelf and often arrives before its tools are installed. It is a partial picture, and it knows almost nothing about the parts it did not fetch.

Then there is the second axis, the one the strawberry test is really about: the agent itself changes. A cloud session running one model is not the same brain as an on-device assistant running another. Same repository, a new reader, and the two read the same words and reach different conclusions, exactly like two windows giving two answers about a piece of fruit.

So you have a repository that holds still while everything meeting it shifts underneath: the completeness of the checkout, the tools available, and the model doing the reading.

The problem is not a crash

You might expect the failure here to be loud: the agent reaches for something that is not there and falls over. That does happen, and it is the easy case, because a crash tells you something is wrong.

The dangerous case is quiet. Picture an agent on a thin clone asked to rebuild a whole-repository index, a file meant to summarise every part of the estate. Most of the estate is not present on a thin clone. So the agent rebuilds the index from the slice it can see, drops every entry the missing parts would have contributed, and produces a file that looks freshly generated and is quietly gutted. No error. No red mark. Just confident, plausible damage that the next reader inherits as truth.

Now add the other axis: the agent is a different model than last time, and it reads the instructions slightly differently. You cannot fix this by being careful, because there is no single "you" here at all. There is a rotating cast of environments and brains, and none of them can hold the others' context in its head.

The fix is shared ground truth that travels

The answer is not to make every environment identical. You cannot, and you should not try; the whole point of a thin cloud clone is that it is light. The answer is to make the ground truth identical, and to carry it in something every environment reads the same way.

That is the job MX gives to a cog: a plain file, readable by a person and a machine alike, that states what something is, how it relates to everything else, and what is safe to do with it. The instructions do not live in one clever agent's head or one machine's setup. They live in the repository, in a carrier that travels with it, and they read the same whether a cloud model or an on-device one opens them. Both environments read the same cogs. When the brain swaps, the ground truth does not.

Three things follow, and they are the whole trick.

The instructions are read, not guessed. A cog states the rule outright, so two different models do not each have to reason their way to it and risk reasoning differently. The famous strawberry failure is the model guessing at something it should be able to read. A cog removes the guess, and with it the divergence.

The checks know which environment they are in. The repository's own guardrails detect whether they are on a complete checkout with the tools present or on a thin partial one. When the picture is whole, they do the work and enforce the rules. When it is not, they refuse, loudly, naming the gap, rather than producing that quietly gutted index. The repository mends itself only when it can see its whole self, and it knows the difference. So the thin-clone agent is structurally stopped from the confident-damage move, not merely trusted to avoid it.

What is learned travels too. Knowledge an agent picks up in one session, a correction, a hard-won rule, a "do not regenerate that here", is written back into the repository as portable memory, so the next one on any machine inherits it. The on-device assistant and the cloud session do not start from scratch and drift apart; they hydrate from the same accumulated practice the moment they open the repository. Memory stops being something one brain holds and becomes something the repository carries to all of them.

Same repository, any brain

Put those together and the strawberry problem stops being frightening. You are never going to make two model instances answer in lockstep by force of will. What you can do is make the file they read explicit and identical for everyone, and keep the environment honest about what it is and what it is allowed to do there.

The file tells the agent what it is. The gate enforces what is safe in this environment. The memory carries what the last agent learned. None of it depends on which model turned up today, or whether the checkout is fat or thin. That is the difference between hoping your agents agree and building a place where it does not matter that they do not: the repository holds the truth, and every environment that meets it reads the same thing.

That, in the end, is what MX is for. Not making the machines smarter. Making the ground they stand on the same.

Tom Cranstoun founded the MX community and wrote the MX book series. He consults on MX strategy through Digital Domain Technologies Ltd.