The Naming Decides Who Will Run the Machines

Demos sell agentic systems. Contracts inherit them. That gap is where most technology decisions quietly go wrong: the purchase is made against a performance, and the ownership is exercised against a structure nobody named. Six months after signing, the owner cannot say what was bought, the vendor cannot be asked a sharp question, and there is no shared noun for anyone to argue about.

The naming decides who will run the machines, because a name is the only handle the owner keeps after the room lights come up. If the system has no kind, it has no questions. There is nothing to ask at renewal, nothing to audit after an incident, and nothing to compare when the next vendor walks in. The IR-Taxonomy is ASKA's attempt to fix that with plain language: a public classification of agentic systems into five kinds, each one a sentence a non-engineer can say out loud. It grew out of our own repositioning work, when we needed a way to describe what we run without either drowning in jargon or flattering the software.

The five names first, each in one plain sentence: what the system does, not how it does it.

• An executable agent takes a task you hand it, produces the result, and stops when the task is done.
• A proactive agent watches something and acts on its own when what it watches changes.
• A proactive plex is a set of proactive agents held together on one standing watch.
• A learner agent changes what it does next based on what it has already seen.
• An orchestrating agentic hub decides which agents work next, reads their results, and answers for the whole outcome.

Each name is a question the reader is meant to answer, not an instruction to obey. The sections below are the question each name puts in the owner's hand, and what changes once the name is said out loud.

1. Executable Agent

The plainest of the five, and most of what is sold as an agent today is exactly this: a worker that waits to be spoken to. The name is not an insult. It commits you to one honest check, because the human keeps the watch. Nothing runs by itself, nothing notices anything, and every cycle needs a person to ask. The question this kind forces at purchase is simple: who presses go, and how many times a day will they realistically do it?

Teams that buy this kind and staff it like an autonomous system drown politely. The fees are cheap and the attention is not. Teams that name it honestly learn the real price up front, which is people, not paperwork. There is something to value here too: with no standing behavior, there is very little to audit. Failures happen in front of someone, because someone is what makes it run.

2. Proactive Agent

This name marks the first threshold that matters to an owner: the system now moves before anyone asks. That is what every demo shows and almost no contract says. The question this kind forces: what does it watch, and what is it permitted to do without a person in the loop? Write those two sentences down before you sign. If the vendor cannot write them, you have not bought a proactive agent. You have bought an executable agent with a timer and a story attached.

The risk profile changes shape at this threshold, and it is worth stating plainly. An executable agent fails visibly. A proactive agent can fail silently, by not firing, and silence is the expensive direction to be wrong in. Ownership means asking, on a schedule, what the watch would have done, whether it did, and where that answer is recorded for someone to read afterward.

3. Proactive Plex

A proactive plex is several proactive agents held on the same standing watch, and the plex is the word for the moment one watch becomes a rota. Agents on standing duty, each covering a different slice, all bound to one continuing mission: one watches what arrived, one watches what the others did, one watches whether anything broke. The reason it needs its own name is that responsibility does not divide by headcount. The question this kind forces: when two agents on the same watch disagree, or one of them stops speaking, who notices, and which of them was carrying the duty?

A plex with no answer to that is a group chat, not a watch. This is also the kind buyers most often overbuy, because six moving parts look more capable than one. The plex costs more than its parts, and the extra is not in the contract but in supervision. In our own practice the answer takes the shape of role-based lanes, steering, and a serving gate that checks the output before it counts as done. Every one of those is an operating cost, not a software feature, and the name is what lets you ask for it before the purchase instead of discovering it during the incident.

4. Learner Agent

The learner agent carries the most marketing weight of the five names, so the plain sentence has to do the real work: it changes what it does next based on what it has already seen. The question this kind forces: what carries over from the last run to this one, where does it live, and who can read it afterward? A learner that writes its lessons into a model no one can inspect is a different purchase from one that writes them into durable state an auditor can read line by line. The demo looks the same in both cases. The ownership is not the same.

This is the kind where the difference between memory and record shows up on the invoice. What we hold ourselves to is a verified write-back: a lesson counts as learned only when it lands as a readable entry, staged first, then checked against the artifact the work is actually served from. If the change cannot be written down, you do not own a learner agent. You own an executable agent whose vendor calls history by another name.

