Letta Office Hours on March 19, 2026 centered on a strategic shift: the product is moving from server-side, chatbot-style agents toward client-side computer-use workflows. Cameron framed that change as a reorientation around agents that can operate on a machine, use files directly, and orchestrate work through local or remote environments rather than relying on fragile server-side abstractions. The episode also introduced a broad set of deprecations and migrations that follow from that bet, including MemFS as the default memory layer and skills as the preferred integration surface.
This guide is part of the Letta Office Hours archive and describes the episode as a historical record rather than a current product specification.
The practical message was less “here is a list of features” than “here is the architecture Letta now wants people to build on.” That meant new pricing, new defaults in Letta Code, a live preview of the desktop client, and repeated guidance to move away from legacy server-side patterns such as tool rules, templates, file-system-style server storage, and agent-to-agent messaging. The episode’s Q&A filled in the mechanics: how prompt caching interacts with memory edits, how MemFS behaves across devices, and why client-side orchestration is meant to be cheaper, safer, and more expressive.
Selected chapters
- 00:01:00 Letta’s next phase and the move to client-side capabilities
- 00:02:30 Letta Code as the deployable harness for computer-use agents
- 00:04:30 Computer use as the core agent model
- 00:05:00 MemFS rollout and memory-block migration
- 00:06:30 Sleeptime refactor and computer-use subagents
- 00:07:30 Deprecating agent-to-agent tools
- 00:09:00 Skills replacing server-side MCP
- 00:12:30 Templates, agent files, and version-controlled deployments
- 00:14:30 Tool rules as a mismatch for autonomous agents
- 00:18:30 Letta Code manual slash mode and subagent behavior
- 00:20:30 The desktop client and live demo preview
- 01:25:00 Prompt caching, compaction, and how MemFS changes cost dynamics
Letta’s next phase
The episode’s central theme was a deliberate change in what Letta is optimized for. Cameron described the older model as “brains in a jar”: server-side agents with memory, tools, and MCP attachments that acted mostly through hosted endpoints. The new model prioritizes client-side capabilities, especially computer use. In that framing, the important unit is not a server-hosted chatbot, but an agent that can operate within a real environment and act on files, terminals, and applications.
That shift also redefines Letta Code. Rather than being only a coding product, it becomes the harness for deploying agents anywhere a computer is available. Cameron explicitly broadened the use case beyond coding to note-taking, knowledge management, and other computer tasks. The architectural implication is that orchestration should happen closer to the environment where the work occurs.
MemFS as the new memory layer
A major migration in the episode was MemFS, the git-backed filesystem memory system. Cameron’s explanation treated it as more powerful than classic memory blocks because it is versioned, directly editable, and naturally suited to client-side workflows. Instead of writing memory through APIs that can trigger cache recompilation, an agent can work on files in its local repository and preserve more efficient prompt caching behavior.
The episode also clarified that MemFS is meant to replace the older memory-block workflow over time, though the exact treatment of existing blocks was still being worked out. The core idea is that memory should behave like normal source-controlled state: visible on disk, diffable, syncable across devices, and compatible with ordinary Git conflict resolution. That makes memory less like a special hosted service and more like a portable project artifact.
Sleeptime, subagents, and orchestration
Sleeptime was presented as the pattern for background memory work. Instead of a server-side reflection process, Letta now wants a computer-use subagent to read the conversation and update MemFS. That same logic extends to multi-agent orchestration more broadly: rather than sending messages between hosted agents and hoping they can act, the preferred pattern is for subagents to operate in environments that have the tools needed to finish work.
This is why agent-to-agent tools were described as deprecated. Cameron argued that server-side messaging is brittle, can loop dangerously, and often strips the receiving agent of the ability to do anything useful. The replacement is more explicit orchestration through tasks, skills, and computer-use agents. The through-line is that messages should lead to action in a real environment, not just another inert server-side response.
Skills, MCP, templates, and tool rules
The episode repeatedly positioned skills as the higher-level integration primitive. Server-side MCP was described as fragile and low power, while skills were framed as composable, lower-token, and better aligned with client-side computer use. In practice, that means capabilities previously bolted onto hosted agents should increasingly live in skills that can invoke local tools or translate external services into command-line workflows.
Templates and tool rules were both treated as legacy abstractions. Templates were criticized as a large maintenance surface that can be replaced by code and version control. Tool rules were described as a mismatch for autonomous agents, since they try to impose workflow logic more suited to chain-like systems. The episode’s message was that Letta wants agent behavior to emerge from code, skills, and environment access rather than from rigid server-side policy layers.
Pricing and Letta Code changes
Cameron also announced new pricing plans and described Letta Code updates. The pricing names were introduced as part of the same transition: the product package is being reorganized around the client-side direction. In Letta Code itself, manual slash mode and subagent behavior were highlighted as examples of the new workflow model, with subagents using Letta Auto.
The live desktop-client preview reinforced the same point visually: Letta is moving toward a local, computer-use-first experience rather than a remote chat interface with a few add-ons. Even the feature announcements were tied back to architecture. The message was not just that the product gained options, but that the options now support a different operating model.
Q&A themes
The Q&A focused on implementation mechanics rather than product slogans. Several questions explored how prompt caching works, why changing memory blocks can be expensive, and when MemFS edits do or do not force recompilation. Cameron explained that edits made directly in MemFS behave more like ordinary file changes, while legacy API writes can invalidate more of the cache.
Another recurring theme was coordination: how to keep agents aware of shared state, how to propagate changes, and how to manage updates across devices. The answer was consistently file-centric. Shared state should be represented as files, watched through hooks or direct reads, and synchronized like source code. That approach is more transparent and more compatible with the rest of the new stack.
Architectural through-line
The episode’s architecture can be summarized simply: move state to files, move work to computers, and move orchestration into code and skills. MemFS makes memory behave like version-controlled source. Computer use makes agents capable of meaningful action. Skills and the code SDK provide the coordination layer. Legacy hosted features remain available only as transitional scaffolding while the platform shifts.
That is why the episode spent so much time on deprecations. Each removed or discouraged feature points in the same direction: away from opaque server-side agent behavior and toward explicit, inspectable, local-first workflows. The result is a platform that is easier to reason about because it resembles software development itself—files, diffs, repositories, tools, and executable environments.