Tendril memory profile

Type: agentic-system-analyses/types/agentic-system-memory-profile.md

Comparison rationale

The durable library has two consumption paths. The model reads descriptions and invocation conditions; Deno reads executable source. JSON serialization does not turn interpreted conditions into symbolic enforcement. Conversely, executable TypeScript has instruction authority at its executor without being natural-language host guidance. The catalog is not an execution whitelist. See MEM-BAP-selection-guidance, MEM-OBJ-index-metadata and RT-BAP-capability-source.

The routing finding is model-mediated operation selection from retained conditions. It does not assert a deterministic trigger matcher, a relevance ranker or compliance in a supplied run. Full index delivery and requested named loading are pull operations. An identifier used to fulfill that request does not establish push selection. The separate human browser is also request-driven; its source cache can be stale. See MEM-RTE-capability-list, MEM-BAP-selection-guidance, RT-RTE-capability-execution and MEM-RTE-capability-browser.

Three admission mechanisms retain distinct warrants: wired automatic registration, afforded automatic program writes and wired manual editing. The container's affordance does not downgrade the editor or upgrade arbitrary program writes. Unknown preexisting-content control remains unresolved. Same-name replacement supports evolution, not versioned rollback, semantic improvement, consolidation or synthesis by implication. See RT-RTE-capability-admission, RT-RTE-program-mutation, RT-RTE-editor-mutation and MEM-OBJ-index-metadata.

The repair instruction supports claimed trace learning: tool failure is to shape automatically admitted durable replacement code consumed on later execution. Its update consumer has claimed learning authority; the resulting code has separate wired instruction authority at Deno. No successful repair, exercised learning or improved capacity is inferred. Other registration inputs and SDK behavior remain unresolved, rather than being assigned a negative from missing execution evidence. See EPI-RTE-failure-repair, EPI-RTE-result-disposition, RT-RTE-capability-admission and RT-RTE-capability-execution.

Reconciliation supersedes the epistemic tool-code object with MEM-OBJ-tool-source, and the epistemic summary-projection route with MEM-RTE-capability-list. All classifications use those canonical destinations. The selection-text container remains valid alongside the epistemic description and policy parts. The program/editor admission parts remain distinct within the valid workspace-mutation container; no unresolved cross-report conflict affects these mappings.

SDK-owned memory alternatives remain included but uninspected. Ordinary SDK turn accumulation, desktop display state, transient tool output and temporary scripts are not classified as accumulated memory merely because they occupy process memory. The accepted records do not establish a durable SDK summary or its absence. Arbitrary workspace write authority likewise does not establish a particular application-memory schema or later consumer. These limits prevent complete axis coverage without suppressing the positive capability-library findings. See RT-RTE-prompt-stream, MEM-OBJ-agent-display, RT-RTE-program-mutation and MEM-OBJ-tool-source.

Source-read log: none. Classification used the supplied accepted members and reconciliation only; no source ambiguity required an additional frozen-source read.