Why the words fight

Lesson 1 of 4 in The Words People Use — Agent, Agentic, Copilot, Assistant.

You have just learned a precise definition of an agent. Now you walk into a vendor demo, a job posting, or an analyst report, and the words stop cooperating. One page says agent. The next says agentic AI, and insists it means something different. A third sells you a copilot, a fourth a digital worker, a fifth intelligent process automation. Nothing lines up.

This is not your reading comprehension failing. The vocabulary genuinely conflicts, because it was never designed — it accumulated. Four sources pushed words into the same space at once:

  • Prior automation waves left their nouns behind. Companies have been automating clerical work for decades: shell scripts and spreadsheet macros, then process-diagram engines in the 1990s, then software that drove existing applications through their own screens in the 2010s. Each wave named itself, each name survived its wave, and each got resold when the next wave arrived — because buyers already had a budget line called automation.
  • Product marketing needs a word that is new enough to justify a new purchase and familiar enough to explain in one line.
  • Analyst firms need category names to rank vendors inside, so they mint them, and vendors then describe themselves in whichever category they can win.
  • Research papers contribute the most careful definitions and the least commercial pressure to honour them.

Then commercial gravity finishes the job. Once one word starts closing deals, everyone reaches for it — and a word that describes every product describes no product. That is not a moral failing on anyone’s part; it is what happens to any label with money attached. Cloud, big data and machine learning all went through the same flattening.

The cost lands on you, and it is specific: two people can agree on a word and disagree about the system. You buy an “agentic platform” expecting software that will handle inputs nobody anticipated; you receive a well-built workflow with sixteen predefined branches. Nobody lied. You tested for the wrong thing, budgeted for the wrong failure modes, and staffed the wrong oversight. The reverse hurts too: you buy expecting a fixed pipeline you can assert against, and you get a model choosing its own path through tools that touch production.

Key terms: agent, workflow, model-directed control flow, orchestration, autonomy

The translation move

  1. You hear a product word

    “Agentic.” “Copilot.” “Digital worker.” “Autonomous.” Any of them.

  2. Park the noun

    Do not argue about the word. You will not win, and the word is not the thing you need to know.

  3. Which decisions does the model make at runtime?

    Ask for the answer in terms of a concrete input: “Show me what happens when a request arrives that nobody designed for.”

  4. A named, fixed set of steps

    The model may fill in individual steps, but the path is human-authored. Workflow-shaped, whatever the label.

  5. The model chooses the path

    Tool selection and ordering are decided per run from what was just observed. Agent-shaped, even if the page says “assistant.”

  6. Nobody can answer clearly

    The most common outcome in a first conversation — and useful information rather than a dead end.

  7. Test with assertions; bounded by design
  8. Needs evals, traces, containment
  9. Verdict: unknown. Keep asking.

Why not just publish a correct taxonomy and be done with it?

People try, constantly, and the attempts are often thoughtful. The problem is that a taxonomy only helps if the person across the table shares it. Yours says copilot implies a human approves each action; theirs says copilot is the brand family their product ships under. You now have two internally consistent glossaries and one mismatched purchase.

Worse, a memorised taxonomy feels like knowledge, so it suppresses the follow-up question you needed to ask. Vocabulary is a lossy channel; the disambiguating question routes around it.

Isn’t this just semantics? The system does what it does.

The system does — but you have to decide how to test it, how much authority to give it, and what to monitor. Those three decisions differ sharply between fixed-path and model-directed systems, and the word is usually the only information you have before the contract is signed.

Concretely: a fixed-path system with sixteen branches can be regression-tested. A model-directed system needs pass rates over many runs, because one clean demo is a single sample from a distribution. Buy one and staff for the other and the gap shows up in production, not in the demo.

What if the vendor genuinely does not know the answer?

It happens, and it is not always a red flag — the person in the room may be in sales, not engineering. Escalate the question rather than the objection: ask for the runtime behaviour on an unanticipated input, ask what the system can do without asking anyone, and ask what stops it. Lesson 4 turns those three follow-ups into a walkthrough.

If nobody in the vendor’s organisation can answer, that is the finding. A team that cannot say which decisions their model makes at runtime is missing a fact they would also need in order to test the system or respond to an incident — which is why the non-answer is worth recording rather than shrugging off.

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.