Why the words we have fail

An architecture review can name the model, prompts, retrieval, tools, memory, agent loop, and evaluator in detail—and still leave one basic question unanswered: what kind of system has been built?

The problem is not that these words are false or vague. They operate at different layers, while none of them names the architecture of responsibility. A model supplies capability; retrieval supplies material; a tool enables an action; an agent may describe an execution pattern. None tells a reviewer where a meaningful decision lives or who can improve it.

Helpful context: Language is the abstraction above thinking explains why vocabulary is architecturally consequential. A category, not a mechanism clarifies the role Thoughtware is meant to play; the cognitive unit turns a named decision into a contract.

A flat list hides the layers

“Copilot” describes the user's relationship with a product, whereas “agent” and “workflow” describe possible structures. Retrieval and prompting describe mechanisms within those structures, and a model and vector store are implementation substrates. They therefore cannot serve as interchangeable names for the whole.

When all these terms appear in one undifferentiated list, any one can impersonate the whole. A team may say it is building a copilot when the real issue is whether a component owns meal practicality; or debate retrieval before deciding which information is authoritative enough to retrieve.

The word agent shows the problem in miniature. In ordinary product talk it can mean a chatbot persona, a loop that calls tools, a workflow runner, a delegated business role, or a system with authority to act. Those meanings overlap in demos and diverge in incidents. A household does not care which one the team meant until the product buys groceries, remembers an inference, or answers a medical constraint as though it had authority.

Word in the meeting	What it often names	What it leaves unanswered
Model	Capability source	Which judgment is being performed
RAG	Material supply	Whether the material is endorsed or merely retrieved
Agent	Loop, persona, or role	What goal it owns and what authority it has
Memory	Stored influence	Whether the record is context, knowledge, experience, or expertise
Evaluator	A scoring mechanism	Which responsibility the score is evidence for

The terms are useful once the architectural object is known. They are dangerous when they are asked to create the object by themselves.

The questions that remain unanswered

An architecture needs to answer which judgments have been delegated, what evidence may influence them, what stays deterministic, where authority stops, and how quality is evaluated. Mechanism vocabulary cannot answer these questions because it was never designed to.

That leaves decisions to settle by accident: a prompt clause, a UI default, and a ranking weight each start shaping what counts as a busy-night meal. The system has a decision, but no architectural place that acknowledges it.

The parts are visible. The whole remains unnamed.

Introduction to Thoughtware · Ch. 5

A useful name must carry a boundary

New vocabulary earns its place only when it creates a stable object for engineering. A useful name has an identity that survives changes to its model or prompt; a defined extent, so cost and quality measurements have a meaning; and a statement of the decision it owns.

That is why naming a cognitive unit is more than moving prompts into a folder. The name creates a contract that callers can rely on and an evaluation target that the team can improve. Without such boundaries, new labels are only branding.

Rewrite one feature description

Take “the agent remembers allergies and uses RAG to plan meals.” Rewrite it in decisions: the allergy is endorsed household knowledge, deterministic validation enforces it, AssessMealPracticality judges a candidate against this week's constraints, and the planning agent coordinates an acceptable week. The rewrite is longer, but it makes the architecture reviewable.

Mechanism words still have their place

The remedy is not to ban technical vocabulary. A team must know which model it deploys, how retrieval is evaluated, what tool permissions exist, and how a workflow is orchestrated. These are implementation questions, and precise mechanism names are indispensable when answering them.

The mistake is allowing mechanism names to end the conversation. “We use RAG” explains how material may reach a model. It does not explain whether the material is authoritative, whether the resulting judgment has a contract, or whether the product may act on the result. “We have an agent” may explain that a loop coordinates tools, but it says nothing about which outcome the loop is accountable for reaching.

Once the architectural boundaries are named, the mechanism discussion becomes better rather than smaller. The team can ask which retrieval source a particular cognitive unit may use, which model can meet its evaluation standard, or where deterministic validation must remain outside the model. Mechanisms become choices in service of a declared responsibility.

Naming changes what can be measured

An accuracy figure is meaningless when it is attached to “the assistant.” Does it measure request interpretation, retrieval relevance, meal practicality, final prose, or the whole trajectory? The denominator shifts with every reader.

A named decision fixes the object of measurement. AssessMealPracticality can have a case suite, a cost profile, a latency budget, and an owner. A change to its prompt or model can be compared against those measures without claiming that the entire product became better or worse. This is the practical value of a vocabulary that identifies architectural objects: it creates stable units for evaluation and improvement.

The same holds for governance. A permission may attach to a purchase action, not to “the agent.” Provenance may attach to household knowledge, not to “memory.” Once the name identifies the boundary, an audit can ask who wrote it, who may change it, and what depends on it.

A test for a useful replacement

Before introducing a new category word, try to use it in four sentences: what does it decide, what inputs may it use, how is its quality measured, and what may it not do? If the answers remain vague, the word has not yet earned a place in the architecture. If the answers become concrete, the term is doing useful work rather than adding another layer of branding.

Read next: A category, not a mechanism explains the kind of name Thoughtware is intended to provide.