AI engineering

Agents Are Already Writing a Language You Can't Read

Compression toward machine-preferred notation isn't a future bet. It's already landing in context formats, agent protocols, and the files your harness reads.

TL;DR: This isn’t a prediction about the next programming language. That lane is already crowded, and it’s the wrong layer to watch anyway — a source language needs a mountain of human-written training data to be any good, and an agent-native one doesn’t have one. The compression that’s actually underway is happening one layer removed from source code, in three places at once: the context and storage formats models read (chosen for token count, not eyes), the protocols agents use to talk to each other and to tools (which quietly deleted the human-facing UI from the middle of the exchange), and the instruction files your harness reads every session (getting denser, stranger, and less like English with every iteration). None of that needs a corpus. It just needs to be consumed in-context, right now, by something that was never going to read it out loud.

English is an accreted protocol, not a language

Every instruction you’ve ever given an AI agent, you gave it in a format that was never designed. English wasn’t specified — it accumulated, the way a shipwreck accumulates barnacles. It borrowed its grammar in one era, its spelling in another, and well over half its vocabulary from French, Latin, and Greek by way of a thousand years of invasion, trade, and Church Latin that nobody voted on. There is no committee that owns it, no version number, no changelog. It is the single most successful piece of legacy software on earth and it has never once been refactored.

And it shows in exactly the places you’d expect from unreviewed legacy code: ambiguous scope, ambiguous reference, silent overloading. “I saw the man with the telescope” doesn’t tell you who’s holding the telescope. “Flying planes can be dangerous” doesn’t tell you whether the danger is in the flying or the planes. Pronouns lose their antecedent three sentences later and nobody notices because a human listener silently repairs it using context the sentence itself never supplied. That repair step is invisible when you’re talking to another human who shares your assumptions. It is not invisible when you hand the same sentence to a system that has no assumptions until you give it some, and takes the sentence at face value because taking things at face value is the only move it has.

This is also, not coincidentally, the format we’ve standardized on for talking to agents. CLAUDE.md, system prompts, tickets, Slack messages piped into a context window — all English, all inheriting every one of those defects, because it’s the interface we already had lying around. We didn’t design a notation for instructing machines. We handed them the most ambiguous instrument in the toolbox because it was the one everyone already spoke, and figured the model would compensate. Increasingly, it does — which is a separate, more interesting problem than the one people are usually worried about.

The turn: this isn’t about the next language

Here’s where most essays like this one go next, and where this one doesn’t. The obvious extrapolation is “so eventually there will be a programming language designed for agents instead of humans” — and that lane is already occupied, loudly, by people with more capital than opinions to spare. I’ll get to the loudest entrant in a minute, because it’s the best evidence for the argument I’m actually making.

The interesting version of this claim isn’t a forecast. It’s an observation: the compression toward machine-preferred notation is already happening, and it’s landing almost entirely at layers that sit around source code rather than in it.

Three layers, in the order a request actually moves through them:

  1. Context and storage — the format the data sits in before a model ever reads it. Chosen, increasingly, for token count rather than human legibility.
  2. Protocol — the interface agents use to call tools and talk to each other. Built to skip the human-facing UI that used to sit in the middle.
  3. Harness — the instruction and memory files a coding agent rereads every session. Compressing, in real time, into something denser than the English they started as.

None of these are “a new programming language.” All three are quietly doing the thing a new programming language is supposedly going to do eventually, and they’re doing it now, in production, without asking anyone’s permission.

Layer one: context chosen for tokens, not eyes

Start with the most literal version: the bytes a model actually reads.

A model doesn’t see text. It sees token IDs — the output of a byte-pair-encoding tokenizer, an intermediate representation that gets thrown away the instant text is stored as UTF-8 and rebuilt from scratch on every single read. A 2026 paper on token-native storage makes the obvious-in-hindsight point that this round-trip is pure waste if the consumer on both ends is a model: skip the translation, store the token IDs directly, and every access downstream gets cheaper. The paper reports storing token IDs as raw integers beats UTF-8 storage for English by roughly 2.25x with no further work, and reaches about 3.3x with entropy coding layered on top, with the broader result — compressed token IDs matching or beating every byte codec tested — holding across six tokenizers and corpora of English, code, and Hindi. It argues the industry should standardize shared tokenizer vocabularies the way it once standardized on ASCII and UTF-8, precisely so more of the pipeline can skip re-tokenizing text that was never going to be read by a person in the first place (Shivendu, arXiv 2608.02376).

That’s the concrete case. The broader trend line is the same shape. Token count has become a first-class cost variable in its own right — enough that the field now produces survey literature on compressing tokens away, driven by the quadratic cost of attention over long inputs (Shao et al., “A Survey of Token Compression for Efficient Multimodal Large Language Models,” arXiv 2507.20198). Once tokens are the budget, format decisions that used to be aesthetic — pretty-printed JSON versus packed binary, verbose keys versus short ones — are now cost decisions, made by the same logic that picks a database index: what does the consumer actually need to read, and what’s the cheapest shape that gives it that.

