The July 23, 2026 Letta Office Hours episode introduced a new phase of the product narrative: the Agent SDK was presented as the main way for developers to build against Letta, after a period of API and deployment shifts. Cameron framed the SDK as the bridge between persistent agents, client-side orchestration, and custom interfaces, then used examples like Dispatch and Throne to show how event streams, approvals, and many parallel conversations can be composed into larger workflows.
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 rest of the episode explored how Letta was splitting the system into clearer parts: schedules that can outlive a single session, OpenAI-compatible model endpoints for local and hosted tooling, persistent sandboxes, early shared-memory ideas, and communication paths for agents and channels. The Q&A then pushed into memory governance, tool approvals, agent identity, and how to teach agents through feedback and explicit specs rather than by hoping raw chat history will be enough.
Selected chapters
- 00:00 Episode introduction
- 00:50 Agent SDK is ready
- 03:40 Dispatch, Throne, and custom UIs
- 08:23 Agent-created cloud schedules
- 09:38 OpenAI-compatible endpoint
- 11:12 Docs, self-configuration, and sandboxes
- 13:26 ACP editor support
- 14:11 Shared memory preview
- 15:47 Q&A: Agent SDK use cases
- 44:40 Agent memory and approval flows
- 54:02 Progressive disclosure and memory navigation
- 1:26:42 Spec-driven development and playtests
From legacy API flow to the Agent SDK
The episode's central announcement was that the TypeScript Agent SDK had reached the point where developers could build real applications on it. Cameron described an earlier transition away from a Docker-style API service and a later shift toward easier agent deployment on client devices, then positioned the SDK as the current answer to those needs. The important point was not just syntax: the SDK was presented as the abstraction for persistent agents, conversations, tool execution, and approvals, rather than a thin wrapper around message sends.
That framing helps explain why the episode kept contrasting the old REST-style flow with higher-level application patterns. Instead of treating every request as a one-off chat turn, the SDK was shown as the layer that lets applications keep agent identity stable while spinning up many conversations or sessions around it. This makes the system more like an operating surface for agent work than a single chat endpoint.
Dispatch, Throne, and event-driven work
The episode used two concrete examples to make the SDK tangible. Dispatch, built by Sarah, turns a task plus instructions into an agent stream that can be watched as work progresses. Throne, Cameron's own prototype, aims at industrial-scale software work: dispatch many runs at once, route work into separate conversations, and manage a large number of software tasks without forcing one interface to handle everything manually.
These demos show a product idea that runs through the whole episode: Letta is not only for an interactive chat window, but also for bulk orchestration. The agent can be the worker, reviewer, and coordinator at once, while the surrounding interface decides which conversations to expose, which tasks to batch, and how much of the stream the human should inspect.
Schedules, sandboxes, and execution location
Another major theme was the separation of time from place. Agent-created cloud schedules were discussed as durable triggers that can wake an agent later, even if the original machine is offline. The episode also described persistent sandboxes that can be spun down, archived, and later revived, with the practical warning that anything deployed there should also exist elsewhere.
That same boundary shows up in the OpenAI-compatible endpoint discussion. By exposing a common API shape, Letta can interoperate with tools such as Open WebUI or LibreChat while still keeping its own persistent-agent semantics underneath. The result is a system that can plug into familiar tooling without collapsing every execution mode into one flat model call.
Shared memory and approval boundaries
The shared-memory preview introduced a more explicit distinction between private agent memory and project-level context. Rather than treating every agent update as automatically authoritative, the episode leaned toward a versioned, reviewable memory surface. That led into discussion of approval flows: some memory changes are useful as direct writes, but other kinds of updates may need a human-readable proposal or a pull-request-like step before they are absorbed.
The Q&A made the tradeoff concrete. The more an agent can learn, the more important it becomes to know which memories are personal, which are shared, and which should be revisable. The episode did not present memory as a single storage bucket; it presented it as a governance problem with different paths for durable identity, team context, and inspectable edits.
Spec-driven development with agents
The late episode moved from architecture to method. Cameron described his preference for spec-driven development: start with explicit behavior, use tests and playtests to pin down what should happen, and let the agent operate inside those constraints. His discussion of Misaligned and related workflows emphasized that an agent can be productive only when the system around it clarifies the desired outcome.
That same logic tied together the episode's other themes. Shared memory, schedules, channels, and SDK sessions all become easier to reason about when the contract is stated up front. The agent may move quickly, but the project still needs a spec that tells it what counts as correct.
Q&A themes
- Why the Agent SDK is the preferred application layer for persistent agents.
- How cloud sandboxes and schedules retain work across devices and sessions.
- Why shared memory needs permissions and review, not just write access.
- How agent-to-agent and agent-to-client communication can stay separable.
- Why tests, contracts, and explicit specs matter more as agents do larger code tasks.
Architectural through-line
The episode's architecture keeps separating concerns that used to be bundled together:
- Agent identity is distinct from a conversation.
- Memory is distinct from shared project knowledge.
- Schedules are distinct from the computer that executes them.
- Sessions and channels are distinct from the runtime that serves the agent.
That is the underlying story of the episode. Letta was being presented as a distributed system for long-lived agents, where persistence comes from clean boundaries rather than from one giant always-on chat process.