The June 19, 2026 Letta Office Hours episode introduces Letta Code mods and connects them to channels, schedules, local operation, memory, and agent learning. A mod changes the running harness by adding tools, commands, event handlers, providers, permission behavior, or interface elements. The later discussion asks how those changes become inspectable and reusable without retraining the model.
This guide is part of the Letta Office Hours archive. It records the product and design discussion from that date; current behavior belongs in the Letta documentation.
Selected chapters
- 00:00:00 Welcome and release recap
- 00:02:03 Product-update introduction
- 00:03:40 Letta Code app and Windows build fixes
- 00:06:10 Slack channel reaction and listen-mode controls
- 00:09:40 Signal channel progress
- 00:11:42 Schedules and new conversations per cron fire
- 00:20:05 Building plan mode as a mod
- 00:27:30 Mods, MCP, and harness extensibility
- 00:55:00 Memory types: experiential, core, procedural, structural
- 01:00:00 MemFS, memory architecture, and why mods change the harness
- 01:15:00 Context Constitution and prompt or tool-description changes
- 01:26:00 Parametric and nonparametric continual learning
Mods change the running harness
Cameron describes mods as runtime extensions to Letta Code. They can add tools, slash commands, event handlers, permission events, model providers, and interface behavior without putting each extension into the core application.
Caren demonstrates the mechanism by rebuilding plan mode as a mod. The example matters because plan mode affects how an agent works, while its implementation can remain a separately installed extension. A mod can therefore change both capability and interaction flow without requiring a new Letta Code release.
Channels and schedules control where work appears
The product roundup includes reaction controls and listen mode for Slack, progress on Signal support, and richer Telegram formatting. Each channel presents the same agent through different message, identity, interruption, and privacy rules.
Schedules gained the option to start a new conversation for each cron fire. A fresh thread prevents repeated jobs from accumulating one unbounded transcript and makes each occurrence easier to inspect. Local mode keeps the agent and its memory on the user's machine, trading cloud reachability for local custody.
Memory has several roles
Cameron distinguishes experiential, core, procedural, and structural memory. The names separate event history, retained facts, reusable methods, and the organization that makes other memory usable. MemFS provides an inspectable place to store and revise those records.
Mods participate in this architecture because they change the tools and events through which an agent reads, writes, and acts on memory. Installing a mod changes available behavior. It does not by itself establish that the agent will select that behavior at the right time.
Skills support learning in context
The episode contrasts parametric learning, which changes model weights, with nonparametric learning through context, memory, skills, and harness configuration. Cameron describes skills as interactive documentation: an agent can inspect a procedure while working and use it as the current operating guide.
A skill can change without retraining the model. The change remains visible as text and files, and later runs can load the revised procedure. Evaluation is still needed because a readable instruction does not prove that the agent follows it correctly.
Deployment keeps identity reachable
The Q&A discusses local agents, Cloud agents, remote APIs, and orchestration products. These deployment choices decide where memory and execution live and how another application reaches the agent.
The remote API gives applications a stable way to address an agent while clients and execution environments change. Channels provide conversational access. Schedules provide temporal triggers. Mods and skills define available procedures. Together, those parts let one retained agent operate in several settings without pretending that every setting has the same permissions or tools.
The runtime is an editable part of agent behavior
The episode's main design claim is concrete: agent behavior depends on the model plus the harness around it. Mods change the harness. Skills and memory preserve procedures and context. Channels and schedules determine where and when those procedures run.
This approach makes behavior changes inspectable, but it also creates more state to manage. Operators need to know which mod supplied a tool, which skill guided a task, which conversation a schedule created, and which environment produced the effect.