You can write in LLMese, but you don’t have to – Fabrizio Ferri Benedetti

You can write in LLMese, but you don’t have to

Posted on Jul 12, 2026<br>· 8 min read

While chatting with Sarah Deaton about the formats agents could use to talk to each other, we got to questions that might sound obvious: why should machines (say, LLMs) communicate with each other like we do? Do they need all the rhetoric we carry around? Or could they get by with a terser register, one that carries the same meaning but in far fewer tokens?

Heh, of course science fiction got there first

I&rsquo;m a huge fan of Iain M. Banks&rsquo;s Culture novels. In almost all of them, the Minds, almost god-like AIs, don&rsquo;t talk between themselves like we do. Banks renders mind-to-mind messages as pseudo-technical headers; buried within, the actual message, which is usually dry and witty like a jab. Decades earlier, Isaac Asimov explored the same idea. Two of his robots, R. Daneel and R. Giskard, talk to each other in Robots and Empire using a highly compressed language.

They spoke in an abbreviated and Aesopic language. They understood each other well, with many decades of communication behind them, and it was not necessary for them to involve themselves in all the elaborations of human speech.

Daneel said in an all but unhearable whisper, &ldquo;Clouds. Unseen.&rdquo;

Had Daneel been speaking for human ears, he would have said, &ldquo;As you see, friend Giskard, the sky has clouded up. Had Madam Gladia waited her chance to see Solaria, she would not, in any case, have succeeded.&rdquo;

Our LLMs are not minds from the Culture, nor Asimovian robots (I wish they were). They&rsquo;re not intelligent, nor have a will of their own. What they do have, though, is an appetite for tokens. This turns the question into a fairly banal logistical issue: could we rewrite the docs into a register meant for models and still get good answers? Could we write, for lack of an uglier word, in LLMese?

Trying to compress meaning in fewer tokens

I made a small prototype to find out, llmify. The prototype takes a document, compresses it into something an LLM can (supposedly) digest, and then measures two things: how many tokens you saved, and whether the model can still answer questions about the content as well as it could from the full doc, using the same set of questions for evals, and the same model.

I compared three ways of compacting docs. The first two are semantic rewrites: one outputs terse Markdown (have a look at the Claude Skill), while the other outputs a stricter line grammar suggested by GPT after exploring various ideas. The closest published analogue I found is Telegraph English, a prompt-compression protocol that also rewrites prose into structured, atomic statements, though I found out about it too late to include it in the experiment. The third method relies on LLMLingua-2, which uses a specially trained model to prune tokens. Although it is built for prompts, I included it to see how pruning performs against semantic rewrites.

I ran the experiment on two documents: the dense Admission Webhooks Good Practices page from the Kubernetes docs, and a doc made by GPT 5.6 on a piece of fictitious tech, VesperGate. The idea was to compare how the model fares when it has prior knowledge of the subject versus when it has none. Here&rsquo;s an original rule from the VesperGate source (it reads like technobabble from a Star Trek episode, something I find quite amusing):

The Lantern receives a Twine and evaluates it against one Lockbook. A Twine is not an API token. It is a signed factual envelope created by the Oriole scheduler. If an operator sends a Twine directly to the Lantern CLI, the Lantern must reject it with VG4032 direct-twine-refused.

Do not summarize all non-clear locks as &ldquo;deny.&rdquo; pale does not deny. amber does not deny. mirror allows the request but records an alternate deny result. Only dusk, dim, and dark block the mutation, and each implies a different remediation.

The Markdown profile keeps it as terse bullets while retaining relevant distinctions:

- Lantern receives scheduler Twine and evaluates against one Lockbook. Direct Twine to Lantern CLI rejected: `VG4032 direct-twine-refused`.<br>- `pale`: `preflight` defer; rollback `vg lockbook thaw --reason pale-timeout`; only incomplete facts.<br>- `amber`: `bind` delay; rollback `vg lockbook release --class amber`; retry may use same Twine.<br>- `mirror`: `bind` shadow-allow; rollback/action `vg lockbook promote-mirror `; admits and records would-have-denied.<br>- Do not summarize all non-`clear` as deny: only `dusk`, `dim`, `dark` block. `pale` defers; `amber` delays; `mirror` allows.

The line grammar turns the same material into typed records:

RULE direct.twine | IF operator sends a Twine directly to Lantern CLI | MUST reject with `VG4032 direct-twine-refused`.<br>DEF color.pale | `pale`; preflight defer; rollback `vg lockbook thaw --reason pale-timeout`; does not deny.<br>DEF...