Same Word, Different Things

I was in a conversation where three people were disagreeing about AI. It took a while before I realised they weren't disagreeing. They were using the same word for different things and believed they were arguing about method.

They were arguing about words.

Three Words That Don't Mean One Thing

Say "skill". For one person it's a folder on their computer that a local tool reads. For another it's something you upload and call programmatically. For a third it's a self-generated entity in an agent framework triggered by incoming messages.

Three completely different things. Same word. And they differ on exactly what matters: where it lives, how it starts, whether it can be handed over to someone else.

Say "agent". Now it's worse. It can mean a named product. It can mean an architectural pattern -- a model in a loop with tools and memory. It can mean a degree of autonomy, ranging from a scripted step to something that acts without being told. And it can mean a metaphor, an "employee in a box". Four registers, one word, and they slide into each other mid-sentence.

Say "automation". For someone who builds pipelines it's a first-class category -- the stable layer. For someone who thinks in processes it's not a concept at all, just a process divided into steps. So "I have zero automations" can mean two completely opposite things. Either "I automate nothing" or "I don't think in that category". Completely different people saying the same sentence.

Why That's Not Harmless

This isn't semantics for its own sake. When a word means several things, you draw valid conclusions about one meaning and apply them invalidly to another.

An example I came across: "it can't be productised, it can only run locally." True -- if you mean one kind of skill. Completely wrong if you mean the other, which has an open interface for being triggered externally. The same word carried the conclusion straight across a boundary where it no longer held. And then you build a business strategy on a barrier that doesn't exist.

Logicians call it equivocation. It sounds academic. In practice it looks like two competent people talking past each other for an hour and leaving convinced they disagree.

The Question That Solves It

Before you decide whether to build agents, or whether something can be sold, or whether a tool is a dead end -- ask one question first.

Which kind of thing, in which context?

That question is tedious. It stops the momentum in a room that wants to move forward. But it's the difference between solving the problem and fixing the wrong thing with great conviction.

Most of what sounds like disagreement about what to do is disagreement about what you're talking about.