Human analogies can motivate functions without determining component boundaries

Type: kb/types/note.md · Tags: foundations, computational-model

Humans are a familiar example of systems that remember, interpret, act, and adapt over time. Analogies to human cognition can therefore suggest a function an agent may need or a failure it may need to prevent. Because those functions appear unified in one person, however, the analogy can also lead designers to inherit a component decomposition—which roles are grouped into one component—before comparing alternatives. For example, a three-space agent-memory proposal maps Tulving's semantic, episodic, and procedural categories onto knowledge, self, and operational spaces, while leaving open whether different retention lifecycles rather than the cognitive taxonomy warrant that separation.

The functional inference and the architectural inference are different. A human analogy may suggest that user-specific intent must persist, relevant experience must affect current action, or identity must remain coherent. Resemblance alone does not show that persistence, activation, interpretation, and action should occur in one engineered component. Their bundling in humans supplies a boundary hypothesis, not target-side warrant. A target may nevertheless need the same exposed boundary for an independent reason. For example, an operator-facing audit and correction interface may require one inspectable “memory” object even when its internal mechanisms do not resemble human memory. The analogy may suggest the familiar boundary, but the target-side audit and interface requirement warrants it. Familiar labels can conceal this distinction. “Memory,” for example, spans storage, contextual activation, learning, and action because agent memory is a crosscutting concern rather than a separable niche.

Personalization makes the distinction visible. A human editor can remember a writer's aims and use them to interpret a terse new request. An agent system can reproduce similar behavior through several allocations. A model may interpret the request from live context or a retained artifact that carries the aims. A context engine may activate the relevant record, while a separate policy—or the user—decides which source may govern current behavior. Alternatively, user-specific aims or response patterns may be learned into model weights. Each allocation is a hypothesis about how to preserve the required capacity and must be tested. The options differ in provenance—how readily behavior can be traced to the source that influenced it—correction cost, portability across models, and ease of attributing failures. Behavior alone may not reveal which allocation produced it because memory-backed personalization can look like model improvement.

Three questions should remain distinct even when their answers interact: Does the target need the function or share the failure mode? Does the human causal mechanism transfer? Where should the responsible roles be allocated? Restate any surviving function as the behavior and dependencies an implementation must preserve. Shared state, recurrence, joint adaptation, or another dependency fixes a component boundary only when a rival allocation cannot preserve the required behavior and dependency without material degradation. Compare candidate allocations against that test, the needs of the target's consumers, feasible media such as context, artifacts, or model weights, domain constraints, and available orchestration machinery. These considerations can narrow or settle the choice; the analogy alone cannot. Finally, compare this map with the allocation implied by the analogy. If the function survives but the boundary moves, the function has support while the inherited allocation remains a design choice.

Nor is separation always better. Coupling can reduce latency and interface costs, preserve shared representations, or enable joint optimization. Separation can improve provenance, replaceability, and controlled evaluation, but it adds coordination and consistency costs. A human analogy can identify reasons to couple, but the target architecture must supply their force: either a boundary-sensitive dependency fails under rival allocations or an independent target-side constraint warrants the boundary. Resemblance alone cannot establish it.


Relevant Notes: