Letta Code synthesis
Type: agentic-system-analyses/types/agentic-system-synthesis.md
Bounded synthesis
From a request to host effects
Letta Code is an enclosing agent runtime that runs conversations, executes admitted client tools and preserves context for later turns. This account covers its shipped CLI, local backend, hosted-service client and maintenance drivers at commit 271f119dcf37d58649a18e6c733386b3c710a456, with an applicability cutoff of 2026-10-12. The sole source, SRC-1, supplies implementation and doctrine/design. No target, tests or examples were executed; no observed runs or causal experiments were supplied. External Letta service, provider and host-application internals are excluded. A whole-system source boundary is not an exhaustive audit of every shipped route. See boundary and evidence and Source register.
In the ordinary headless path, the caller chooses an agent and conversation and supplies a problem. The harness prepares instructions, history, skills and tool schemas. The local backend invokes a provider executor and persists the stream; the hosted alternative delegates inference and server state through an API. The model proposes text and tool arguments, while host code interprets stop reasons and owns continuation. Client-tool calls return to the harness for permission classification, execution or denial, then feed their results into another model round. Assistant text or structured headless output is the terminal product. Agent, conversation, run and tool-context identities serve different purposes; captured tool context prevents later execution from silently using a changed global registry. See RT-RTE-foreground-turn, RT-OBJ-tool-context and RT-CMP-turn-model.
Admission is not necessarily a human decision. One-shot headless denies requests needing interactive input; bidirectional sessions can receive permission responses. Automatic rules, hooks and unrestricted modes also decide. Hooks can block or rewrite arguments before execution. Permissions license actions, not the truth of their results. Optional kernel shell isolation is off by default, and its covered shell paths do not include in-process mod imports or independently spawned hooks. See RT-CLM-approval-policy, EPI-RTE-hook-policy and RT-CLM-shell-isolation.
Listener execution adds a stronger, conditional recovery protocol: before tool code runs, it durably records an unknown outcome; after settlement, it records the exact result. This distinguishes provably unstarted calls from effects that may already have happened. It does not establish exactly-once execution or rollback, and the ordinary headless path does not acquire this guarantee. App Server and channel ingress provide alternate callers, and schedules enqueue prompts without an active terminal user; queued is not completed. See RT-RTE-listener-approval, RT-CLM-effect-checkpoint, RT-CLM-app-server-auth and RT-RTE-scheduled-prompt.
Delegation, return and delivery
The representative multi-step workflow is a conditional local, non-memory Task in a live bidirectional headless session. The parent proposes an assignment; Task checks child identity and conversation scope, captures parent scope, registers background state and returns a launch receipt. The child runs its own conversation. Its CLI defaults use unrestricted permissions with inherited disallows and configured filters, not the parent's live approval dialog. These defaults concern Task, not every delegation route. See RT-RTE-subagent-task and the workflow account.
Background settlement records child success or error and routes bounded report text plus an output-file reference to the captured parent. Bidirectional headless turns that notification into queued synthetic user input for a subsequent parent turn. The parent remains responsible for the caller-facing response. Launch, child protocol completion, product verification and final delivery are distinct milestones. A captured result without a completion error is not an independently verified solution. Recognizable truncated result transport can trigger one respawn; that retry does not undo earlier effects. Keeping the input session live is necessary for this selected notification-to-continuation path; successful one-shot asynchronous delivery is not inferred. See workflow account and RT-RTE-foreground-turn.
What persists and reaches the next decision
Local memory has several consumers rather than one visibility rule. Automatic core compilation reads committed Git HEAD: in the v2 layout, root Markdown bodies become standing context and child indexes provide directory pointers. A changed committed revision can enter an ongoing conversation as a memory-update message. Requested Memory reads and Skill loading instead read working-tree files. Consequently, commitment controls automatic core projection, not all tool-fed context. Skill discovery advertises metadata; requested loading injects full procedure text separately. History loading pushes selected prior conversation context, while transcript search returns requested bounded results. See MEM-RTE-core-projection, MEM-CLM-visibility-boundary, MEM-RTE-deferred-read, MEM-RTE-skill-loading and MEM-RTE-transcript-search.
Git admission checks layout, metadata, protected paths and character budgets. These are structural constraints, not provider-token guarantees or factual acceptance. A false body assertion can pass valid frontmatter. Hooks are bypassable, and destructive backup restore is a separate directory-replacement route. The actual force of memory prose is model-interpreted context or instruction; retained policy and progress metadata have fixed program consumers. Root ARCHIVE.md remains core, so the shipped archival placement instruction does not itself reduce automatic exposure. See MEM-RTE-memory-admission, EPI-RTE-frontmatter-check, EPI-RTE-commit-admission, EPI-RTE-memory-restore, MEM-BAP-memory-context and MEM-CLM-archive-projection.
Two automatic trace-fed maintenance chains are wired. Compaction supplies bounded conversation and tool activity to an auxiliary model, trims/clips its output, and persists a summary plus retained tail for later provider calls. It reduces active context without an inspected fidelity oracle. Reflection supplies selected transcript slices and current memory to a background worker in a memory worktree. Instructions request lasting facts, contradiction correction and reusable skills. Clean successful proposals can merge mechanically; optional explicit integration is another agent conversation, not necessarily human review. Failed integration leaves source input eligible for retry; successful no-change reflection can consume it. Reasons are requested in reports and commits, but normal core and skill consumers read bodies rather than those explanations. See MEM-RTE-transcript-compaction, EPI-RTE-summary-generation, MEM-RTE-reflection-integration, EPI-RTE-reflection-guidance and MEM-BAP-reflection-progress.
These chains establish local wired trace-fed durable updates, not improved capacity or parametric training. Requested reflection curation remains doctrine-strength; summary semantics remain indeterminate. Optional arena selection affords a human-facing winner or tie choice with loser discard, but no enforced factual criterion or demonstrated later learning from its log. Shared attachment controls discovery eligibility; detach leaves bytes on disk. Hosted non-skill memory remains opaque. See MEM-RTE-arena-selection, MEM-RTE-repository-sync, MEM-OBJ-hosted-memory and profile verification.
Evidence-responsive change and assessment
The strongest inspected improvement-directed contribution is the separate mod-learning builder. Configured scenarios evaluate captured output/trace markers, exit and timeout; reports feed later proposal rounds, passing candidates are preferred, and promotion can copy selected executable code to a configured path. This is evidence-responsive successor selection for scenario conformance. Live activation is a separate mod-loading route, not a consequence proved by copying. Settings patches and release updates provide other organization-change mechanisms but do not themselves judge improvement. See EPI-RTE-mod-evaluation, EPI-RTE-mod-selection, RT-RTE-extension-load, RT-RTE-settings-patch and RT-RTE-package-update.
For continuity across long conversations, the architecture supplies durable text and explicit later-consumer channels, with lossy summary and requested retrieval alternatives. For delegated work, it supplies asynchronous settlement and parent continuation, not generic product verification. For tested executable adaptation, the builder supplies bounded evaluation and selection, not a demonstrated component effect or transfer beyond configured scenarios. These are scenario-relative capacities, not a product ranking. The public claim of long-horizon learning through self-rewriting exceeds the supplied evidence for beneficial future action. See EPI-CLM-long-horizons and the epistemic bounded conclusion.
The independent properties remain separate:
- Theory-builder conditions 1–4: the accepted account does not establish an actual formulated theory instance, decisions depending on its content, content-directed criticism with blame and changed reliance, or a next round shaped by that criticism. These remain unestablished, not evidenced absent. Mod scores and retained reports do not substitute for those conditions.
- Learning from criticism of a consumed theory: retained traces and evaluation-responsive iteration are positive contributions, but no supplied comparison establishes improved future capacity through such criticism.
- Reflection: instructions request review of the agent's experience and memory, and updates can return to later behavior through wired context channels. This supports requested self-representation and update capacity; observed representation-mediated effects remain uninspected.
- Autonomy: software and models can launch, propose and mechanically integrate without per-edit human approval on the inspected maintenance paths. This does not establish computation performing every semantic operation of an autonomous theory builder; optional arena choice is a different admission path.
- Self-improvement: the mod builder supports a dormant improvement-directed, evaluation-responsive change pathway at configured-scenario scope. Memory reflection wires trace-informed updates to later context. Neither establishes exercised self-improvement over sessions: actual evidence-to-update dependence and subsequent operation causally depending on the live change are not supplied. Successful improvement requires separate outcome evidence.
These distinctions follow the epistemic bounded conclusion, EPI-RTE-mod-selection, MEM-RTE-reflection-integration and report verification. Unassessed relevant paths prevent unqualified system-wide negatives. A candidate-to-evaluation-to-live-load trace with later operation would change the activation assessment; controlled outcome comparisons would address benefit. Concrete memory candidates, preserved criticisms and their later consumers would address theory-building and semantic acceptance. Correcting root archival placement or changing compiler selection would alter the context-load finding, whereas merely renaming a file would not.
Limitations
| limitation | affected SRC IDs and record citations | inspected boundary | conclusion prevented | evidence that would resolve it |
|---|---|---|---|---|
| No execution or causal comparisons supplied | SRC-1; RT-RTE-foreground-turn, MEM-RTE-reflection-integration, EPI-RTE-mod-selection | Source implementation and doctrine at the frozen commit | Successful delivery, exercised learning/self-improvement, reliability or causal benefit | Registered execution traces linking updates to later consumers and controlled outcome comparisons |
| External service/provider and uncaptured installed content | SRC-1; MEM-OBJ-hosted-memory, RT-CMP-turn-model, RT-CMP-summary-model, RT-RTE-extension-load | Client contracts and shipped loaders, not external internals or live installations | Complete deployed-loop guarantees, exact weight identity, external parameter updates, hosted storage/encoding/selection or arbitrary extension behavior | Frozen dependency/service implementation and captured deployment content with corresponding consumer evidence |
| Delegation inventory omits the separate Workflow tool | SRC-1; RT-RTE-subagent-task, workflow account, report-verification Limits | Task workflow; verifier inspected Workflow caller, permission propagation and notification consumer, not complete SDK contract | Generalizing Task's unrestricted child default, or complete cross-route grants, state, verification and recovery comparisons | Accepted records tracing Workflow's SDK workers, inherited permission mode and recovery/verification consumers |
| Initialization/reorganization semantic checking is not characterized end to end | SRC-1; MEM-RTE-memory-admission, EPI-RTE-commit-admission, report-verification Limits | Structural admission plus verifier's inspection of initialization doctrine requesting approved-history research, corroboration, current-code checks and primary curation | Complete content-checking inventory or inference that all memory adoption lacks semantic checks | Procedure and companion-script traces with candidate evidence, criterion, disposition and later consumption; doctrine alone cannot establish operation |
| Summary and reflection semantics are not independently checked | SRC-1; EPI-RTE-summary-generation, EPI-RTE-reflection-guidance, MEM-OBJ-reflection-payload | Bounded/truncated model inputs, clipped summaries and requested curation | Faithful summary, accepted factual or ampliative claim, completed contradiction resolution, complete evidence presentation | Input/output instances and reference checks; evidence-consuming acceptance naming criterion, intended use and scope |
| Initial content and dynamic skill provenance/control unresolved | SRC-1; MEM-OBJ-core-memory, MEM-OBJ-agent-skills, MEM-RTE-memory-admission | Known initialization and later update paths; unknown prior authorship and resource consumers | Complete lineage, agency or executable skill-memory classification | Captured initial/imported content provenance, admission principal and companion-resource invocation records |
| Replay, search and automatic reflection selection partly uninspected | SRC-1; RT-OBJ-local-transcript, MEM-RTE-transcript-search, MEM-RTE-reflection-integration | Recorded persistence/search routes and bounded normalization/selection inspection | Complete reconstruction, ranking/cache or maintenance-selector inventory | Accepted records for replay, invalidation, normalization and full multi-conversation selection |
| Generic worker repair and migration remain incomplete | SRC-1; MEM-RTE-reflection-integration, MEM-RTE-memory-admission | Reflection finalization and known distinct generic-worker gate; repair suppression, not exact edits | Universal dirty-parent veto, complete repair/retry/admission or migration-curation semantics | Traced generic-worker finalization, retained conflict repair, precise transformations and later consumers |
| Arena principal and feedback successor unknown | SRC-1; MEM-RTE-arena-selection, EPI-OBJ-arena-choice | Human-facing choice, software finalization and log/upload wiring | Authenticated per-content human review, factual acceptance or feedback-driven later training | Choice provenance, reviewed evidence and criteria; identified later feedback-update consumer |
| Path-conditional enforcement and synchronization | SRC-1; RT-CLM-shell-isolation, RT-CLM-effect-checkpoint, MEM-RTE-repository-sync, EPI-RTE-memory-restore | Optional sandbox, listener callbacks, hook-covered commits, repository transport and restore branch | Universal isolation/admission, exactly-once effects, rollback, secure erasure or hosted convergence | Deployment/enforcement audits across alternate callers, durable recovery traces and service-side convergence/erasure contracts |
| Improvement and theory-building comparisons remain local and partial | SRC-1; EPI-RTE-mod-evaluation, EPI-RTE-mod-selection, EPI-RTE-reflection-guidance, epistemic coverage | Scenario marker predicates; partial assertion/environment inspection; no candidate theory or consumed criticism | General causal component effect, autonomous theory-builder finding, successful learning or complete-system absence | Scenario/assertion validity records, independent component variation, formulated candidates and criticism-to-next-round traces |
No unresolved analyst conflict was declared. Both report-verification limits are carried above; profile verification declares no additional limit. No source files were read for this synthesis; its claims use the handed records and retained verification findings.