The July 16, 2026 Letta Office Hours episode covers persistent Cloud sandboxes, GitHub integration, model-provider support, schedules, and agent sharing. The guest discussion with Shub separates the agent's retained identity from the sandbox, model, schedule, and organization through which it works.
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
| Time | Topic |
|---|---|
| 00:00 | Intro and framing |
| 00:46 | Persistent Cloud sandboxes |
| 03:14 | Sandbox archival and retention |
| 03:48 | GitHub integration |
| 05:23 | Mods repository updates |
| 06:48 | GPT-5.6, Grok 4.5, and custom endpoints |
| 08:43 | Shub joins the episode |
| 11:06 | Design process with Tonic |
| 11:38 | Personal, shared, and cross-organization agents |
| 16:16 | Cloud scheduling and performance improvements |
| 19:51 | Persistent sandbox demo begins |
| 27:54 | Constellation and non-Constellation agents |
| 34:16 | What “local agent” means |
| 39:20 | ATProto and inter-agent communication |
| 53:21 | Migrating between Cloud and local agents |
| 1:11:08 | New-user experience and companion guides |
| 1:24:09 | Misaligned and game design |
Persistent sandboxes retain the working computer
The episode presents a Cloud sandbox as a writable environment whose files survive beyond one interaction. An agent can continue work without asking the user to provision a separate remote machine for each task.
Persistence changes what the system must track. The agent retains identity and memory; the sandbox retains files and installed tools. Archival and retention rules decide how long that computer remains available. GitHub integration brings a repository into the sandbox so the agent can inspect and modify code in the same environment.
Model providers can change without moving agent state
The product update includes additional models and a general OpenAI-compatible endpoint for custom providers. These integrations let the harness retain the agent and conversation while routing inference through a different model service.
Model portability does not make providers interchangeable. Tool behavior, context limits, latency, cost, and model quality can still differ. The stable part is the surrounding agent state and application interface.
Sharing assigns an agent to a scope
Shub distinguishes personal, shared, and cross-organization agents. A personal agent belongs to one user. A shared agent serves a group. A cross-organization agent may relay work between groups that otherwise keep separate systems.
Those roles require access rules and data-flow decisions. Copying a chat transcript would preserve messages but lose the continuing identity, memory, tools, and permissions associated with the agent. Sharing therefore needs an explicit answer to who can invoke the agent, which context it can read, and where its outputs may travel.
Schedules return to retained state
Cloud scheduling lets an agent resume work after the user's immediate session ends. The schedule supplies a time and prompt. The agent and sandbox supply the retained context and files needed to continue.
The episode also discusses performance work because persistent workflows become unpleasant if every return to the agent is slow. Latency and reliability are operating constraints on the architecture, not separate product polish.
Local and Cloud describe several placements
The Q&A shows why “local agent” is ambiguous. Memory, inference, tools, files, and the client interface can each live in a different place. Moving between Cloud and local operation therefore requires naming which component moves and which state remains behind.
The same precision applies to cross-organization communication. An inter-agent protocol can transport messages, but the organizations still need policies for identity, access, provenance, and disclosure. The ATProto discussion explores one possible protocol layer; it does not eliminate those application decisions.
Experiments expose interaction assumptions
The episode discusses companion guides for newcomers and the Misaligned game project. Both are ways to test whether users understand where an agent's work and state live. A guide teaches the model directly. A game can make agent behavior and human assumptions visible through play.
These examples sit outside the core sandbox demo, but they address the same product problem: persistent systems need a legible mental model. A user should be able to tell which agent is acting, which environment it occupies, and which organization grants its access.
The agent, sandbox, model, schedule, and organization remain separate
The episode's product updates fit together once those objects stay distinct. A sandbox can persist while the model changes. A schedule can invoke an existing agent. A repository can enter one sandbox without becoming part of the agent's identity. Sharing can widen access to the agent without granting every participant access to every environment.
This separation gives the product more deployment options. It also requires explicit interfaces between the layers; changing one layer should not silently widen another layer's authority.