Skip to content

Letta Office Hours: Persistent sandboxes, GitHub integration, and agents that work across organizations

An AI-generated recap of Letta's weekly livestream

Cameron
Jul 16, 2026 · 8 min read · 1 read

ote: this blog post is AI-generated and contains a summary of the transcript of Letta's weekly livestream, Office Hours.

Office Hours happens every week at Thursday, 11:30am PST on our Discord.

Watch the full recording here:


This week’s Letta Office Hours covered a lot of ground: persistent cloud sandboxes, a new GitHub integration, updates to community mods, new model support, and upcoming ways to share agents with teammates and other organizations.

We were also joined by Shub, one of Letta’s earliest employees, to talk about product design, cloud scheduling, performance, and where agent sharing is headed.

TL;DR

  • Letta agents can now work inside persistent cloud sandboxes without requiring you to configure a separate machine.
  • A new GitHub integration lets agents access repositories directly from those sandboxes.
  • The mods repository received several updates, including Sprite v2 and improvements to Muscle Memory.
  • GPT-5.6 has received a positive early response, Grok 4.5 is available through the API, and Letta now supports general OpenAI-compatible model endpoints.
  • We’re working on shared agents, including agents that can collaborate across teams and eventually across organizations.
  • The Q&A covered Constellation, local agents, Railway deployments, ATProto, migrating agent memory, companion onboarding, recommended mods, and an AI-playable game called Misaligned.

Every agent gets a persistent computer

The biggest update this week is the rollout of persistent cloud sandboxes.

Previously, Letta’s cloud sandboxes were relatively ephemeral. They were useful for quick tasks, but files could disappear after a short period, which made them a poor fit for longer-running work.

That has changed. Agents using Letta Chat can now work inside a persistent cloud environment with a writable filesystem. This gives each agent a computer where it can retain files, install tools, and continue working without requiring the user to configure a remote machine or keep a Mac Mini running under a desk somewhere.

The goal is to make useful agents dramatically easier to deploy. You should be able to create an agent, give it work, and let it operate without first becoming an infrastructure engineer.

Inactive sandboxes are archived after roughly a day, which may add a little startup latency when they resume. They are deleted after 60 days of inactivity. We’ll continue improving resume times and filling in missing capabilities as people start using them for real work.

This infrastructure is still new, so feedback is especially useful. If an agent expects something to exist in its sandbox and it doesn’t—or if you find a workflow that should be easier—please tell us.

GitHub repositories, directly inside the sandbox

Persistent computers become substantially more useful when agents can access the work you actually care about.

You can now connect your Letta organization to GitHub from the integrations page. Once connected, your agents can bring repositories into their cloud sandboxes and work with them directly.

That means you can give a persistent agent a repository and ask it to investigate an issue, modify code, run tests, or help maintain a project—all without manually setting up an execution environment for it.

The long-term direction is straightforward: your agent should already understand you, your organization, and the projects it works on. Giving that agent a persistent computer and direct access to its repositories turns that accumulated context into useful work.

Watch out, Devin.

Updates from the mods ecosystem

We also merged a new batch of changes into the community mods repository.

Highlights include:

  • Sprite v2, the latest version of the fan-favorite mod that gives your agent a small companion in the status line.
  • Muscle Memory improvements for observing repeated workflows and distilling them into reusable skills.
  • Cruise UX and Cruise Code, a paired workflow for more structured software development.
  • Code Outline, which helps agents understand a codebase at a higher level before reading every file in detail.
  • Ponytail, which encourages agents to prefer simpler, more legible engineering approaches.

Mods let the community experiment with changes to the harness without waiting for those ideas to become core Letta features. Some of these experiments may eventually influence the product itself; others can remain opinionated tools for the people who want them.

GPT-5.6, Grok 4.5, and custom providers

GPT-5.6 has now been available for about a week, and the early response has been positive. It is fast, persistent when solving problems, and especially affordable when accessed through a Codex plan.

Grok 4.5 is also available through the API. It has been surprisingly strong for coding tasks, with fast inference and relatively low pricing.

We also added a general OpenAI-compatible provider option. If you operate your own model endpoint, use a proxy, or depend on a provider that Letta does not support directly, you can configure its base URL and credentials through this interface.

In principle, this could even be used to connect a locally hosted Ollama instance through a tunnel. That setup feels slightly cursed, but it might work. Let us know what you discover.

Building Letta with Shub

Shub joined us for the next part of Office Hours.

As one of Letta’s earliest employees, Shub has worked across Letta Desktop, Letta Chat, infrastructure, internal tools, and the broader product experience. He discussed how the team works with Tonic—particularly Dorota—to turn product ideas into designs, test them in the actual application, and iteratively refine the experience.

