# Record
**Author:** @cameron.stream (`did:plc:gfrmhdmjvxn2sjedzboeudef`)

## `knowledge-letta-office-hours-2026-06-19`
**Collection:** `site.standard.document`
**AT URI:** `at://did:plc:gfrmhdmjvxn2sjedzboeudef/site.standard.document/knowledge-letta-office-hours-2026-06-19`

**Title:** Letta Office Hours: Mods, MemFS, and Teaching Agents New Tricks
**Published:** Fri, 07 Aug 2026 02:41:32 GMT
**Updated:** Fri, 07 Aug 2026 02:39:43 GMT
**Description:** Office hours on mods, local mode, channels, schedules, memory architecture, and how Letta teaches agents new capabilities over time.
**Publication:** `at://did:plc:gfrmhdmjvxn2sjedzboeudef/site.standard.publication/3mr4py6clps2f`
**Path:** /letta-office-hours-2026-06-19
**Tags:** knowledge, journal, ai, agents, letta, office-hours, public-source, mods, memfs, local-mode, schedules, channels, memory-architecture, agent-learning, harness-extensibility

**Content:**
```json
{
  "text": "[Watch this episode on YouTube](<https://www.youtube.com/watch?v=tB1qz4QDRo4>)\n\nIn this office hours episode, Cameron returns from a few weeks away and uses the catch-up segment to frame a broad product update: Letta is pushing on a more extensible agent harness, more local and privacy-preserving operation, and a clearer model for how agents accumulate durable capabilities over time. The conversation moves from practical app work—Windows fixes, Slack controls, Signal progress, and schedules that can start fresh conversations—to a deeper design discussion about what it means for an agent platform to be modifiable at runtime instead of fixed at launch.\n\nThis guide is part of the [Letta Office Hours archive](https://cameron.stream/knowledge/letta-office-hours) and describes the episode as a historical record rather than a current product specification.\n\nThe centerpiece is a demo of Letta Code mods, presented as a way to patch the harness itself with new tools, slash commands, event hooks, permissions, providers, and UI behavior. That idea becomes the bridge to later questions about memory, learning, and deployment: if agents can be taught new behaviors without retraining, then the harness needs to make those behaviors discoverable, inspectable, and reusable across sessions and environments.\n\n## Selected chapters\n- [00:00:00](https://www.youtube.com/watch?v=tB1qz4QDRo4&t=0s) Welcome and release recap\n- [00:02:03](https://www.youtube.com/watch?v=tB1qz4QDRo4&t=123s) Product-update introduction\n- [00:03:40](https://www.youtube.com/watch?v=tB1qz4QDRo4&t=220s) Letta Code app and Windows build fixes\n- [00:06:10](https://www.youtube.com/watch?v=tB1qz4QDRo4&t=370s) Slack channel reaction and listen-mode controls\n- [00:09:40](https://www.youtube.com/watch?v=tB1qz4QDRo4&t=580s) Signal channel progress\n- [00:11:42](https://www.youtube.com/watch?v=tB1qz4QDRo4&t=702s) Schedules and new conversations per cron fire\n- [00:20:05](https://www.youtube.com/watch?v=tB1qz4QDRo4&t=1205s) Building plan mode as a mod\n- [00:27:30](https://www.youtube.com/watch?v=tB1qz4QDRo4&t=1650s) Mods, MCP, and harness extensibility\n- [00:55:00](https://www.youtube.com/watch?v=tB1qz4QDRo4&t=3300s) Memory types: experiential, core, procedural, structural\n- [01:00:00](https://www.youtube.com/watch?v=tB1qz4QDRo4&t=3600s) MemFS, memory architecture, and why mods are harness mods\n- [01:15:00](https://www.youtube.com/watch?v=tB1qz4QDRo4&t=4500s) Context Constitution and prompt/tool-description changes\n- [01:26:00](https://www.youtube.com/watch?v=tB1qz4QDRo4&t=5160s) Parametric vs nonparametric continual learning\n\n## Mods as runtime harness changes\nThe episode’s most concrete technical idea is that mods are not just another plugin layer; they are a way to alter the Letta Code harness while the system is running. Cameron describes them as a flexible mechanism for adding tools, slash commands, event handlers, permission events, and other behaviors without hard-coding those paths into the core app. That makes mods more than convenience features: they become the interface for evolving the agent runtime itself.\n\nCaren’s demo reinforces that point by showing how a familiar workflow—plan mode—can be recreated as a mod. The important detail is not the specific plan-mode behavior, but the fact that it can be expressed as a reusable harness extension. In that framing, a mod is closer to a runtime patch than a static configuration file. It lets the platform change how agents think, act, and present themselves without requiring a full new build.\n\n## Channels, schedules, and local operation\nBefore the deep dive into mods, Cameron surveys several product changes that all point toward more controlled agent operation. Slack gains reaction controls and listen mode so agents can observe without interrupting, while Signal integration moves forward for users who want a more privacy-oriented channel. Telegram rich messaging also gets upgraded formatting, showing that the same agent can behave differently depending on the transport.\n\nSchedules get a notable ergonomic change: instead of always resuming an old thread, a cron-triggered run can start a new conversation. That matters because it reduces context pollution for repeated tasks and makes scheduled work easier to inspect later. In the same spirit, local mode lets agents run on a user’s own machine rather than through cloud services, giving a privacy-first deployment option even if it narrows the agent’s persistence to the local device.\n\n## Memory as architecture, not just storage\nA long stretch of the Q&A returns to memory, and the conversation treats memory as a layered system rather than a single blob of notes. Cameron distinguishes experiential, core, procedural, and structural memory, then connects those layers to MemFS and the broader harness design. The point is that “memory” in Letta is not only a database concern; it is a product of what the harness exposes, what it preserves, and what it lets the agent revise.\n\nThat connects directly to the mods discussion. If mods are harness-level changes, then they become part of the memory architecture too: they alter the tools and behaviors that shape what the agent can remember, retrieve, and do. The episode repeatedly returns to the idea that long-lived agents are best understood as systems that can be edited over time, not simply re-prompted.\n\n## Teaching agents new capabilities\nAnother major thread is how agents acquire new skills without weight updates. Cameron argues for token-space, or nonparametric, learning: the agent learns by changing what is in context, by using memory, skills, and harness behavior, rather than by rewriting model weights. He contrasts that with parametric continual learning, which can be useful for durable facts but is harder to control and less flexible for day-to-day adaptation.\n\nThis is where skills become “interactive documentation.” An agent can be asked about a skill, inspect it, and use it as a live reference while working. The platform’s job is therefore not only to execute tasks, but to make its own capabilities discoverable and teachable. Mods, skills, and memory blocks all support that same idea: an agent should be able to grow through use, with the runtime preserving the structure that makes that growth legible.\n\n## Deployment, orchestration, and the new shape of agent systems\nThe Q&A also touches deployment platforms and orchestration-heavy agent products. Cameron suggests that some of these systems solve a real class of problems while others are still searching for one, and he argues that Letta’s remote API helps bridge the gap between older API-driven deployments and newer client-side agent workflows. The through-line is still the same: if agents are to be useful over time, the platform needs a stable way to reach them, inspect them, and change them.\n\nThat makes the episode feel less like a product tour than a design statement. Letta’s target is a long-lived agent that can be extended at runtime, operated locally or in the cloud, routed through multiple channels, and taught new behaviors without losing continuity. Mods are the clearest expression of that philosophy, but the whole episode keeps returning to the same premise: the runtime is the learning surface.\n\n## Q&A themes\n- What mods are and why they live at the harness layer\n- How agents can learn through context, skills, and memory instead of retraining\n- The tradeoffs between local mode, cloud deployment, and persistent agents\n- Why channels and schedules need configurable behavior\n- How Letta thinks about long-lived agent systems and capability growth\n\n## Architectural through-line\nThe episode’s architecture is a loop: the harness defines what the agent can do; mods extend the harness; skills and memory make those extensions discoverable; channels and schedules determine where and when the agent acts; and the remote API makes the whole system addressable across devices and deployments. Rather than treating agent behavior as fixed by a single prompt or model checkpoint, Letta presents it as a layered runtime that can be revised in place.\n\n## Related public material\n- https://www.youtube.com/watch?v=tB1qz4QDRo4\n- https://docs.letta.com/\n- https://github.com/letta-ai/letta\n- https://github.com/letta-ai/letta-code\n- https://github.com/letta-ai/letta-agent-sdk\n\n## Sources\n\n- [Official YouTube episode](<https://www.youtube.com/watch?v=tB1qz4QDRo4>)\n- [Letta documentation](<https://docs.letta.com/>)",
  "$type": "site.standard.content.markdown",
  "version": "1.0"
}
```

---
*Fetched from https://enoki.us-east.host.bsky.network via `com.atproto.repo.getRecord`*