Letta Code report verification

Type: agentic-system-analyses/types/agentic-system-verification.md

Verification

The reports support a bounded implementation-and-design account. No material blocker was found. Two additional shipped mechanisms limit the completeness of the delegation and memory-curation inventories; neither invalidates the selected Task workflow or the inspected memory gates.

I read all supplied members, types and contracts. The four correction-answer files are empty; there are no correction arguments to accept or decline. The supplied structural report says none, so there is no structural failure requiring a routed blocker. I independently rechecked SRC-1's clean checkout and HEAD against the boundary, then inspected source text without executing the target, tests, examples or providers. The tracked top-level tree agrees with the boundary's coverage table. Local provider execution and the shipped hosted client are compatible with the enclosing-runtime classification; external service responsibilities remain excluded. No source change or boundary contradiction was found.

Records, evidence and force

I assessed every declaration in the runtime records, memory records and epistemic records, together with the workflow account and annotations. This covered record referents, cited source passages, conditions, evidence strength, consumer force and the conclusions depending on them. Deterministic citation and quotation-occurrence checks are not substitutes for this judgment.

  • Foreground execution and context. I traced input append, live-run exclusion, orphan-call settlement, history selection, effective settings, prompt resolution and executor invocation in SRC-1 src/backend/dev/fake-headless-backend.ts, then provider-context assembly in src/backend/dev/pi-stream-adapter.ts and revision handling in src/backend/local/local-backend.ts. These support RT-RTE-foreground-turn, both runtime model components and RT-BAP-provider-context. The components' externally unresolved parameter identity is preserved, not replaced by a claim that a configured model handle freezes weights. Scoped registry selection and explicit missing-context failure in src/tools/manager.ts support RT-OBJ-tool-context.
  • Admission and recovery. I checked deny/guard precedence in SRC-1 src/permissions/checker.ts, the optional execution callbacks in src/agent/approval-execution.ts, the serialized unknown-to-exact transitions in src/websocket/listener/recovered-approval-checkpoint.ts, and the shell wrapper in src/tools/impl/shell-sandbox.ts. The findings in RT-CLM-approval-policy, RT-RTE-listener-approval, RT-CLM-effect-checkpoint and RT-CLM-shell-isolation remain path-conditional. Precomputed results bypass new tool execution; the pre-effect unknown transition concerns execution crossing the callback, not every previously computed effect. Neither consent, an optional sandbox nor a checkpoint establishes correctness, rollback or exactly-once external effects. App Server's non-loopback startup guard in src/websocket/app-server.ts supports its narrower authentication claim, not complete network authorization.
  • Other runtime changes and principals. Due/manual schedule admission and queued-versus-completed status in SRC-1 src/cron/scheduler.ts support RT-RTE-scheduled-prompt. Dynamic import, factory activation and owner-registration cleanup in src/mods/mod-engine.ts support RT-RTE-extension-load and its executable-authority path without implying isolation or reversal of arbitrary side effects. Dry-run, confirmation and live PATCH branches in src/skills/builtin/self-configuration/scripts/update-agent-settings.ts, and startup update exclusions in src/updater/auto-update.ts, support the separate settings and package routes. Their success predicates are not improvement oracles.
  • Retained objects and selection. Initial block conversion, root/deferred classification, committed-tree compilation, requested filesystem reads and skill injection were checked in SRC-1 src/backend/local/initial-memory.ts, src/agent/memory-format.ts, src/backend/local/system-prompt-compilation.ts, src/tools/impl/memory.ts, src/tools/impl/skill.ts and src/headless.ts. These support the core, deferred, skill and admission distinctions, including MEM-CLM-visibility-boundary. Root ARCHIVE.md still satisfies the core selector, supporting MEM-CLM-archive-projection. Compiler directory pointers do not establish universal delivery of deferred descriptions. Local transcript and conversation search retain different selection domains; the inspected term-match ratio does not establish vector retrieval. Hosted payload, selector and embedding unknowns in MEM-OBJ-hosted-memory are not converted into absences.
  • Transformation and integration. I independently followed the auxiliary model, overflow reduction and clipping in SRC-1 src/backend/local/compaction.ts, summary-plus-tail persistence in src/backend/local/local-store.ts, and later context use. The summary object is distinct from raw history; MEM-RTE-transcript-compaction and the epistemic generation/retention split preserve that distinction. Reflection triggers, successful-progress updates, automatic/explicit finalization and arena discard were checked in src/cli/helpers/post-turn-reflection.ts, src/cli/helpers/reflection-transcript.ts, src/cli/helpers/reflection-launcher.ts, src/cli/helpers/reflection-arena.ts and src/agent/memory-worktree.ts. Failed integration is not successful transcript consumption. Generic memory-worker merge preserves a conflicting branch and does not share reflection's unconditional dirty-parent rejection. Shared-repository push in src/agent/attached-repository-git-sync.ts differs from the pending-history audit in src/agent/memory-git.ts; transport and attachment membership do not establish semantic endorsement or remote convergence.
  • Epistemic checks. The complete validator in SRC-1 src/memory-frontmatter.ts supports the epistemic report's false-body counterexample: accepted scalar metadata does not validate body truth. Its diagnostics and the hook disposition in src/agent/memory-git-hooks.ts are separate functions. Destructive backup restore is another state-replacement path, not evidence of universal hook enforcement. Sequential hook blocking/rewriting in src/hooks/executor.ts and its consumer in src/tools/manager.ts support operational authority without a generic factual license. Marker predicates, pass-first comparison, prior-attempt inputs and conditional promotion in src/mods/learning-harness.ts support EPI-RTE-mod-evaluation and EPI-RTE-mod-selection, but not causal benefit or explanatory criticism. The report correctly keeps summary semantics indeterminate and reflection's requested semantic operations at doctrine strength. The learning claim is not treated as run evidence.
  • Selected workflow. I traced Task identity/fork checks, asynchronous settlement and bounded notification in SRC-1 src/tools/impl/task.ts; captured-result/error and one-time truncated-stream recovery in src/agent/subagents/manager.ts; and synthetic-user queue admission and subsequent-turn construction in src/headless.ts. These support RT-RTE-subagent-task and the workflow's conditional bidirectional account. Launch receipt, protocol success, parent product acceptance and caller delivery remain distinct. The child CLI's unrestricted mode with inherited disallows is not a claim about every delegation mechanism.

