Speak English About AI
Jargon is a tax you pay in stakeholders. Plain language isn't dumbing it down; it's the half of deployment nobody budgets for.

I don't say "agentic" in meetings.
Not because the word is wrong. Because the moment I say it, half the room stops evaluating the project and starts evaluating whether they belong in the conversation. They do belong. My vocabulary just told them otherwise.
I build production AI systems: pipelines, agents, quality gates, the full stack. And the skill that has moved more projects from slide to production than any of it is the unglamorous one. I speak English about this stuff.
Jargon is a tax
Here's the mechanic nobody watches happen. You're presenting an AI initiative. You say "we'll use retrieval-augmented generation over a semantic layer with agentic orchestration." Three stakeholders just checked out. None of them will say so. People do not raise their hand to announce they don't know a word. They go quiet, they stop asking questions, and three weeks later the project has "alignment issues" that are actually comprehension issues nobody would name.
Every unexplained term costs you a stakeholder, and adoption dies politely in the hallway.
Now the same system in English: "The software reads the same reports your team already reads, drafts the answer, and a checker makes sure the numbers tie before anyone sees it."
Same architecture. Zero information lost. But this version invites the operations lead to say "what happens when the numbers don't tie?" — which is exactly the conversation you need, with exactly the person who knows where the bodies are buried.
The model working is half the job. The other half is a room full of people deciding they trust it enough to change how they work. Nobody trusts what they can't understand.
Plain language is proof, not simplification
There's a status game in tech where complexity of vocabulary signals depth of understanding. Production work taught me the opposite. The people who understand a system most deeply describe it most plainly, because they know which details carry weight and which are decoration.
If I can't explain what a system does to a dispatcher or a CFO in one breath, that is not their gap. It's mine. Either I don't understand the system well enough to compress it, or the system doesn't do anything clear enough to compress. Both are findings. Both are mine to fix before the build starts, not after.
<aside> The honest caveat: precision matters between engineers. "Agentic" and "RAG" exist because they compress real distinctions, and I use them constantly in technical rooms. The skill isn't avoiding jargon everywhere. It's knowing which room you're in, and never using a term as a substitute for being understood. </aside>The Translation Table
The working artifact. Left column is what gets said in tech rooms; right column is what I say everywhere else. Steal it, extend it, argue with it.
| The jargon | The English |
|---|---|
| Agentic workflow | Software that can take the next step on its own instead of waiting for a person |
| RAG / retrieval-augmented generation | The AI looks things up in your documents before it answers, instead of guessing from memory |
| LLM | Software that reads and writes language well enough to do desk work |
| Fine-tuning | Training the AI on your examples so it picks up how your business does things |
| Hallucination | The AI states something false with full confidence |
| Evals / quality gates | Tests the output has to pass before anyone is allowed to see it |
| Ground truth | A number we already know is right, that the AI's answer has to match |
| Orchestration | Deciding which tool or step runs, in what order, and what happens when one fails |
| Context window | How much the AI can keep in mind at once |
| Human in the loop | A person signs off before anything real happens |
Notice what the right column does: every line answers "what does this mean for how work gets done here?" That's the test. A translation that doesn't touch someone's actual workday isn't a translation, it's a shorter kind of jargon.
The rule I run
Every AI concept in a proposal gets one sentence a smart person outside tech would nod at. If I can't produce the sentence, I'm not ready to build the thing, because I clearly haven't decided what it does for the business yet.
This rule has killed projects at the whiteboard stage. Good. Those were projects that would have died in month four instead, after budget.
The teams winning with AI aren't the ones with the best vocabulary. They're the ones where everyone in the room, ops, finance, the field, understands what's being built well enough to improve it.
Speak English. Ship more.
Verified in this piece: no production figures used; the Translation Table is the artifact. Next in this series: to be linked.
I ship AI-built software into production and write about the gates, patterns, and cost discipline that make it work. More about me →
Practitioner notes on the gates, the patterns, and the cost discipline behind AI-built software.
Related reading
Seven gates, each one blocking the next. Most projects should die at Gate 1, and the ones that survive all seven are the ones people actually trust.
Prompting, examples, review: you learned all of it the first time you delegated. AI fluency is management fluency with a shorter feedback loop.