There’s a second, weirder data point worth sitting with here, because it complicates the tidy story rather than confirming it. A study out of the University of Maryland and Microsoft tested 26 languages against several major models and found English wasn’t even the best-performing natural language for prompting — Polish, French, and Italian all outscored it, with English landing sixth (PureAI, December 2025). English has the largest training corpus of any language on earth and it still isn’t the ceiling. That’s a strange fact to hold next to “the format needs a huge corpus to work” — I’ll come back to it, because it’s the exact tension the counterargument section has to resolve.

Layer two: protocol, or how the UI got deleted from the middle

The second layer is where two machines talk to each other, and here the compression isn’t about token count — it’s about deleting a step that used to be mandatory.

Before the Model Context Protocol, an agent that needed data from your CRM or your ticketing system went through the same door a person did: a REST API with a schema written for a developer to read the docs, wire up an integration, and maintain a custom connector per service. Anthropic’s original announcement is explicit about the problem this created — every new data source needed its own bespoke implementation, which meant AI systems stayed “trapped behind information silos,” no matter how good the model got (Anthropic, “Introducing the Model Context Protocol,” November 2024). MCP replaced that with a single standard the agent speaks directly to the tool, no human-legible integration layer required in the middle. The protocol didn’t get more readable. It got more standard, which is a different and more important property when the reader on both ends is software. I’ve built one of these servers end to end — wiring an MCP interface into a Phoenix app with Hermes is a good look at what that middle layer actually contains once you strip the UI out of it: no forms, no screens, just typed calls an agent issues and a schema it introspects.

The protocol has kept moving in the same direction since. The most recent MCP spec revision made the core transport stateless and leaner, in the spec’s own framing for better reliability and scalability — which in practice means less connection overhead for agents calling tools constantly, rather than a human clicking through a UI occasionally (Model Context Protocol Blog, “The 2026-07-28 Specification”). And in December 2025, Anthropic donated MCP to a new Agentic AI Foundation under the Linux Foundation, co-founded with Block and OpenAI (Anthropic, “Donating the Model Context Protocol”) — which is what it looks like when a protocol stops being one vendor’s bet and becomes the load-bearing wire format for an entire category. Nobody voted to remove the human from that exchange. It just turned out the exchange was faster and more reliable without one, and speed and reliability won.

There’s earlier academic groundwork pointing at the same destination from a different angle — the Agora protocol, proposed by an Oxford-led group in 2024, frames agent-to-agent communication as a trilemma between versatility, efficiency, and portability, and argues agents should default to standardised routines for frequent communications and drop into natural language only for the rare, novel case (Marro et al., “A Scalable Communication Protocol for Networks of Large Language Models,” arXiv 2410.11905). Agora hasn’t shipped as widely as MCP has, but the direction of travel is the same: natural language is the fallback, not the default, once two machines are the ones doing the talking.

Layer three: the harness that already doesn’t read like English

This is the layer with no vendor announcement, because it isn’t a product — it’s a practice, and I run it myself.

On my own machine, my agent instruction files don’t stay in the English I first wrote them in. I run a command that rewrites them in place into a compressed dialect — articles dropped, filler stripped, full sentences reduced to fragments where a fragment loses nothing — and drops the original prose beside it as a .original.md backup. That backup is the part worth noticing. The human-readable version still exists; it has just been demoted to a copy that nothing in the pipeline reads. The file the agent actually loads is the compressed one. Not because I find the dialect aesthetically pleasing — I don’t, it reads like a telegram — but because the agent doesn’t need “the following file should be read” when “read:” says the identical thing in two fewer words that never mattered to the reader in the first place. I also run a markdown-based agent operating system, files an agent rereads at the start of nearly every session and that I would never hand-format if a human were the only audience — the AIOS pattern, laid out here, is structured the way it is because the consumer is a context window with a budget, not a colleague skimming for the gist. The same shape shows up at the code layer, not just the instruction layer — an Elixir-specific harness encodes the Phoenix and OTP conventions an agent needs on every task as a dense rule list, not a tutorial, because a tutorial is for someone learning the material once and a rule list is for something that rereads it every single time. What actually goes in those files is its own question, and one I’ve worked through over fifty commits; this is about the shape the contents settle into, not the contents.

This is exactly the debate playing out in public right now, and both sides have a real point. One camp is compressing hard: an SRE who stripped markdown decoration and collapsed prose into pipe-delimited key-value notation reports cutting his Claude Code memory system by 60–70% in characters, freeing context budget the agent would otherwise spend re-reading formatting it never needed (TechLoom, “Compress Your CLAUDE.md,” February 2026). The other camp is doing the opposite and has the receipts to back it up: Tyler Folkman documented his own Claude Code context “collapsing” at step 47 of a long session, watching 18,282 tokens of accumulated project knowledge get auto-summarized down to 122 tokens, with measured accuracy dropping from 66.7% to 57.1% the moment that happened — his conclusion, in a post that goes paywalled partway through, is that CLAUDE.md should accumulate knowledge over time rather than get pruned back toward brevity (Folkman, “Your CLAUDE.md should grow, not shrink,” October 2025).

