Thoughtware
Part IV · Consequences

Open Questions and Boundaries

The boundaries this theory does not yet settle, stated precisely enough to be investigated.

5 min read

Thoughtware is proposed here as a way to reason more clearly about software whose behaviour depends materially on machine judgment. Like any architectural theory, however, its usefulness depends not on pretending that every boundary is already settled, but on making the difficult boundaries easier to examine. Several questions remain open and should be treated as part of the research and engineering agenda that follows from the category.

One such question concerns the boundary between a Cognitive Unit and an Agent.

The distinction proposed in this paper is responsibility-based: a CU owns a judgment, while an Agent owns progress toward a goal. In practice, however, a single judgment may require several internal steps, intermediate checks, or even a short reasoning loop. At what point does a sufficiently complex CU become an Agent? The likely answer cannot depend simply on implementation mechanics. The more useful boundary may be whether the internal decisions have independent architectural meaning, deserve separate evaluation, or could reasonably be reused elsewhere.

With Skills in the picture the question becomes sharper rather than harder: where does a Cognitive Unit end, where does a Skill begin, and at what point does a Skill become an Agent? A provisional test can be stated. A Cognitive Unit owns one bounded open decision. A Skill owns one bounded capability whose procedural shape is substantially known. An Agent owns a goal whose trajectory has to be determined while it is being pursued.

The most useful diagnostic concerns what each construct is permitted to change. A Cognitive Unit may change how a judgment is reached. A Skill may change which bounded path through a known capability applies. An Agent may change which capability is undertaken next, and may decide that the goal has been achieved. Real systems will still contain ambiguous cases, but the theory now offers a language in which those cases can be argued about precisely.

A second and smaller boundary sits alongside it. When does procedural state become agentic state? A Skill may hold state for the duration of an invocation in order to perform its procedure, and that is unremarkable. It begins to acquire agency when it needs historical state — what has been attempted before, and how it went — in order to decide which procedure it should undertake at all.

A second question concerns the external determinism expected of cognitive components. A CU may be probabilistic internally while still presenting a stable responsibility and result contract to the rest of the system. But how stable must that behaviour be before other components can safely depend on it? Traditional APIs can preserve identical signatures while cognitive behaviour changes substantially. This creates a related problem of versioning. A new model, prompt strategy, knowledge source, or reasoning method may improve average performance while altering edge-case behaviour even though no interface has changed. Cognitive versioning may therefore need to account for behavioural performance, evaluation results, and known failure characteristics in addition to conventional API compatibility.

There is also an unresolved tension around inspectability. Cognitive encapsulation argues that callers should not depend on prompts or internal reasoning strategies. Governance and debugging, however, often require some visibility into why a judgment occurred. Complete exposure of internal reasoning may be undesirable, unreliable, or unnecessary, while complete opacity can make failures difficult to investigate. Thoughtware therefore needs better forms of inspectability that preserve implementation independence while still exposing evidence, decision factors, confidence, provenance, and other useful traces of behaviour.

The progression from experience to expertise introduces another boundary. Not every remembered case should influence future behaviour, and not every recurring pattern deserves architectural permanence. Systems need ways to determine when a pattern is sufficiently general, stable, and well evaluated to become reusable expertise. They also need mechanisms for revising or retiring expertise when environments, policies, or underlying conditions change.

Evaluation introduces its own recursive problem. If one cognitive capability judges another, who evaluates the judge? Automated judges can be biased, correlated with the system they evaluate, or poorly calibrated against actual domain expectations. Better methods are needed for combining judge CUs, human reference judgments, disagreement analysis, calibration sets, and meta-evaluation without simply moving uncertainty one level higher.

Finally, the question of authority remains partly technical and partly institutional. Capability alone cannot determine how much responsibility software should receive. Consequence, reversibility, uncertainty, accountability, regulation, and social expectations all affect whether a system should act, recommend, ask, or escalate. The appropriate boundary will differ across domains and may change as evaluation evidence accumulates.

These questions do not weaken the case for Thoughtware. They reveal the kinds of problems that become visible once cognition is treated architecturally rather than as an undifferentiated AI feature. A useful theory should not eliminate such questions prematurely. It should provide a language in which they can be stated precisely, investigated systematically, and progressively resolved.