5. Orchestrating Agentic Hub

An orchestrating agentic hub does not do the task. It runs those who do: it assigns the work, reads the returns, and answers for the whole result. It is the most demanding kind for an owner, because it carries the other names inside itself and it moves the accountability line. Two questions belong together here. When the hub assigns work to an agent you did not choose, was that your decision or the vendor's? And can the hub be overruled while it is running, or only after it has failed? An owner who cannot answer these is not buying an orchestrating agentic hub. They are outsourcing a management position to software and calling it procurement.

The hub is also where the machinery of a durable operating system earns its keep. Knowledge routing, role-based lanes, gates on the output: those exist so that a hub's decisions are readable after the fact instead of mystical. The hub is what an owner buys when the work itself no longer fits in one pair of hands. Name the kind and you can demand the readable version of it by name.

6. Who the Language Is For, and What It Is Not

The reader of this language is the owner of a technology decision. That means the buyer, the operator who inherits the purchase, the director who signs, and the person who will still be there after the demo team leaves. Most of them do not write code, and the sentences above are deliberately short enough for them to use. The taxonomy is task-agnostic by design, so this article is honestly not about running any of these kinds on your project. The shape of what you own is settled before the first task arrives, and naming is how that shape gets said out loud while there is still time.

What it is not, in the same plain voice: it is not a metric. There is no score, no index, no benchmark attached to the five names. It is not a proof of competence; a system can be a genuine proactive plex and still be badly run. It is not a promise; naming a kind obliges no one's outcome. And it is not a qualification. Nothing earns a certificate for being a learner agent, and the ladder reading is the failure mode to watch for, because there is no ladder here. A cheap executable agent that fits the work beats the most autonomous kind that does not. These are five kinds, not five ranks. The whole job of the language is to make two parties mean the same thing by the same noun.

7. The Honest Limit

A name is trivially cheap to claim. Anyone can print orchestrating agentic hub on a slide, and the vocabulary arrives without the duty that should travel with it. The taxonomy settles the shape of the question, not the evidence. The checking still belongs to the buyer, or to whoever the buyer hires to do it. A classification language that could not be misused by a vendor would also be too specific to be useful to one; that trade-off is the price of plain words, and it is worth paying knowingly.

The kinds are coarse on purpose. Real systems cross them: a hub that also executes, a proactive agent with one narrow learned rule, a plex where two of its members are really timers in costume. The language describes the dominant behavior, not a purity test, and crossing is a conversation to have, not a disqualification to accept. What the taxonomy also cannot do is tell you which kind is right for your work. It says what you own. Whether that is what you should own is a judgment it deliberately refuses to make for you.

And the limit about us. The IR-Taxonomy was invented inside one small consultancy's own repositioning work and sharpened against our own operating decisions. It is not a standard. There is no committee behind it, no certification body, and no stranger's procurement record that cites it yet. The same honesty the site's operating essay keeps about its own kit applies here: it asserts usefulness; it does not yet demonstrate adoption outside our own walls. Until some buyer uses these five names to reject a bad purchase or scope a good one, treat the taxonomy as a disciplined question set, not a compliance frame.

8. Compressed Version

Agentic systems are sold on demos and lived in as structures, and the gap between the two is closed by naming. The IR-Taxonomy puts five plain names on that gap: an executable agent does what it is handed; a proactive agent acts on its own watch; a proactive plex holds several such watches on one mission; a learner agent carries its past into its next run; an orchestrating agentic hub runs the other agents and answers for the result. Each kind is one sentence about what the system does, and one question the owner is entitled to have answered in writing: who presses go; what does it watch; who notices the gap; what carries over; whose decision was that.

The language is for the owner of the technology decision, not the engineer who builds it. It is task-agnostic, and it carries no metric, no proof of competence, and no promise. It ranks nothing. The cheapest kind that fits the work beats the most autonomous kind that does not, and a shared noun that both parties can say out loud is worth more than any demo, because the demo ends and the noun is what you ask questions with.

The limits travel with it: a name can be claimed by anyone, the categories are deliberately coarse, and no committee stands behind the words. The taxonomy is the question. The evidence is still the owner's job. The demo decides who sells. The naming decides who will run the machines.