Thoughtware
Part I · The Shift

The Missing Category

Why implementation vocabulary — LLM application, RAG, agent, copilot — names the machinery rather than the software category.

6 min read

The emergence of cognitive capability in software has produced an equally rapid expansion of vocabulary. We speak of LLM applications, AI applications, copilots, chatbots, retrieval-augmented generation, agents, agentic systems, workflows, multimodal systems, and increasingly complex combinations of these ideas. Each term is useful within its own scope. Some describe a model or technical mechanism. Others describe an interaction pattern, an orchestration strategy, or a degree of autonomy. Together, they give us a language for discussing how contemporary AI systems are implemented.

What they do not yet give us is a durable name for the class of software being created.

This distinction matters because implementation vocabulary and category vocabulary serve different purposes. HTTP is fundamental to the web, but we do not define a web application as an HTTP application. A product that relies extensively on a relational database is not normally understood as a SQL application. Cloud systems may depend on containers, orchestration platforms, distributed storage, and service meshes, yet “container software” would tell us very little about the nature of the system itself. These technologies remain important, but they sit beneath a more stable description of what has been built.

Emerging technologies tend to make their infrastructure unusually visible. When a capability is new, both builders and users pay close attention to its mechanisms.

The mechanism becomes part of the product vocabulary because it is novel, differentiating, and still poorly abstracted. Over time, successful infrastructure becomes less conspicuous. It does not become less important. It becomes sufficiently normal that it can disappear beneath the conceptual surface of the product.

Much of the current language of AI reflects this transitional moment. “RAG application” identifies a retrieval technique. “Agent” identifies a form of goal-directed orchestration. “Copilot” usually describes a relationship between a user and an assisting system. “Chatbot” describes an interface pattern. “Multimodal” describes the kinds of information a system can process. Even “LLM application” defines software by the model family currently responsible for some of its capability. None of these terms necessarily survives a change in the mechanism beneath it.

A useful category should survive such changes. It should continue to describe the system if one model is replaced by another, if retrieval techniques evolve, if prompts become automatically generated, if an agent framework disappears, or if the product stops presenting itself through a conversational interface. It should describe what has become structurally different about the software rather than which generation of AI infrastructure happens to implement it.

This paper proposes Thoughtware as that category.

Thoughtware is software in which cognitive capabilities such as interpretation, reasoning, judgment, evaluation, and adaptation are organised as first-class components of the system.

The emphasis is on organisation. Thoughtware is not simply software that happens to call a model. It is software whose architecture assigns meaningful responsibilities to cognitive capability. Some part of the system is expected not merely to execute a predetermined procedure, but to interpret a situation, form a judgment, evaluate possibilities, or adapt its behaviour within defined boundaries. These responsibilities become part of how the software is decomposed, specified, tested, governed, and improved.

This boundary is important because the presence of an LLM alone is not enough. A deterministic product that generates a friendly greeting with a language model has not necessarily become Thoughtware. Neither has a static summarisation button, a thin API wrapper around a model, or a chatbot added to the edge of an otherwise unchanged application. Such features may use sophisticated models, but the cognitive capability remains incidental to the architecture. The underlying system could often remove that capability without changing how its primary responsibilities are organised.

Thoughtware begins to emerge when cognition becomes structurally consequential. A practical qualification test is therefore useful. A system increasingly belongs to this category when meaningful judgment is delegated to it, when cognitive responsibilities are deliberately located within the architecture, when the inputs and outputs of those responsibilities can be identified, when their behaviour is evaluated rather than merely assumed to be satisfactory, and when those capabilities can evolve without requiring the surrounding product to be conventionally rewritten each time.

These criteria are intentionally architectural rather than technological. They do not require a particular model, framework, interface, or deployment pattern. A Thoughtware system might contain language models, vision models, specialist models, deterministic algorithms, conventional services, human approvals, and tools that have no cognitive behaviour at all. The defining question is not which technologies are present. It is whether cognitive responsibility has become an organised part of the software.

This leads to the central proposition of the category: Thoughtware is an architectural category, not a model category. Models provide capability, but they do not by themselves determine the structure of the resulting system. The architectural task begins when that capability must be divided into responsibilities, combined with deterministic mechanisms, constrained by authority, observed, evaluated, reused, and improved.

Naming the category therefore does more than provide a convenient label. It changes the level at which the problem can be discussed. Instead of asking only which model, retrieval method, prompting technique, or agent framework should be used, we can ask what kinds of cognitive responsibility the software should contain and how those responsibilities should be organised.

Having named the category, the next question is more fundamental: what, exactly, is the new material being organised inside it?