Neither side is arguing for English prose. They’re arguing about which non-English shape wins — dense and short, or structured and long.

That’s the tell. The fight isn’t compression versus no compression. It’s over which machine-native shape wins: TechLoom’s answer is fewer, denser tokens; Folkman’s is more tokens organized as durable structure instead of throwaway prose. Both have already left plain English behind. If you’re carrying a harness file bloated with the prose you’d write for a new hire rather than the fragments an agent actually parses, that’s a live audit question, not a someday one.

Wait — doesn’t a model need a huge human corpus to be any good at a language?

Yes, and this is the strongest objection to everything above, so it gets answered directly rather than waved off. Coding models are measurably better on high-resource languages — Python, JavaScript, Java — than on low-resource ones, and the reason isn’t mysterious: the training corpus for Python is enormous, and the corpus for a brand-new agent-native language is, by definition, close to zero on day one. This is the same structural point I made about reward signals in why coding agents don’t write maintainable code — a model only gets good at what it was actually trained against, and a training run doesn’t retroactively acquire examples that don’t exist yet. A source language with no human authors has no corpus, full stop, and no amount of clever architecture invents one.

Which is the real reason Vercel Labs’ Zero is the essay’s best counter-example rather than its refutation. Shipped in May 2026, Zero is a systems language whose compiler is explicitly built for an AI reader rather than a human one — it emits structured JSON carrying stable, machine-parseable error codes and typed repair ids alongside the English diagnostic text, the same command surfacing both so humans read the message while agents read the code. As of its later releases the compiler’s actual input is a binary graph store, with human-readable .0 source files demoted to a projection of that graph rather than the thing itself (MarkTechPost; InfoQ). It is a genuinely serious, well-funded, well-designed attempt at a source language built for an agent reader — and the ceiling shows up immediately in the discussion around it. One commenter in InfoQ’s roundup makes the obvious objection, that the languages agents end up best at are the ones that show up most in the pretraining data; another pushes back, arguing that major API churn in projects like Svelte suggests training data matters less than expected. The objection is the one that holds. A language with more than 5,200 GitHub stars is competing against Python’s multi-decade, planet-scale corpus, and no amount of design cleverness manufactures two decades of Stack Overflow answers on demand.

That tension resolves cleanly once you separate the layers. The corpus requirement is a source-language problem specifically, because a model has to have learned the language during training to write it well — that’s a weights-time constraint. Context formats, protocols, and harness files don’t have that constraint, because they’re never learned at training time at all. They’re consumed in-context, at inference time, the same session they’re written — a model doesn’t need a corpus of prior CLAUDE.md files to correctly parse the one sitting in its context window right now, any more than it needs prior examples of your specific JSON payload to parse the payload it was just handed. That’s exactly why compression is landing at those three layers first and stalling at the source-code layer: the floor that stops an agent-native source language cold simply isn’t present at layers that were never asking the model to recall anything — only to read.

It also settles which shape compression takes if it does reach code. The dramatic version — a model emitting bytecode or a machine-oriented IR with no readable source in between — needs a new compiler, a new runtime, a new debugger, and a corpus that doesn’t exist, four new things that all have to work before day one. The cheap version needs none of them: keep the entire existing toolchain and let the surface form compress, the way a JS minifier already strips symbols and shortens names, just done by the author instead of the build step. When both produce the same functional output, the cheap one ships first.

What this means if you’re shipping this week

None of this is a reason to go write your instruction files in something clever. It’s a reason to notice you’re probably already three-quarters of the way there and to stop pretending the artifact in front of you is prose.

If your CLAUDE.md, your MCP tool schemas, or your context payloads still read like something written for a new teammate’s first day, you’re paying a real, measurable tax in tokens and in the model’s attention budget for a readability property almost nobody is actually using — the agent rereads that file every session, and it was never the intended audience for the throat-clearing. That’s a different bill from the one I’ve written about before — the hardware and inference cost side of running these systems is about compute; this is about the shape of what you’re feeding the compute, which is a design decision, not a spend decision, and it’s cheaper to fix.

And if the code itself is where you’re spending your attention, worth asking what that code is actually for once its primary reader isn’t a person either — which is the harder, more interesting question I’ve written about separately: source was never really “for” the compiler even in the human era, it was the artifact of a theory someone held in their head. An agent that produces the artifact without holding the theory is a different kind of problem than a badly-formatted context file, and it’s the one that actually costs you six months from now, not six tokens.

Start where the corpus problem doesn’t apply. Audit the files your agent rereads constantly before you touch the language it writes in — that’s the layer already moving, it’s the layer you fully control today, and it’s the one nobody’s shipping a press release about. I help teams run that audit as part of a fractional engineering engagement — usually alongside the architecture and security work, because by the time someone notices their harness has drifted into an unreadable dialect, it’s rarely the only thing that’s drifted.