Where does a decision live?

In conventional software, when something goes wrong, you can often point. A rule lived in a condition. A calculation lived in a function. A permission lived in a policy check. The system might be large and complicated, but its decisions had identifiable homes.

Systems built on language models behave differently. A decision might emerge from the combination of a model, an instruction, retrieved context, previous conversation, examples, tool results, and the way several calls were arranged. The system can interpret a request, compare alternatives, recommend a path, notice a weakness in its own output, and try again. Yet when a team is asked a simple architectural question, which component decides whether the request is clear enough?, where is the judgment about whether a plan is practical?, the honest answer is often: somewhere inside a large prompt, or across several prompts, or in a loosely connected chain of model calls.

The system works. Its cognition has not been given a structure people can point to.

That is the gap Thoughtware is meant to close. Not by inventing new capabilities, the capabilities are already in the call sites, but by treating judgment as a packageable material. Name the piece of thinking. Give it inputs and outputs. Place it inside an agent that owns a goal. Surround it with knowledge, experience, retrospection, bridging, and evaluation so that improvement has somewhere to land.

The next time a behaviour improves or worsens, the useful sentence is not “the model got better” or “we tweaked the prompt.” It is: this decision lives here, and then you act there.