We made our AI agents talk like aircraft manuals

On 6 August 2026 we added one standing rule to the agent-instruction file of every repo we operate: AI agents must communicate with us in ASD-STE100 Simplified Technical English by default. 19 repos, 8 pull requests, one afternoon. Here is why, and what it looks like.

What Simplified Technical English is

ASD-STE100 is a controlled language specification from the European aerospace and defence industry. It exists because aircraft maintenance manuals get read by mechanics all over the world, many of them non-native English speakers, doing work where a misread sentence can kill someone. So the industry stopped trusting natural English and built a constrained one.

The core rules: a limited dictionary of approved words. One word, one meaning (in STE, "follow" only means "come after"; if you mean obey, you write "obey"). Instructions of 20 words or fewer, one instruction per sentence. Active voice. Articles kept, because dropping "the" is how ambiguity sneaks in. Technical names stay verbatim.

None of this makes prose beautiful. All of it makes prose hard to misread. That is the trade, and aerospace decided decades ago it was worth it.

Why agents have the same problem as maintenance manuals

We run agent swarms daily. We write the spec, hand the diff to the agents, and decide what ships based on evals. The bottleneck is never the agent's typing speed. It is the moment a human reads the agent's reply and decides what is actually true.

Default model output is optimized to sound helpful, and helpful-sounding English is where misreads hide. "The deployment appears to have completed successfully, although there may be some propagation delays" contains one fact and three escape hatches. Hedges, synonym-hopping, and 40-word sentences are the same failure surface the aerospace industry engineered away. An agent that is confidently wrong in vague prose costs more than one that is wrong in checkable sentences.

The rule we shipped

This exact section now sits in every CLAUDE.md we maintain:

## Communication style: Simplified Technical English

Communicate with the user in ASD-STE100 Simplified Technical English by
default. In chat replies, explanations, reports, and summaries:

- Write short sentences. Keep instructions to 20 words or fewer and
  descriptions to 25 words or fewer.
- Give one instruction per sentence. Use the active voice.
- Use one word for one meaning. Do not switch synonyms for variety.
- Use simple words. Prefer "start" over "initiate", "use" over "utilize",
  "show" over "demonstrate".
- Use articles (a, an, the) where grammar needs them.
- Keep paragraphs to one topic, six sentences or fewer.

Scope: this governs how Claude talks to the user in this repo. It does not
change published site copy, code, commit messages, or any content that has
its own voice rules; those rules stay in force.

The scope line matters. Our published copy has its own voice rules and would die in STE. Our audit reports have their own format. This rule governs one thing: how an agent talks to us while we work.

Before and after

A status update, the way agents write by default:

I've gone ahead and implemented the requested changes and also took the liberty of refactoring some adjacent utility functions, which should hopefully improve maintainability going forward, though you may want to double-check some of the edge cases.

The same update in STE:

I changed the two files you named. I also changed format.ts, which you did not ask for. Check the date edge cases in format.ts before you merge.

The second version is shorter, but that is not the point. The point is what it forces out into the open: the unrequested change stops hiding inside "adjacent utility functions", and "double-check some of the edge cases" becomes a specific file and a specific risk.

A deploy report, before:

The deployment appears to have completed successfully, although there may be some propagation delays, so the changes might not be immediately visible.

After:

The deploy is live. version.json reports commit f31b0b7. The CDN can take 2 minutes to show new pages. Check again at 14:32 if the page is old.

And the synonym rule, which sounds pedantic until you have been burned. An agent that writes "verified" in one paragraph, "validated" in the next, and "confirmed" in the third invites you to wonder whether those were three different checks. Under one-word-one-meaning, three checks get three names or one name three times, and the count of what actually happened is never a puzzle.

How the rollout went

• 19 repos and folders carry the rule: the studio site, the founder's personal site, Social Desk, our open-source tools (cld-flare-maxxing, the Jan Aushadhi finder, the DPDPA skill), and the internal ones.
• 8 landed through pull requests because those repos require review before main moves; the rest took direct commits or, for two local-only folders, a plain file edit.
• One repo rejected the push outright: cld-flare-maxxing protects main behind a required status check, so the rule went in through an auto-merged PR after its verify job passed. Our own guardrail slowed us down, which is the guardrail working.

The honest tradeoffs

STE reads blunt. The approved-dictionary idea does not map cleanly onto software, where the real vocabulary is API names and error strings, so we keep technical terms verbatim and apply the sentence rules around them. And a default is not a straitjacket: a design discussion sometimes needs a long sentence, and the rule text says "by default", not "always".

The deeper reason this fits us: we sell audits, and an audit report lives or dies on whether a finding can be misread. Practicing unambiguous language on every internal reply is free training for the thing clients actually pay for.