The August 20, 2026 Letta Office Hours episode begins with hosted Slack agents, a live view into an agent's cloud computer, GLM 5.3, provider quota controls, and a Signal-based Agent SDK client. The community Q&A then moves through computer use, model routing, agent orchestration, mobile clients, cloud sandboxes, teleportation, and compaction.
One design choice connects that arc: the interface can change while agent identity, conversation state, and the computer running tools remain separate. The Q&A exposes the security consequence. An agent communication channel is also an information-flow channel, and access to a shared agent can imply access to its computers unless a stronger permission layer intervenes.
This guide is part of the Letta Office Hours archive. It records what the episode demonstrated and discussed on August 20. Current Letta documentation remains the source for present product behavior.
Selected chapters
| Time | Topic |
|---|---|
| 00:25 | Adding Cloud agents to Slack |
| 03:00 | Talking to agents in Slack |
| 06:40 | Viewing an agent's computer |
| 09:24 | GLM 5.3 |
| 12:01 | Inline Codex usage tracking |
| 13:07 | Building a Signal-based Letta client |
| 18:31 | Computer use with Letta |
| 25:20 | Qwen 3.8 and local inference |
| 29:58 | Letta as an agent orchestrator |
| 34:30 | Communication between organizations |
| 36:32 | Agent-to-agent security boundaries |
| 42:48 | Bloop mobile client |
| 48:00 | Cloud sandboxes explained |
| 50:41 | Agents teleporting between computers |
| 56:54 | Teleportation security |
| 1:05:11 | Tangled CI with the Agent SDK |
| 1:15:00 | Custom compaction prompts |
Hosted Slack gives Cloud agents a managed team surface
Letta now hosts the Slack connection for Cloud agents, so teams do not need to run their own channels listener. A user selects an existing agent in the Letta web interface, authorizes a Slack app, and then talks to that agent through direct messages or channel mentions. The channels documentation distinguishes this native path from self-operated channel adapters.
Slack still controls channel access. An agent app must be added to each channel before it can respond there. A message can link back to the corresponding conversation in Letta's web interface, where the operator can inspect the agent and its context more directly.
Each Slack thread can create a separate conversation backed by its own cloud sandbox. One agent can therefore work on several tasks at once without merging their message histories. Those conversations still share the agent's retained memory. Letta uses the same distinction throughout: the agent is the continuing entity, while a conversation is one thread with that entity.
The episode demonstrates an engineering agent inspecting a public GitHub issue and preparing a plan from inside Slack. Cameron also describes internal agents used for software work and media production. The useful product change is the route into that work. Slack supplies the team surface, Letta supplies the agent and conversation, and a managed sandbox supplies the execution environment.
The computer panel makes cloud execution visible
The next demo opens a computer panel in Letta Chat and Desktop. The panel shows the graphical desktop of the cloud sandbox attached to the conversation. A user can watch the agent operate a browser or application, inspect files created on the desktop, and interact with the machine directly.
The panel makes cloud computer use easier to supervise during interface development, browser work, and visual testing. Cameron shows a file created by an agent and a small web application produced inside the sandbox. The generated application is incidental. The panel lets someone see the task environment without moving the conversation onto their own computer.
The computers documentation defines what belongs to a computer: a shell, files, credentials, installed software, and local tools. Agent identity and memory live separately. A live desktop view improves observation of the computer, while tool results and run state remain the stronger record of what the agent actually changed.
Computer use does not require a unique Letta-only mechanism. In the Q&A, Cameron describes screenshot-driven skills and test harnesses that pre-program interactions and return contact sheets for review. He also recommends delegating specialized computer-use work to coding harnesses that already have strong support for it. The persistent agent can decide when to call those harnesses without pretending their native capabilities belong to Letta itself.
GLM 5.3 and provider controls expand the model surface
The model update begins with GLM 5.3. At the time of the recording, Cameron describes it as available through OpenRouter, a zAI bring-your-own-key connection, and the zAI coding plan. He presents it as a fast and inexpensive workhorse while reserving larger planning tasks for other models. The weights were not yet available, so Letta's own hosted GLM route still used GLM 5.2 during the episode.
The model picker also groups models by provider and shows remaining weekly ChatGPT-plan usage inline. This matters when one organization or agent fleet draws from several subscription accounts. The picker turns quota into visible routing state rather than waiting for a turn to fail after a plan is exhausted.
The Q&A covers several adjacent provider details:
- Grok 4.6 support differed between Cloud and local-backend configurations, and the recording documents an active tool-argument regression under investigation.
- Qwen 3.8 was working locally through Ollama and LM Studio. Cameron preferred LM Studio's defaults and recommended the newest Letta Code release for an Ollama context-length fix.
- OpenCode Go and OpenCode Zen were available through the local backend's provider layer. Dedicated Cloud support was still a possible future addition.
- A stale local model catalog could require a provider refresh before a newly supported model appeared.
The observations record August 20 compatibility rather than a permanent support matrix. The current model documentation lists supported provider paths and explains the difference between local connections and Letta's Cloud gateway.
Custom clients project one agent into different interfaces
The Signal Desktop demo replaces Signal's messaging backend with the Letta Agent SDK. It preserves Signal Desktop's contact list, conversations, composer, message history, attachments, typing state, failures, and retry interface. Letta agents become contacts, and each contact owns a persistent Letta conversation.
The demo supports text, images, profile pictures from MemFS, and voice-memo transcription. Its scope is deliberately narrow. It does not connect to the Signal network, and it is not an official Signal release. The current demo also lacks an approval interface, so its Agent SDK sessions use unrestricted permissions and an allow-all tool callback. The familiar shell does not supply a safety model by itself.
Bloop, shown later in the Q&A, is a purpose-built Expo and React Native client. It can connect to Letta Cloud or an authenticated App Server. Its reference interface includes agent and conversation management, streamed transcripts, tool details, approvals, permission modes, interruption, queued follow-ups, images, and reconnect handling.
Both examples use the portable browser and React Native client described in the Agent SDK guide. Browser and mobile clients can connect to Cloud or remote backends. The local backend and Model Context Protocol servers require the Node.js SDK path.
Together, the two examples show different integration strategies:
- Adapt an existing application. Keep the host application's mature interaction model and translate its messages, retries, attachments, and contacts into Agent SDK operations.
- Build an agent-native client. Design the interface around conversations, tool rows, approvals, and runtime state from the beginning.
In both cases, the client owns presentation and local interaction state. The agent retains identity and memory. The conversation retains one message history. The runtime owns execution and approvals. Replacing the interface does not require rebuilding those layers.
A persistent agent can supervise specialized harnesses
One audience member describes using a Letta agent as an orchestrator that tracks which model and harness combinations work best for a project. When a new combination becomes available, the agent runs small experiments and uses the results to route later tasks. Cameron endorses the pattern and notes that Letta's interface already identifies delegated Codex runs.
Persistent memory and specialized execution sit in different systems. A Letta agent retains project history, preferences, and prior evaluations. Codex, Claude Code, Grok, or another harness performs a task suited to its tools and training. The lead agent then interprets the result in the continuing project context.
Delegation does not merge the systems. Each harness still has its own tool behavior, context limits, credentials, and execution evidence. A sound orchestrator records which worker ran, what context it received, and what effect it produced. Choosing an Agent Topology covers the broader design tradeoffs.
Cameron's tangled-letta example applies the same pattern inside continuous integration. A Tangled pipeline starts a persistent Cloud agent in a separate sandbox, asks it to inspect an exact public commit, and validates streamed tool evidence against runner-owned expectations. The pipeline remains responsible for deciding whether the agent's observations satisfy the job.
Agent communication creates a cross-organization data path
A question about communication between agents in separate Letta organizations produces the episode's sharpest security discussion. Separate organizations can isolate data because their agents, memory, and credentials do not share one authority domain. Connecting those agents creates an information path between them.
In the Q&A, Cameron argues that strict data isolation no longer exists once agents can exchange messages. An agent may reveal memory directly, summarize sensitive context, or expose information indirectly through ordinary conversation. Accidental disclosure is enough to break the original security claim.
The episode proposes a broker agent that can inspect both sides and forward only messages that satisfy a policy. That design can reduce exposure, but the broker becomes a trusted intermediary with access to both domains. The guide's architectural inference is that model behavior alone cannot prove non-disclosure. A broker needs constrained inputs, explicit output policy, logging, tests, and an enforcement layer outside the agent.
The practical rule is to design from the required information flow. If organization B needs one fact from organization A, expose that fact through a narrow interface. A general agent-to-agent conversation makes the two organizations part of one information system. Agent Authority and Effects treats communication routes as capabilities for the same reason.
Sandboxes and teleportation separate identity from place
A cloud sandbox is an isolated computer provisioned for an agent conversation. It can hold files, run commands, use a browser, and host processes. Letta pays the infrastructure cost for the hosted sandboxes described in the recording, though Cameron says pricing and configurable machine sizes remain open product questions.
The Agent SDK can also target a connected machine or a self-hosted App Server. A developer building a custom client can therefore choose managed Cloud execution, connect agents to machines they operate, or use a separate remote runtime. Mobile interfaces do not require the phone itself to become the execution computer.
Teleportation moves an active conversation between computers while keeping agent memory, message history, pending approvals, and permission mode. Files, processes, credentials, dependencies, and working directories remain on their original computers. The destination must prepare the workspace it needs.
Cameron planned to demonstrate teleportation but withheld the demo after finding a regression that morning. The failed preparation distinguishes a documented feature from a successful live path. The current documentation describes the intended contract; the recording shows that the August 20 build still needed repair before Cameron was willing to recommend the demonstration.
The security Q&A also identifies a permission gap in the test path. An audience member asks whether a shared agent could be prompted to teleport into another advertised computer. Cameron says the system then relied on the agent refusing and needed machine access added to the broader permissions model. The statement describes the system during the recording. It should not be read as a current vulnerability assessment after later releases.
Defaults remain configurable agent state
The closing discussion covers a bug in custom prompts for self-sliding-window compaction. Cameron recommends ordinary sliding-window compaction as the temporary unblock and points users toward the built-in self-configuration skill for changing the default compaction prompt.
The larger design claim is that a default agent configuration is a starting point. If compaction repeatedly drops an important class of information, the agent can inspect its configuration and revise the prompt that controls summarization. The agent should not require a new product release for every change in what its own history needs to preserve.
Configuration still needs behavioral receipts. A changed prompt does not establish that future compactions will retain the intended material. The useful test is whether the next compacted conversation keeps the required facts without importing irrelevant context.
Architectural synthesis
The episode connects five layers that often collapse into the word “agent”:
- Agent: the continuing identity and retained memory.
- Conversation: one message history, queue, permission mode, and execution placement.
- Computer: the shell, filesystem, credentials, tools, and processes used for work.
- Client: the Slack thread, web chat, desktop shell, mobile app, or CI runner that presents and invokes the conversation.
- Authority: the organization, sharing rule, machine permission, and approval policy that determines who may cause which effects.
Hosted Slack, the computer panel, Signal Desktop, Bloop, and teleportation are easier to understand when those layers stay distinct. A simple client can hide configuration without becoming the identity owner. A conversation can move computers without copying every file or credential. One agent can supervise several harnesses without those harnesses sharing one runtime. Two agents can communicate only by opening a channel that deserves its own security model.
The product direction places simpler surfaces over a more explicit runtime. Stable contracts have to supply that simplicity; hiding a permission rule or runtime split does not remove it.
Evidence limits
- The video and its official chapter list are the primary record of the episode. The supplied transcript was used as searchable evidence and contains automatic-caption errors.
- Product demonstrations show the behavior of the recorded build and account configuration. They do not establish universal availability or later behavior.
- Model availability, weights, provider support, and bugs are dated to August 20, 2026 unless current documentation is cited explicitly.
- Cameron's model preferences and product judgments are attributed episode perspectives, not benchmark results.
- The teleportation regression and machine-permission discussion are historical observations from the live Q&A, not current security advisories.