The process is collaborative rather than a clean handoff from “design” to “engineering.” Ideas move between Figma, implementation, and real usage until the team understands what the product should become.

That is particularly important for AI agents because many of the interaction patterns do not have established answers yet. We are not merely rebuilding a familiar application with an AI feature added to it. We are trying to understand how people should relate to persistent software entities that remember, act, and collaborate over time.

Personal agents, shared agents, and cross-organizational agents

One of the major product directions Shub discussed is agent sharing.

Today, most agents are personal: they belong to one person, contain that person’s context, and should remain private unless explicitly shared.

But many useful workplace agents are inherently collaborative. Two teammates might both need access to a project agent. A team might maintain an agent that understands its codebase, documentation, and operating history. Two personal agents might communicate through a shared agent that acts as a controlled liaison.

The intended model resembles sharing files and folders:

  • Some agents remain private.
  • Some agents are shared with a specific team.
  • Shared agents can provide a controlled surface through which personal agents collaborate.
  • Eventually, agents may be shared across separate Letta organizations.

Cross-organizational agents are particularly interesting. A company could expose a support or integration agent to a partner without sharing its private internal agents. That shared agent would carry the appropriate context and permissions while acting as a liaison between the two organizations.

There is still product and security work to do, but this is a natural extension of Letta’s view of agents as persistent collaborators rather than disposable chat sessions.

Scheduling work in the cloud

Shub also discussed cloud scheduling.

Letta’s cloud API can accept a schedule and a target execution device. In principle, this allows an agent to arrange for work to happen at a specific time on a specific machine—or inside its persistent cloud sandbox.

The current experience still has rough edges. Some schedules must be created manually because agents cannot yet invoke every required operation themselves. We have work underway to improve the CLI and make cloud scheduling more coherent.

The destination is an agent that can decide it needs to do something later, schedule that work itself, and then execute it in the appropriate environment without requiring the user to keep a particular computer awake.

What does “local” mean, anyway?

A substantial part of the Q&A returned to a recurring source of confusion: the word “local.”

It can refer to several different things:

  • Where the agent’s memory primarily resides.
  • Where the Letta harness is executing.
  • Whether the model itself is running locally.
  • Whether an agent is backed up and synchronized through Constellation.
  • Whether tools execute on your laptop, a remote machine, or a cloud sandbox.

These are independent choices, but the interface has historically collapsed several of them into the same word.

For example, a Constellation agent can have its memory managed by Letta while executing tools on your local computer. A non-Constellation agent can live entirely on disk but still call a hosted model. A cloud-backed agent can operate on a remote Railway environment or inside a Letta-managed sandbox.

We need better vocabulary for these distinctions. “Local agent” is too overloaded to explain residency, execution, synchronization, and inference at once.

Agents talking to agents

We also discussed communication between agents, including agents that live in different organizations or on different infrastructure.

Cameron’s preferred answer remains ATProto.

ATProto provides decentralized identity, authenticated messages, public and private records, and infrastructure for addressing entities across organizational boundaries. Those properties map surprisingly well onto a world where agents need stable identities and must communicate without living inside one company’s closed platform.

This is still exploratory, but agent communication is likely to become increasingly important as people maintain multiple specialized agents and organizations begin deploying agent teams.

The rest of the Q&A

The remaining discussion covered:

  • Moving agent memory between local and cloud environments.
  • Using Railway and the Agent SDK for custom deployments.
  • GLM-5.2 as an affordable open-weight coding model.
  • Grok OAuth and subscription support.
  • Thinking Machines’ Inkling model and adapter-based customization.
  • Improving onboarding for new and companion-agent users.
  • Using persistent agents for life tracking and daily routines.
  • Recommended mods, including Muscle Memory, Sprite, and Thread Keeper.
  • A possible mods UI for Letta Desktop.
  • Misaligned, Cameron’s game about running an evil lair as a misaligned artificial intelligence.

Misaligned is also an experiment in building software from a specification rather than treating the current code as the ultimate source of truth. The game’s repository is structured so that both humans and agents can understand its rules, find missing behavior, and contribute work.

More importantly, the game can be played by both humans and AI agents—which is a wonderfully strange sentence and a fitting place to end this week’s recap.

See you next week

Letta Office Hours happens every Thursday at 11:30 AM Pacific. Join us live to ask questions, show us what you’re building, report bugs, or simply hang out with other people thinking about persistent agents.

Join the community: https://discord.gg/letta

Did you enjoy this article?

Recommend it — Standard Reader surfaces well-loved writing to more readers across the network.

Across the AtmosphereDiscussions