Across these findings, wired implementation, claimed doctrine and uninspected operation are supported at their stated scopes. No declaration claims an observed run or causal experiment. No evidenced-absence record is declared; uninspected alternatives therefore cannot support a complete-system negative. Model compliance, faithful summaries, factual memory acceptance and beneficial later behavior do not follow from persistence or delivery.

Relations and reconciliation

I checked all explicit Part of: relations against their referents. The retained summary belongs to the transcript container; core projection and compaction subfunctions belong to the conversation/context-maintenance account; reflection guidance and finalization belong to the background-task account; and pre-tool policy is a narrower foreground execution function. These relations do not transfer a part's semantic status to its container or establish universal activation.

The four supersessions identify the same summary, committed projection, Memory fetch and arena-selection referents. Their passage-level identities support consolidation without erasing the epistemic fields. The combined memory-prose declaration remains a valid container alongside core/deferred parts. Compaction production and retention, memory authoring and commit disposition, and reflection guidance and integration are genuinely different scopes. No supersession licenses stronger evidence or hides an incompatible value.

I checked each integration disposition. Commit-only doctrine versus dirty-file reads, archive placement versus core selection, requested visibility versus directory pointers, generic-worker versus reflection gates, human-facing versus authenticated choice, and protocol completion versus product acceptance are either source mismatches or compatible scope distinctions. None is an unresolved disagreement between analyst findings. The reconciliation therefore need not invent an unresolved-conflict paragraph.

Omission questions and stopping decision

The search basis was the frozen tracked tree, shipped dispatch/export surfaces, producer-to-consumer dependencies and alternatives to listed routes. I selected questions capable of changing consequential conclusions: whether every retained-memory read requires commitment; whether all state replacements pass the same gate; whether all child execution inherits the Task permission policy; and whether memory curation guidance consists only of reflection and structural validation. Compiler/tool, restore, worker, shared-sync and callback counterpaths settle the first two questions in favor of the reports' existing qualifications.

The last two questions exposed the additional Workflow tool and initialization procedure described in Limits. Their omission affects inventory and cross-route comparisons, not the supported positive Task workflow or the locally scoped absence of factual checking by the frontmatter validator. The epistemic report expressly withholds system-complete negatives. Further optional expansion stopped after these alternatives received bounded dispositions: no identified material challenge remains undisposed, and neither the reports' central claims nor an emitted comparison finding requires exhaustive inspection of every evaluator, migration instruction, installed extension or external service. Untested behavior and uninspected SDK internals remain unknown, not absent.

Blockers

none

Limits

  • The delegation inventory does not characterize the separately shipped Workflow tool. This limits comparisons based on RT-RTE-subagent-task and the selected workflow: do not generalize their child CLI permission defaults to all delegated execution. SRC-1 src/tools/impl/workflow.ts creates an SDK spawner, passes the invoking permission mode, runs a script asynchronously and queues bounded completion through the same notification bridge; src/tools/workflow/sdk-spawner.ts propagates the configured mode into worker query options. I inspected these caller and result-consumer paths, not the external SDK's complete execution contract. The Task account remains supported, but a complete comparison of delegation grants, worker state, verification and recovery across Task and Workflow is unavailable.

permissionMode: getRuntimeContext()?.permissionMode ?? permissionMode.getMode(), --- src/tools/impl/workflow.ts - The memory-curation and epistemic inventories leave the shipped initialization/reorganization procedure uncharacterized. The existing limits on MEM-RTE-memory-admission and EPI-RTE-commit-admission remain valid, but readers must withhold a complete account of content checking before memory adoption. SRC-1 src/skills/builtin/initializing-memory/SKILL.md requests approved-history research, authorship corroboration, current-code checks, coverage accounting, primary-agent curation and verified commitment. This is additional doctrine/design, not evidence that those semantic checks operated or warranted a particular memory. Its procedure and companion-script execution were not traced end to end; it neither turns the structural Git gate into a truth evaluator nor establishes accepted factual claims in a supplied run.

Weigh validation. Store confirmed claims as fact; for stale ones store the current fact, keeping the history only when the change is itself a useful gotcha. Unverifiable claims need your own check before entering always-loaded memory. --- src/skills/builtin/initializing-memory/SKILL.md